> The processor architecture only comes in to play with values that > referred to as "numbers used directly by Rexx". This is generally the > internal digits setting used internally by bifs/methods, and for > things like "do nnnn" loops. These are the places where a Rexx number > need to be converted into native values. This is distinct from the > current numeric digits setting, which is what governs Rexx arithmetic. > > So, for the last 30 years, both of these values have always been "9", > so everything remained in sync. You could still set numeric digits > higher for calculations, but if you tried to use "1000000000" for a > substr position (for example), you would get an error for an "invalid > whole number", since the substr() bif uses numeric digits 9 > internally. All calculations that would evaluate as a whole number > under the default digits setting would also produce good values for > the bifs, and non-whole number results would generally be rejected. > The internal digits setting is unaffected by changes in NUMERIC > DIGITS. It always operates with the internal digits setting. > > In the current 4.0 codebase, when compiled for 64-bit, the internal > digits setting is 18, which allows you to manipulate values larger > than 9999999999. The default digits setting is also the same, which > means the symmetry from the 32-bit implementation is maintained. The > danger with decoulping these occurs when a bif such as pos() returns a > value that would not be considered a whole number under the current > digits setting (which btw, is a situation you can encounter if you are > running at a setting smaller than 9). If you use that value to > perform a calculation, you're likely to lose digits off the end, > creating a result with a high "astonishment factor".
There has always been that 'astonishment factor' when (typically using integers) more than 9 digits of precision are required for a calculation to be exact. That's a consequence of the choice to go for readability -- a default of 9 digits -- rather than a higher precision by default. Having 64-bit implementations does not change that; all 64-bit means is that larger objects may be more common, so the astonishment may happen a bit more often. The problem is already there in the 32-bit implementation, so programmers already have to address the issue, so this is not something that works in 32-bit but does not work in 64-bit. For example, using 32-bit 3.2.0 (some irrelevant lines & prompts deleted): dir VTS_01_1.VOB 28/04/2005 11:41 1,073,692,672 VTS_01_1.VOB say stream('VTS_01_1.VOB', 'c', 'query size') 1073692672 That result is more than 9 digits; if one is doing arithmetic on stream sizes today, in a 32-bit environment, you must already be using a larger numeric digits. (And I have to suspect that people probably set 12 or 15 digits, so increasing the default to 18 won't override that in any case.) If short: if the argument is that the 9-digit choice was wrong in the first place (which is a valid point of view) then the proposal should be to change the _language_ to use a larger default (18, 20, whatever) -- and that would then apply to all implementations, whether they run on 16-bit, 32-bit, or 64-bit platforms. I really do not like the idea that say 1/7 Might give 0.142857143 on one machine and 0.142857142857142857 on another, just because one user installed the 32-bit version and another the 64-bit. This would lead to all kinds of subtle problems of this nature (a toy example): if x/3 = 0.333333333 then say 'X is one' which would work differently depending on which version one had installed. However, I do like the idea of a directive like ::numeric digits 18 that would apply to a complete program/class. That would be useful anyway (as would similar for other 'global defaults', such as Trace setting). :-) Mike Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Oorexx-devel mailing list Oorexxemail@example.com https://lists.sourceforge.net/lists/listinfo/oorexx-devel