## oorexx-devel

 [Oorexx-devel] COMPLEX From: Walter Pachl - 2009-09-24 07:17:06 Attachments: Message as HTML ```Can anyone on this list explain the reason behind the '//' and '%' methods of this sample class. (Still) interested in mathematics Walter Pachl and a real question about rxMath The doc says that the functions should fail when a precision >16 is demanded explicitly or by default. Should this be enforced in the code (which I could not do) or corrected in the doc (which I could and would) ?? Wording would be something like "Precision is limited to 16 digits." Regards Walter```
 Re: [Oorexx-devel] COMPLEX From: Mike Cowlishaw - 2009-09-24 08:09:13 ```> The doc says that the functions should fail when a precision >16 is > demanded explicitly or by default. > Should this be enforced in the code (which I could not do) (I would have thought so ) > or corrected in the doc (which I could and would) ?? > > Wording would be something like "Precision is limited to 16 digits." What would the latter mean? That 'the result could give more than 16 significant digits but the 17th and subsequent might be random (this is a bad idea)?' Or perhaps 'the result will have no more than 16 significant digits' (in this case, is the final digit correct?)? etc. Interestingly the rxmath function package accepts requests for > 16 digits -- but only returns 16. An error would have been better, perhaps. 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 ```
 [Oorexx-devel] rxmath From: Walter Pachl - 2009-09-24 09:13:06 ```This little program Numeric Digits 100 Do x=0 To pi(100)/2 by 0.1 a=rxCalcSin(x,30,'R') b=sin(x,50) Say x a Say x b Say ' ' End ::requires "rxmath" library gives me 5 "wrong" results (out of 16 test cases) I have marked them with ***: 0 0 0 0 0.1 0.09983341664682816 *** 0.1 0.099833416646828152306814198410622026989915388017982 0.2 0.1986693307950612 0.2 0.19866933079506121545941262711838975037020672954021 0.3 0.2955202066613396 0.3 0.29552020666133957510532074568502737367783211174262 0.4 0.3894183423086505 0.4 0.38941834230865049166631175679570526459306018344396 0.5 0.4794255386042030 0.5 0.47942553860420300027328793521557138808180336794060 0.6 0.5646424733950354 0.6 0.56464247339503535720094544565865790710988808499415 0.7 0.6442176872376910 *** 0.7 0.64421768723769105367261435139872018306581384457369 0.8 0.7173560908995228 0.8 0.71735609089952276162717461058138536619278523779142 0.9 0.7833269096274834 0.9 0.78332690962748338846138231571354862314014792572031 1.0 0.8414709848078965 1.0 0.84147098480789650665250232163029899962256306079837 1.1 0.8912073600614354 *** 1.1 0.89120736006143533995180257787170353831890931945283 1.2 0.9320390859672263 1.2 0.93203908596722634967013443549482599541507058820873 1.3 0.9635581854171930 1.3 0.96355818541719296470134863003955481534204849131774 1.4 0.9854497299884601 *** 1.4 0.98544972998846018065947457880609751735626167234737 1.5 0.9974949866040545 *** 1.5 0.99749498660405443094172337114148732270665142592212 I would leave the implementation as it is, document the 16, and not claim that the result is precise up to the last digit. Walter ```
 Re: [Oorexx-devel] rxmath From: Mike Cowlishaw - 2009-09-24 14:28:40 ```> I would leave the implementation as it is, document the 16, and not claim > that the result is precise up to the last digit. It's very common for maths functions to only be 'correct to within 1 ulp', instead of 'correctly rounded' (the latter can be very hard and/or expensive to achieve). However, whichever it is should be documented. Not correct to within 1 ulp would be Very Bad. I still think that if an application calls for (say) 20 digits of precision and only gets 16 then it should be alerted (by an error) -- or else, how does it know what its getting? It might be just 5. (Too late to change the behaviour of existing code that fails quietly, however.) 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 ```
 Re: [Oorexx-devel] rxmath From: Walter Pachl - 2009-09-24 16:54:39 ```I see your point, of course! So 1. doc should say what's done 2. doc should say what's done 3. We may have to distinguish 2 cases, implied versus explicit precision: a) x=rxCalcSin(0.5,,'R') where Numeric Digits is set to 20, say b) x=rxCalcSin(0.5,30,'R') explicitly asking for more than can be returned For a) documenting that the result will have 16 digits, 15 of which are reliable For b) error: invalid scond argument But I leave it to the developers to tell me how I should change the doc (when they change the code) Walter ----- Original Message ----- From: "Mike Cowlishaw" To: "Open Object Rexx Developer Mailing List" Sent: Thursday, September 24, 2009 12:58 PM Subject: Re: [Oorexx-devel] rxmath >> I would leave the implementation as it is, document the 16, and not > claim >> that the result is precise up to the last digit. > > It's very common for maths functions to only be 'correct to within 1 ulp', > instead of 'correctly rounded' (the latter can be very hard and/or > expensive to achieve). However, whichever it is should be documented. Not > correct to within 1 ulp would be Very Bad. > > I still think that if an application calls for (say) 20 digits of > precision and only gets 16 then it should be alerted (by an error) -- or > else, how does it know what its getting? It might be just 5. (Too late > to change the behaviour of existing code that fails quietly, however.) > > 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 > > > > > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register > now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > ```
 Re: [Oorexx-devel] rxmath From: Walter Pachl - 2009-09-24 20:02:23 ```> For a) documenting that the result will be .... rounded to the current setting of Numeric Digits if this is less than 16 and by the way: It's not the calculation that is done to that precision but the result will have that precision (the algorithm isn't exposed and I have not yet tested if the first argument is rounded in any way) Sorry Walter ----- Original Message ----- From: "Walter Pachl" To: "Open Object Rexx Developer Mailing List" Sent: Thursday, September 24, 2009 6:54 PM Subject: Re: [Oorexx-devel] rxmath >I see your point, of course! > So > 1. doc should say what's done > 2. doc should say what's done > 3. We may have to distinguish 2 cases, implied versus explicit precision: > > a) x=rxCalcSin(0.5,,'R') where Numeric Digits is set to 20, say > > b) x=rxCalcSin(0.5,30,'R') explicitly asking for more than can be returned > > For a) documenting that the result will have 16 digits, 15 of which are > reliable > > For b) error: invalid scond argument > > But I leave it to the developers to tell me how I should change the doc > (when they change the code) > > Walter > > ----- Original Message ----- > From: "Mike Cowlishaw" > To: "Open Object Rexx Developer Mailing List" > > Sent: Thursday, September 24, 2009 12:58 PM > Subject: Re: [Oorexx-devel] rxmath > > >>> I would leave the implementation as it is, document the 16, and not >> claim >>> that the result is precise up to the last digit. >> >> It's very common for maths functions to only be 'correct to within 1 >> ulp', >> instead of 'correctly rounded' (the latter can be very hard and/or >> expensive to achieve). However, whichever it is should be documented. >> Not >> correct to within 1 ulp would be Very Bad. >> >> I still think that if an application calls for (say) 20 digits of >> precision and only gets 16 then it should be alerted (by an error) -- or >> else, how does it know what its getting? It might be just 5. (Too late >> to change the behaviour of existing code that fails quietly, however.) >> >> 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 >> >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry® Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9-12, 2009. Register >> now! >> http://p.sf.net/sfu/devconf >> _______________________________________________ >> Oorexx-devel mailing list >> Oorexx-devel@... >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register > now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > ```
 Re: [Oorexx-devel] rxmath From: Rick McGuire - 2009-09-24 20:35:33 ```The algorithm is the values are converted to a native code double values and the C equivalent library function is called for each of these functions. The returned results and formatting is performed by the native libraries. At the limits of the precision, different library implementations are known to differ on the last digit. Rick On Thu, Sep 24, 2009 at 4:02 PM, Walter Pachl wrote: >> For a) documenting that the result will be .... > rounded to the current setting of Numeric Digits if this is less than 16 > > and by the way: It's not the calculation that is done to that precision but > the result will have that precision > (the algorithm isn't exposed and I have not yet tested if the first argument > is rounded in any way) > > > Sorry > Walter > > ----- Original Message ----- > From: "Walter Pachl" > To: "Open Object Rexx Developer Mailing List" > > Sent: Thursday, September 24, 2009 6:54 PM > Subject: Re: [Oorexx-devel] rxmath > > >>I see your point, of course! >> So >> 1. doc should say what's done >> 2. doc should say what's done >> 3. We may have to distinguish 2 cases, implied versus explicit precision: >> >> a) x=rxCalcSin(0.5,,'R') where Numeric Digits is set to 20, say >> >> b) x=rxCalcSin(0.5,30,'R') explicitly asking for more than can be returned >> >> For a) documenting that the result will have 16 digits, 15 of which are >> reliable >> >> For b) error: invalid scond argument >> >> But I leave it to the developers to tell me how I should change the doc >> (when they change the code) >> >> Walter >> >> ----- Original Message ----- >> From: "Mike Cowlishaw" >> To: "Open Object Rexx Developer Mailing List" >> >> Sent: Thursday, September 24, 2009 12:58 PM >> Subject: Re: [Oorexx-devel] rxmath >> >> >>>> I would leave the implementation as it is, document the 16, and not >>> claim >>>> that the result is precise up to the last digit. >>> >>> It's very common for maths functions to only be 'correct to within 1 >>> ulp', >>> instead of 'correctly rounded'  (the latter can be very hard and/or >>> expensive to achieve).  However, whichever it is should be documented. >>> Not >>> correct to within 1 ulp would be Very Bad. >>> >>> I still think that if an application calls for (say) 20 digits of >>> precision and only gets 16 then it should be alerted (by an error) -- or >>> else, how does it know what its getting?  It might be just 5.  (Too late >>> to change the behaviour of existing code that fails quietly, however.) >>> >>> 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 >>> >>> >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Come build with us! The BlackBerry® Developer Conference in SF, CA >>> is the only developer event you need to attend this year. Jumpstart your >>> developing skills, take BlackBerry mobile applications to market and stay >>> ahead of the curve. Join us from November 9-12, 2009. Register >>> now! >>> http://p.sf.net/sfu/devconf >>> _______________________________________________ >>> Oorexx-devel mailing list >>> Oorexx-devel@... >>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>> >> >> >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry® Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9-12, 2009. Register >> now! >> http://p.sf.net/sfu/devconf >> _______________________________________________ >> Oorexx-devel mailing list >> Oorexx-devel@... >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > ```
 [Oorexx-devel] Syntax From: Walter Pachl - 2009-09-24 20:31:13 ```In a state of shock I ask this question: Is the syntax description in the manuals wrong? It says that The >>--- symbol indicates the beginning of a statement. and The ---> symbol indicates that the statement syntax is continued on the next line. and Diagrams of syntactical units other than complete statements start with the >--- symbol and end with the ---> symbol. (the ending -> being a little ambiguous here ... NOW, Is this a statement ???? 2.3. RxCalcSqrt() >>-RxCalcSqrt(number--+---------------+--)--------------------->< +--, precision--+ Pls set me straight!!!! Walter ```
 Re: [Oorexx-devel] Syntax From: Rick McGuire - 2009-09-24 20:39:09 ```It is entirely possible that the diagrams are wrong. These diagrams are done manually, generally be people who don't understand them particularly well (or even care to maintain them). If you feel these are a problem, correction patches are gladly accepted. Please remember, the people who work on ooRexx do so by volunteering their own time. There are more tasks needed to achieve perfection than can possibly be performed by the small team of people who are actually making contributions to the project. Rick On Thu, Sep 24, 2009 at 4:31 PM, Walter Pachl wrote: > > In a state of shock I ask this question: > Is the syntax description in the manuals wrong? > > It says that > The >>--- symbol indicates the beginning of a statement. > > and > > The ---> symbol indicates that the statement syntax is continued on the next > line. > > and > > Diagrams of syntactical units other than complete statements start with the >  >--- symbol and end with the ---> symbol. > > (the ending -> being a little ambiguous here ... > > NOW, Is this a statement ???? > > 2.3. RxCalcSqrt() > >>>-RxCalcSqrt(number--+---------------+--)--------------------->< > >                                       +--, precision--+ > > > Pls set me straight!!!! > > Walter > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > ```
 Re: [Oorexx-devel] Syntax From: Mark Miesfeld - 2009-09-24 20:47:40 ```On Thu, Sep 24, 2009 at 1:31 PM, Walter Pachl wrote: > In a state of shock I ask this question: > Is the syntax description in the manuals wrong? > > It says that > The >>--- symbol indicates the beginning of a statement. > > and > > The ---> symbol indicates that the statement syntax is continued on the next > line. > > and > > Diagrams of syntactical units other than complete statements start with the >  >--- symbol and end with the ---> symbol. > > (the ending -> being a little ambiguous here ... > > NOW, Is this a statement ???? > > 2.3. RxCalcSqrt() > >>>-RxCalcSqrt(number--+---------------+--)--------------------->< > >                                       +--, precision--+ > > > Pls set me straight!!!! You seem to have left out this sentence: The --->< symbol indicates the end of a statement. So, yes the above is a statement. -- Mark Miesfeld ```
 Re: [Oorexx-devel] Syntax From: David Ashley - 2009-09-24 21:46:30 ```On 09/24/2009 03:31 PM, Walter Pachl wrote: > In a state of shock I ask this question: > Is the syntax description in the manuals wrong? > > It says that > The>>--- symbol indicates the beginning of a statement. > > and > > The ---> symbol indicates that the statement syntax is continued on the next > line. > > and > > Diagrams of syntactical units other than complete statements start with the > >--- symbol and end with the ---> symbol. > > (the ending -> being a little ambiguous here ... > > NOW, Is this a statement ???? > > 2.3. RxCalcSqrt() > > >>> -RxCalcSqrt(number--+---------------+--)--------------------->< >>> > +--, precision--+ > > > Pls set me straight!!!! > > Walter > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > Actually, the syntax diagram is correct. It looks like a '<' character got eaten by DocBook. I will look into that. David Ashley ```
 Re: [Oorexx-devel] rxmath From: Walter Pachl - 2009-09-25 22:12:58 ```How does the ooRexx community decide on such an issue. Fact is that the current implementation never fais due to too high an explicit or implied precision. I urge you to make up your mind and decide what should be done. My solution would be error if the user explicitly asks for more than 16 digits and document that only 16 digits are returned when the inherited precision is larger that 16. class NumericFormatter is the one that would have to be changed Related to this some other observations: 1.2. Error Handling and Function Returns Error 40 (Incorrect call to routine) is raised if either the wrong number of arguments or incorrect data is passed to a function. I notice error 88 when a numeric argument cannot be converted to double Where an error occurs, the variable MATHERRNO is set with additional information that further defines the source of the error. Can anyone provide an example? Have a nice weekend Walter ----- Original Message ----- From: "Mike Cowlishaw" > > I still think that if an application calls for (say) 20 digits of > precision and only gets 16 then it should be alerted (by an error) -- or > else, how does it know what its getting? It might be just 5. (Too late > to change the behaviour of existing code that fails quietly, however.) > > Mike > ```
 Re: [Oorexx-devel] rxmath From: Walter Pachl - 2009-09-26 05:32:47 ```----- Original Message ----- From: "Rick McGuire" "if a doc update was missed regarding this error, then the documentation should be fixed. Rick" Most definitely so, I'd say. If that's the decision I volunteer to work on the update of the rxmath.doc. Walter ```
 Re: [Oorexx-devel] rxmath From: Rick McGuire - 2009-09-25 23:14:43 ```I don't agree that there should be a distinction between behaviors based on how the digits value has been set. The 3.2.0 code did not make such a distinction, raising an error in both situations. The error for a too large value was removed when we discovered that rxmath could not be used on a 64-bit system without lower the default digits setting. To accommodate this, the error for a value above the maximum was removed. The default digits setting for 64-bit systems has since been lowered to 9, but the issue is still there. I don't have a problem with how the code is behaving, and if a doc update was missed regarding this error, then the documentation should be fixed. Rick On Fri, Sep 25, 2009 at 6:12 PM, Walter Pachl wrote: > How does the ooRexx community decide on such an issue. > Fact is that the current implementation never fais due to too high an > explicit or implied precision. > I urge you to make up your mind and decide what should be done. > > My solution would be error if the user explicitly asks for more than 16 > digits > and document that only 16 digits are returned when the inherited precision > is larger that 16. > > class NumericFormatter is the one that would have to be changed > >            Related to this some other observations: > 1.2. Error Handling and Function Returns > Error 40 (Incorrect call to routine) is raised if either the wrong number of > arguments or incorrect data is passed to a function. > >            I notice error 88 when a numeric argument cannot be converted to > double > > Where an error occurs, the variable MATHERRNO is set with additional > information > that further defines the source of the error. > >            Can anyone provide an example? > > Have a nice weekend > > Walter > > > > ----- Original Message ----- > From: "Mike Cowlishaw" > >> >> I still think that if an application calls for (say) 20 digits of >> precision and only gets 16 then it should be alerted (by an error) -- or >> else, how does it know what its getting?  It might be just 5.  (Too late >> to change the behaviour of existing code that fails quietly, however.) >> >> Mike >> > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > ```
 Re: [Oorexx-devel] rxmath From: Rick McGuire - 2009-09-26 11:09:14 ```The 4.0 also makes no distinction, but it removed what I consider to be an arbitrary error behavior. The library returns as many digits as it can within the requested digits. Rick On Sat, Sep 26, 2009 at 3:23 AM, Mike Cowlishaw wrote: > I think I agree with Rick on this: > >> I don't agree that there should be a distinction between behaviors >> based on how the digits value has been set.  The 3.2.0 code did not >> make such a distinction, raising an error in both situations. > > Hence, if the doc makes no distinction and the 3.2 code makes no > distinction, but the 4.x code does make a distinction, then the correct > action is to change the 4.x code back to the 3.2 behaviour? > > This does seem to be the best thing mathematically, too.  If the user asks > for 20 digits but only gets 16, then the result could be off by 10,000 > ulps, which is 'shocking' :-).  Some algorithms would never converge with > that kind of error.  (And, of course, if later the underlying software > started using a more precise library based on quad BFP (binary128) or > decimal128 then suddenly results could start to be very different. > > Incidentally, there is now a decimal function library available open > source, I think (from Intel).  Pretty sure that would provide decimal128, > which would permit up to 34 digits precision (I haven't looked at it). > > > 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 > > > > > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > ```
 Re: [Oorexx-devel] rxmath From: Mike Cowlishaw - 2009-09-26 15:25:32 Attachments: Message as HTML ```> The 4.0 also makes no distinction, OK, good. > but it removed what I consider to > be an arbitrary error behavior. The library returns as many digits as > it can within the requested digits. Not OK. That allows it to return (in the extreme case) the result '1' for any and all functions. Just one example: hull1985b paper Cats: ov PDF ¿Web? Properly Rounded Variable Precision Square Root, T. E. Hull and A. Abrham, ACM Transactions on Mathematical Software, Vol. 11 #3, pp229?237, ACM Press, September 1985. Abstract: The square root function presented here returns a properly rounded approximation to the square root of its argument, or it raises an error condition if the argument is negative. Properly rounded means rounded to nearest, or to nearest even in case of a tie. It is variable precision in that it is designed to return a p-digit approximation to a p-digit argument, for any p > 0. (Precision p means p decimal digits.) The program and the analysis are valid for all p > 0, but current implementations place some restrictions on p. The algorithm described in this will fail horribly if at some point some function it uses starts returning fewer than the requested digits. And then anything that uses square root will similarly fail. Case in point: GPS location of a place on the surface of the earth to ~3m requires calculations working at better than 23-24 (decimal) digits. Mike [Editor IEEE 754, so know more than I would have wished to about this kind of thing :-( ] 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 ```
 Re: [Oorexx-devel] COMPLEX From: Walter Pachl - 2009-09-24 08:22:50 ```Well I just observer what is returned. I am sure that the 16 digits returned are not always correct (when I compare them with my results computed to nnn digits. The code would have to be changed by someone else, as I said. Walter No opinion on // and % of complex? ----- Original Message ----- From: "Mike Cowlishaw" To: "Open Object Rexx Developer Mailing List" Sent: Thursday, September 24, 2009 10:08 AM Subject: Re: [Oorexx-devel] COMPLEX >> The doc says that the functions should fail when a precision >16 is >> demanded explicitly or by default. >> Should this be enforced in the code (which I could not do) > > (I would have thought so ) > >> or corrected in the doc (which I could and would) ?? >> >> Wording would be something like "Precision is limited to 16 digits." > > What would the latter mean? That 'the result could give more than 16 > significant digits but the 17th and subsequent might be random (this is a > bad idea)?' Or perhaps 'the result will have no more than 16 significant > digits' (in this case, is the final digit correct?)? etc. > > Interestingly the rxmath function package accepts requests for > 16 digits > -- but only returns 16. An error would have been better, perhaps. > > 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 > > > > > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register > now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > ```
 Re: [Oorexx-devel] rxmath From: Walter Pachl - 2009-09-25 05:39:51 ```1) What are 'native' libraries? 2) I noticed the 'double' in an error message. 3) I need a commitment that RxCalc... will be taught in the next Release to fail if what ? It does not make sense to correct the doc towards current behahior when this behavior is thought to be wrong (see Mie's comment) and might be changed in the future. Yoyo is the term for that, I think. 4) Mark, I beg to differ. "You say You seem to have left out this sentence: The --->< symbol indicates the end of a statement. So, yes the above is a statement." To me "RxCalcSqrt(number,precision)" is a functin invocation not a statement and the Syntax should accordingly look like >-RxCalcSqrt(number--+---------------+--)---------------------< the >---< indicating this (maybe) 5) David promised to clarify the < ("Actually, the syntax diagram is correct. It looks like a '<' character got eaten by DocBook. I will look into that-") I await your (Developers') advice if and what I should do about this mess (intentionally exaggerated :-) Walter Rick, I am aware of this: "...the people who work on ooRexx do so by volunteering their own time. " "It is entirely possible that the diagrams are wrong. If you feel these are a problem, correction patches are gladly accepted" But before making changes I need some agreement and advice! ------------------------------------------------------------------ And there is no response to my recent COMPLEX question (remember "//" and "%" which I can't understand. Have a nive weekend y'all ----- Original Message ----- From: "Rick McGuire" To: "Open Object Rexx Developer Mailing List" Sent: Thursday, September 24, 2009 10:35 PM Subject: Re: [Oorexx-devel] rxmath The algorithm is the values are converted to a native code double values and the C equivalent library function is called for each of these functions. The returned results and formatting is performed by the native libraries. At the limits of the precision, different library implementations are known to differ on the last digit. Rick On Thu, Sep 24, 2009 at 4:02 PM, Walter Pachl wrote: >> For a) documenting that the result will be .... > rounded to the current setting of Numeric Digits if this is less than 16 > > and by the way: It's not the calculation that is done to that precision > but > the result will have that precision > (the algorithm isn't exposed and I have not yet tested if the first > argument > is rounded in any way) > > > Sorry > Walter > > ----- Original Message ----- > From: "Walter Pachl" > To: "Open Object Rexx Developer Mailing List" > > Sent: Thursday, September 24, 2009 6:54 PM > Subject: Re: [Oorexx-devel] rxmath > > >>I see your point, of course! >> So >> 1. doc should say what's done >> 2. doc should say what's done >> 3. We may have to distinguish 2 cases, implied versus explicit precision: >> >> a) x=rxCalcSin(0.5,,'R') where Numeric Digits is set to 20, say >> >> b) x=rxCalcSin(0.5,30,'R') explicitly asking for more than can be >> returned >> >> For a) documenting that the result will have 16 digits, 15 of which are >> reliable >> >> For b) error: invalid scond argument >> >> But I leave it to the developers to tell me how I should change the doc >> (when they change the code) >> >> Walter >> >> ----- Original Message ----- >> From: "Mike Cowlishaw" >> To: "Open Object Rexx Developer Mailing List" >> >> Sent: Thursday, September 24, 2009 12:58 PM >> Subject: Re: [Oorexx-devel] rxmath >> >> >>>> I would leave the implementation as it is, document the 16, and not >>> claim >>>> that the result is precise up to the last digit. >>> >>> It's very common for maths functions to only be 'correct to within 1 >>> ulp', >>> instead of 'correctly rounded' (the latter can be very hard and/or >>> expensive to achieve). However, whichever it is should be documented. >>> Not >>> correct to within 1 ulp would be Very Bad. >>> >>> I still think that if an application calls for (say) 20 digits of >>> precision and only gets 16 then it should be alerted (by an error) -- or >>> else, how does it know what its getting? It might be just 5. (Too late >>> to change the behaviour of existing code that fails quietly, however.) >>> >>> 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 >>> >>> >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Come build with us! The BlackBerry® Developer Conference in SF, CA >>> is the only developer event you need to attend this year. Jumpstart your >>> developing skills, take BlackBerry mobile applications to market and >>> stay >>> ahead of the curve. Join us from November 9-12, 2009. Register >>> now! >>> http://p.sf.net/sfu/devconf >>> _______________________________________________ >>> Oorexx-devel mailing list >>> Oorexx-devel@... >>> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >>> >> >> >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry® Developer Conference in SF, CA >> is the only developer event you need to attend this year. Jumpstart your >> developing skills, take BlackBerry mobile applications to market and stay >> ahead of the curve. Join us from November 9-12, 2009. Register >> now! >> http://p.sf.net/sfu/devconf >> _______________________________________________ >> Oorexx-devel mailing list >> Oorexx-devel@... >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel >> > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register > now! > http://p.sf.net/sfu/devconf > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Oorexx-devel mailing list Oorexx-devel@... https://lists.sourceforge.net/lists/listinfo/oorexx-devel ```
 Re: [Oorexx-devel] rxmath From: Mark Miesfeld - 2009-09-25 14:43:50 ```On Thu, Sep 24, 2009 at 10:39 PM, Walter Pachl wrote: > 1) What are 'native' libraries? In this discussion, native libraries refer to the libraries provided by the C / C++ compiler subsystem, or by the operating system. Native library can also refer to the library that implements an external package. The main point here is that the rxmath package simply makes a call into the math library provided by C / C++ compiler subsystem and returns what that library returns. If the answer is wrong, you need to take it up with the people providing the C / C++ compiler on that platform. Microsoft on Windows, the gcc people on Linux, I believe IBM on AIX, etc.. The other point that Rick was trying to make is that it is known that there are differences in how these different libraries behave. > 2) I noticed the 'double' in an error message. A double is a C / C++ data type. A google search of: c++ double data type will yield a huge listing of explanations. > 3) I need a commitment that RxCalc... will be taught in the next Release to > fail if what ? You're probably not going to get that. If the behavior is different for that single function than for the other functions, then it could be a bug. Open a bug report. However, there is no guarantee how high on any one's list it will be. On the other hand, if the behavior is a result of how the native math library is behaving, there may be nothing to do about it. > 4) Mark, I beg to differ. "You say You seem to have left out this sentence: >                                          The --->< symbol indicates the end > of a statement. >                                          So, yes the above is a statement." >    To me "RxCalcSqrt(number,precision)" is a functin invocation not a > statement >    and the Syntax should accordingly look like >    >-RxCalcSqrt(number--+---------------+--)---------------------< >    the >---< indicating this (maybe) The explanation of the syntax diagrams is inherited from IBM. I believe they may not have worded it consistently, but it seems okay to me. Each syntax diagram shows the syntax of a single function call or method invocation, *not* a Rexx statement. When the explanation refers to a "statement" they mean a "syntax diagram" As such, in the "How to Read the Syntax Diagrams" explanation substitute "syntax diagram" every place you see the word "statement." The explanation says: The >>--- symbol indicates the beginning of a statement. The --->< symbol indicates the end of a statement. The syntax diagram reads: >>-RxCalcSqrt(number--+---------------+--)-------------->< +--, precision--+ and is correct. The statement begins with >>- and ends with ->< > 5) David promised to clarify the < ("Actually, the syntax diagram is > correct. It looks like a '<' character >                                                             got eaten by > DocBook. I will look into that-") I think David may have misread your first post, there is no < eaten by DocBook in this case. > I await your (Developers') advice if and what I should do about this mess > (intentionally exaggerated :-) My advice would be to not worry too much about the railroad track diagrams. None of the, current, people working on the docs like them and we've already reached a consensus that we would replace them if: we reach a consensus on what to replace them with and / or someone volunteers to do all the work. -- Mark Miesfeld ```
 Re: [Oorexx-devel] rxmath From: Mike Cowlishaw - 2009-09-26 07:23:55 ```I think I agree with Rick on this: > I don't agree that there should be a distinction between behaviors > based on how the digits value has been set. The 3.2.0 code did not > make such a distinction, raising an error in both situations. Hence, if the doc makes no distinction and the 3.2 code makes no distinction, but the 4.x code does make a distinction, then the correct action is to change the 4.x code back to the 3.2 behaviour? This does seem to be the best thing mathematically, too. If the user asks for 20 digits but only gets 16, then the result could be off by 10,000 ulps, which is 'shocking' :-). Some algorithms would never converge with that kind of error. (And, of course, if later the underlying software started using a more precise library based on quad BFP (binary128) or decimal128 then suddenly results could start to be very different. Incidentally, there is now a decimal function library available open source, I think (from Intel). Pretty sure that would provide decimal128, which would permit up to 34 digits precision (I haven't looked at it). 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 ```