Re: [Oorexx-devel] [DISCUSS] What should be the default numeric digits setting for 64-bit.
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 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 10 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 99. 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.3 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
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] [DISCUSS] What should be the default numeric digits setting for 64-bit.
Mike Cowlishaw wrote:
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 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 10 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 99. 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.
In the 16-Bit world this meant that Rexx number values could be larger
than the processor's largest integer that usually would have been used
by assembled and compiled languages (offering external functions), which
I still think has been a very remarkable (and excellent) decision! This
also meant that for all practical purposes using NUMERIC DIGITS was not
needed if interfacing with external functions (receiving large numbers,
calculating with them, supplying them back).
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.)
This is exactly the problem in today's world where we deal with 64-Bit
and shortly in the future with 128-Bit and more. Interfacing with
compiled languages that take advantage of the register sizes exceeds all
of a sudden the Rexx default capability. Getting and calculating with
numbers from external functions all of a sudden cause them to be edited
by Rexx, loosing digits in the process, which in the past did simply not
happen.
This is where a real problem starts: Rexx programs all of a sudden stop
working correctly! Enclosed you'll find a small Rexx utility that I
wrote in the OS/2 days 17 years ago which would break up large files
into chunks that did fit on diskettes and generating a copy command to
reassamble the chunks to allow the original file to be recretated. (As
strange as it may seem) That very same program may be still useful in
splitting up large files for CDs or even DVDs! Just take into account
multiemedia files (digital - home - videos). (Believe it or not, that
Rexx program was faster on Windows machines than specialized, compiled
programs!)
It was with this little program that I noted for the first time a couple
of years ago, that in todays hardware environment the digits settings of
9 is becoming a serious bottleneck, causing Rexx programs that used to
run for decades to all of a sudden to fail! I think that is not
acceptable and needs to be solved once and forever! It is probably not
feasible/possible to go after all existing programs and insert a NUMERIC
DIGITS 20 (and then with 128-Bit processors and
Re: [Oorexx-devel] [DISCUSS] What should be the default numeric digits setting for 64-bit.
Hi Rick, I have been watching this thread with interest. Probably of all the committers I should have the least say, because I have hardly contributed to the 4.0.0 effort. Personally, in my coding I generally leave numerc digits alone and it doesnt affect me. In fact the only time I noticed it was when I tried to tell if something was a valid 13 digit barcode by testing for datatype 'w'. On the other hand, I know that for others it is important, and it is troubling that a rexx script should operate differently on two machines running the same operating system, just because they have different processors. This would create the sort of error that the developer could not recreate on their own machine. Indeed, it is possible that there are users out there who do not know whether their machine is 32 or 64 bit. I know it must be frustrating to hit this just before putting the code out there, but I am inclined to agree with Mike that this is not a good idea. thanks, Jon 2009/2/26 Rick McGuire object.r...@gmail.com This is directed primarily to the project committers. Mike Cowlishaw has raised the issue that the default digits setting for 64-bit implementations should remain at 9 digits rather than being raised to the higher value of 18 that will be used for numbers used internally by Rexx. I'm not terribly in favor of this, but I'm not willing to be the sole person who makes this decision. This new thread is to discuss whether the change should be made or not. In a couple of days, I'll submit this to a vote that will decide how to proceed. Note that at this stage, there's likely to be some delay on getting 4.0 out the door caused by this change. The code change itself is trivial, but we'll need to rework quite a few of the test cases plus update the docs again. Also, I suspect we're going to need to add a mechanism that allows a programmer to know when the current digits setting is different from the internal digits setting and adjust if needed. Currently, there's no clean way to detect this situation other than doing something like pass a value to a bif to see if it rejects it. One thing I was considering for the next release was an Interpreter class that would be a companion to the RexxContext class. The Interpreter class would hold the global state of the interpreter, and things like defaultDigits, internalDigits, etc. are good property candidates for this class. I have some other long range plans for this class, but those can deferred to a later release. Rick -- 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
Re: [Oorexx-devel] [DISCUSS] What should be the default numeric digits setting for 64-bit.
Just a couple of comments on David's points ... While I do not completely disagree with Mike on this issue there are some points I would like to make. 1. I would really like to know how many existing scripts are out there that would be impacted by the larger NUMERIC DIGITS setting for the 64-bit interpreter. I suspect, but have no proof at all, is that we are not talking about a large number. Just how many scripts actually perform numeric intensive operations? And of those, how many will be impacted? Again, I suspect not a large number. This really isn't a matter of 'numerically intensive' (although those will do their math 4x slower). It's about the applications today that expect a short, readable result from a computation that is then displayed to the end user. Ian Collier illustrated this: Regarding readability, compare: say 1/7 say 1/7 0.142857143 0.142857142857142857142857142857142857143 To be honest I really don't need to see that many digits unless I'm doing something highly mathematical. say 11**33say 11**33 2.32251544E+3423225154419887808141001767796309131 I have absolutely no idea how big the right-hand number is just by looking at it; it's not a useful answer to a human viewer. 2. A lot of work and a discussion went into this decision. Now is not the time to second guess ourselves. [I missed this somehow. But we are only talking about the *default* for Numeric Digits. That won't change the way anything else works (except some testcases such as Ian's examples above). 3. While I am all for the human readable features in Rexx, in this case I believe the larger setting in a 64-bit environment is justified. In that case, why not for the 32-bit environment too? With two differing implementations, there will be two diverging sets of applications (both 'working' on either environment) which will give different results, formatting, appearance, etc. 4. While I don't want to second guess the ANSI standard, it was developed at a time when 64-bit environments were not even on the radar. I believe this was at least a minor factor in setting the standard to 9. Not really. Rexx was developed when mainframes were going through the very painful 24-bit - 31-bit upgrade, and 64-bit (and Y2K) coming along was very much used as an example of how one must avoid that trap again. 9 digits was mostly chosen because it was about as long a number that one can display that's readable/understandable. The alternative is requiring some kind of format specification for every computer - human result, which discourages good programs. Last but not least, I would like to point out that any dependencies a script has on NUMERIC DIGITS being set at 9 can obviously be classified as a BAD programming practice when no check is made to determine the current setting. Rexx code is just like any other source code, it can be copied and reused over and again. Who know where that code will be pasted? And under what setting it will be running? Bad programming is bad programming no matter how it gets created or used. So every line of code must be prefixed by: if digits()\=9 then signal badprogrammer I'm unconvinced :-). And what if someone copied part of an expression from one program to another? If the language definition says (as it, in effect does, does) you may assume DIGITS is 9 unless there is evidence to the contrary, I think the programmer is not a bad programmer if he or she makes that assumption. [A valid criticism, on the other hand, might be that the language should not have defaults. Walter Pachl has often said that SIGNAL ON NOVALUE should be implicit (umm, default?). One could therefore argue that all Rexx programs should start with a series of NUMERIC instructions.] 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 Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] [DISCUSS] What should be the default numeric digits setting for 64-bit.
I realize I'm new to this forum, not on the project committee, and no one here knows me from Adam's house cat. I do have an opinion on this topic I wish to share though so please excuse the brief introduction. Though I'm new here, I'm certainly not new to REXX or to software development in general. I've been in the business for going on 40 years (yes, I'm a main-framer) and I currently work in CICS engineering for a very large financial firm. REXX is my friend, I've used it for many years, and probably have used it to accomplish things that it's own mama (papa?) never dreamed of. I've written my own REXX functions in assembler to do strange things such as dis-assembling a CICS DFHSITxx load module and pass back its parameterized contents in a stem structure so I can feed the information into a configuration database. (It seemed easier than building a general assembler source parser to get the information). We're running upwards of 1,500 CICS regions here, so having tools to help manage their configuration is a matter of survival. I think changing the traditional behavior of NUMERIC DIGITS is a bad idea, mostly for the reasons Mike Cowlishaw and others have enumerated. Just within my own company I've learned that if I ever find myself deciding on a design approach and asking myself a question like, I wonder if anyone here ever does X, uses Y, or needs Z.., that I should automatically assume which ever answer is the most detrimental to what I'm trying to do and makes it the most difficult, and proceed as if it were the iron-clad truth. I can't speak for anyone else, but in my own experience when I ask questions like that, its usually because I'm trying to get out of doing extra work that I already know I ought to do. Its not just about existing scripts/code, its also about those who in the future might attempt to build something and run afoul of this platform-dependent nuance and give up in frustration. If bif's have problems, then those problems ought to be corrected in the bif's. I realize there are areas where by necessity the language has to vary due to platform due to the interfaces to the underlying operating system (or lack thereof), but I don't think the core language features should be one of those places unless its truly unavoidable. My opinion, thanks for listening. Robert -- 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
Re: [Oorexx-devel] [DISCUSS] What should be the default numeric digits setting for 64-bit.
Maybe if we give a small example of where things will go horribly wrong
on a 64-bit system with a NUMERIC DIGITS setting of 9 then people will
have a better idea of what the impact will be.
Here is a small sample.
a = copies('A', 99888777666555444) /* perfectly acceptable for 64-bit
ooRexx */
c = half(length(a))
d = substr(a, 1, c) /* this will not give the correct result! */
return
half: procedure
return arg(1) / 2
In this example the return value of the half function will not be what
you expect because the procedure subkeyword will cause the NUMERIC
DIGITS setting to revert to 9. Digits will be lost and any subsequent
operations on the return value will not be precise.
In order to prevent this type of aberation a programmer will need to
look at every procedure in a ported 32-bit program in order to determine
if a larger setting is being inadvertently cancelled out in a procedure.
What this really means is that if you have a program the works on large
objects (like very large strings) in a 32-bit environment and then port
it over to a 64-bit environment, when the string objects start to grow
beyond what a 32-bit environment can handle then the program will become
incorrect over time. I believe this is a worse condition than the
alternative of upping the NUMERIC DIGITS default setting.
Just my 2 cents worth.
David Ashley
--
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
Re: [Oorexx-devel] [DISCUSS] What should be the default numeric digits setting for 64-bit.
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
Re: [Oorexx-devel] [DISCUSS] What should be the default numeric digits setting for 64-bit.
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
Re: [Oorexx-devel] [DISCUSS] What should be the default numeric digits setting for 64-bit.
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 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 10 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 99. 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
