Re: Where to post ideas for RPG

The arguments do not have to all be the same sign - one of the tests compared negative and positive - works due to a fortuitous characteristic of EBCDIC - alpha characters precede numerals - this would not work in ASCII. Same data type, including length and precision, OK.

How about some positive ideas about whether it is possible? I don't know - would operational descriptors do anything worthwhile?

What are the restrictions, if any, of the typical min() or max() function in languages like C/C++? I think I saw something to the effect that both arguments have to be of the same type - which would often be some kind of integer.

A lot of min/max stuff in C++ seem to be implemented as macros - no such animal, is there, in RPG? Side effects are mentioned.

This was not presented as a final solution - maybe someone else will see value here and run with it - a very generic, type-safe pair of functions - or someone writes an RFE or COMMON requirement to ask Barbara to take care of solving it!

Cheers
Vern

On 8/22/2016 8:58 PM, CRPence wrote:

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.