Re: Where to post ideas for RPG

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.