From: Rick M. <obj...@gm...> - 2009-02-26 13:21:53
|
Because this creates a serious mismatch between how the bifs/methods work and the default digits setting. If you end up working with values larger than 999,999,999, then things will fail silently unless you've intentially enabled LOSTDIGITS. Don't forget, we're dealing with values returned from a bif as well as passed in. Under 32-bits, x = substr(y, pos('abc", y) + 3, 5) will never create an error with real data because you can't have a string value longer than the precision used by the bifs. If numeric digits is 9 in the 64-bit world, this will start failing when dealing with very, very large data values because the expression 'pos("abc", y) + 3' will start failing. I think in the end, you can make lots of arguments why either behavior is good or bad, but this was a decision that was discussed and made 4 years ago, and a lot of work has gone into creating an interpreter that faithfully implemented this, including tests to verify the behavior. My personal opinion is the version needs to be internally consistent with itself. Having the same digits value for the default and as used for internal numbers will prevent a lot of "unexpected results" situations. And keeping that value a 9 for a 64-bit capable system means it's essentially pointless even shipping a 64-bit version, since there's no real way to leverage the full capabilities. You also have to start introducing arbitrarily defined limits on things, like no string value longer than 999,999,999 etc. This is not a good time to reverse position on advice previously given, particularly when we're in a position to finally ship this. Rick On Thu, Feb 26, 2009 at 6:47 AM, Mike Cowlishaw <MF...@uk...> wrote: >> Yes, this was part of the conversation we had when the default of 18 >> was originally decided up. For the positive/negative range, you have >> to deal with 2**63-1, not 2**64-1. > > That's for those negative-length strings and streams? :-) > >> That value is 19 digits long, and >> the value is 9223372036854775807. *Close* to range expressed in 9s, >> but still short. So the decision came down to have a non-human >> readable limit or scale it back one increment to 18, which means the >> range is +/- 999,999,999,999,999,999 (i.e., 18-9s vs. 9-9s). > > Well, if the intent is not to encompass either power-of-two limit, it > might have been more sense to choose 16 digits (IEEE decimal64). But more > to the point, if human-readable is the goal then 9 digits is already > pushing the limit of what people can 'read at a glance' (remember, the > original choice was between 6 and 9 digits; I think 9 was the right > choice, but plenty of people thought 6 was enough). > > 9 digits is also the ANSI requirement (section 8.2.1, p70). Why > deliberately vary from the standard? I often use 'numeric digits' on its > own to revert to 9, as in: > > ... working at 9 digits > numeric digits 15 > -- do some calc to higher precision > numeric digits > ... now back to normal > > Now (depending on the implementation) this will sometimes increase and > sometimes decrease the digits! Why is this a good thing, when for 28 > years the effect of that instruction has been well-defined, on all > implementations? > > 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 > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > |