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". Anyway, the numeric NATIVE/INTERNAL or whatever spelling ends up getting applied to the option would say you explicitly want the default digits to match the internal. Specifying a value higher than that would be no different than setting the value higher than the internal version is in a 32-bit system. Rick On Thu, Feb 26, 2009 at 4:50 PM, Sahananda (Jon) Wolfers <sahana...@windhorse.biz> wrote: > Looking at David's example makes me think that it is important to get this > right before releasing 4.0.0 & thus worth a bit of a delay. > > I like Ricks idea of an ::option directive - the default being the current > setting, with NATIVE being as many as you can squeeze out of the > architecture at run time. > > What would happen if you specified more Digits on the ::option directive > than the processor architecture allowed for? > > thanks, > > Jon > > > > 2009/2/26 Moritz Hoffmann <antig...@gmail.com> >> >> Rick McGuire schrieb: >> >> > One approach would be to add an ::options directive that allows a >> > package to set how the default should be handled for code within a >> > package file. You could chose it directly, or have an option that >> > says essentially "use native". Given something like this, I'm less >> > opposed to pinning the default at the lower value. This would also >> > fix an issue that a lot of people complain about, that it's necessary >> > to up numeric digits for every method of a class, sort of killing two >> > birds with one stone. An equivalent keyword for NUMERIC digits would >> > probably be nice too. >> >> >> I like this option, it is similar to Java's strictfp keyword, which >> overcomes similar issues we're struggling with here. Generally, I prefer >> to avoid breaking existing programs, but in the case of enhanced numeric >> digits I don't see too many scenarios where it cause problems. I hit the >> border of nine digits seldomly, and if it was hit, strange things >> happened, like a number not getting incremented when adding 1 or so. >> Such problems could be avoided (or say - delayed) when increasing the >> default numeric digits to 18. >> >> Maybe we should have a discussion what pieces of code could break >> because of the changed settings, and what will work now out of the box >> due to longer numbers. >> >> Moritz >> >> >> PS: Sorry for my low activity - but my life leaves hardly any time for >> ooRexx at the moment. Hope this will change again at some time! >> >> >> ------------------------------------------------------------------------------ >> 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 >> Oorexx-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > > ------------------------------------------------------------------------------ > 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 > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > ------------------------------------------------------------------------------ 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 Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
