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
"Rick McGuire"
<[EMAIL PROTECTED]
l.com> To
Sent by: "Open Object Rexx Developer Mailing
oorexx-devel-boun List"
[EMAIL PROTECTED] <[email protected]
orge.net >
cc
09/11/2008 08:49 Subject
AM [Oorexx-devel] To infinity, and
beyond....
Please respond to
Open Object Rexx
Developer Mailing
List
<[EMAIL PROTECTED]
ts.sourceforge.ne
t>
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
<<inline: graycol.gif>>
<<inline: pic24873.gif>>
<<inline: 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
