We don't really have any special kind of run time object we can use, other than maybe just making that object a character string. Once Mike's decimal package is in place, things would end up getting mapped to the real numeric values for these entities. I'm not sure it makes sense to start bending space and time for this issue right now.
Rick On Thu, Sep 11, 2008 at 10:21 AM, David Ashley <[EMAIL PROTECTED]> wrote: > Speaking of the decimal math package, should the values like nan be mapped > to a run time object like .nan, .infinity, etc? This seems to me to be a > more object oriented approach to these exception values rather than a > character string representation. > > Just a thought. Feel free to shoot it down if it does not make sense. > > Thanks, > W. David Ashley > IBM Systems and Technology Group Lab Services > Open Object Rexx Team > Mobile Phone: 512-289-7506 > > > [image: Inactive hide details for "Rick McGuire" ---09/11/2008 08:49:33 > AM---I was just playing around with some edge cases on the floa]"Rick > McGuire" ---09/11/2008 08:49:33 AM---I was just playing around with some > edge cases on the float/double argument support. There are some problems > involved with out > > > *"Rick McGuire" <[EMAIL PROTECTED]>* > Sent by: [EMAIL PROTECTED] > > 09/11/2008 08:49 AM > Please respond to > Open Object Rexx Developer Mailing List < > [email protected]> > > > To > > "Open Object Rexx Developer Mailing List" < > [email protected]> > cc > > > Subject > > [Oorexx-devel] To infinity, and beyond.... > I was just playing around with some edge cases on the float/double argument > support. There are some problems involved with out-of-range values that need > to be addressed and they should be addressed consistently. There are > basically two issues. 1) How to deal with values getting passed out as > arguments and 2) Dealing with the edge cases of values getting passed back > in. > > On outbound values, the code for doubles is checking to see if the > converted value is +infinity or -infinity, and raises an error in either > case. ooRexx numbers outside of the valid range result in that, so an error > is raised. Float, on the other hand, calls the double conversion routine and > then casts the double value to a float. There's no checking for the > infinities at this boundary, so the infinities will get passed as arguments > in the float case. Easy enough to add a check so this is consistent, but > this begs the question of whether we might actually want to allow the > infinity values to get passed through. My gut instinct is no, and it's > generally easier to lift an restriction than to impose one at a later time, > so it can't hurt to keep this an error. An error is also consistent with how > integer value arguments are handled. > > The other issue is how we should be dealing with these edge values when > they are a return value. Currently, there are no return value cases that > result in an error getting raised. I also had to deal with one of the edge > cases with RxMath already, since nan gets returned by some of the library > functions. This used to be somewhat inconsistent because it depended upon > how the underlying libraries worked. On Windows, the nan cases returned the > string "ERROR" and on Linux you got the string "nan". I fixed this in the > infrastructure by having a nan value map to the character string "nan". I > can do the same for "+infinity" and "-infinity" in the infrastructure if we > agree that's the desired behavior. Right now, it appears that at least for > the float tests, a returned infinity is getting formatted as a "1", which is > definitely not a correct result. > > So, to sumerize, the questions are: > > 1) How should out of range double and float arguments be handled? > 2) How should we handle nan, +infinity and -infinity as return values. > > Rick > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Oorexx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Oorexx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > >
<<graycol.gif>>
<<ecblank.gif>>
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
