×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 22-Aug-2016 15:13 -0700, John Yeung wrote:
On Mon, Aug 22, 2016 at 4:42 PM, CRPence wrote:
On 22-Aug-2016 12:35 -0700, Vernon Hamberg wrote:
The result is meaningless if data types don't match (other
than zoned and character, maybe), since it is a hexadecimal
comparison. Basically, all data types should be the same.
<<SNIP>>
More appropriately than "should be", I would suggest, is that
the data-type and [notably length\scale] attributes *must* be
_identical_ for the two arguments.
Actually, it's even worse than that.
Not only must the types of all the arguments be identical, they must
be from a subset of the available types, or the arguments must meet
other restrictions, such as all being the same sign, or all being
positive. <<SNIP>>
Agreed.
FWiW, such cases were supposed to have been covered by my text that
was not included in the above quote, wherein I gloss-over the caveats of
the binary [Vern said hexadecimal] comparison, having presumed that the
/accuracy/ of such comparisons was already understood to be limited in
effectiveness; i.e. the following quote, re-inserted here:
Otherwise, there is no way to ensure the effective accuracy
["effective", per being a binary vs typed compare] for the
less-than-or-equal predicate.
I did not attempt to better explain that, as I had inferred that the
situation was already understood by Vern as a failure of the /hex/
comparison, per the originally stated assumption [from an earlier reply]
noting "so long as the sort sequence is correct in hex", the values can
be compared. As I understood Vern's assertion, in order for the /hex/
comparison to function as expected, those hex values would need to be
known to collate consistent with that less-than-or-equal predicate being
applied to the /typed/ values.
Clearly that requirement is not met for the internal representation
of the typical signed BCD [as in my example below] nor for signed
Integer types, but is met for either the unsigned representations of
either BCD or Integer and is met for the effective equivalent [to an
unsigned] scenario whereby either all values are positive [or all values
are negative and with negative predicate logic, and for BCD ensured
consistent only when all signed-positive or all signed-negative values
also share the same sign digit -- any of 0xA through 0xF].
For example, (0x555F<=0x777D)=True with a purely /hex/ comparison,
but when those values are to be represented by data-type DECIMAL(3), the
comparison no longer holds true; i.e. (555<=-777)=False.
midrange.com
