> 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')

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 

  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). :-)


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
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
Oorexx-devel mailing list

Reply via email to