Don't have any great insight here but just wanted to be sure we keep in mind Mike's decimal arithmetic changes that we will be supporting eventually. I.e. let's not do something here that makes that support more difficult or incompatible when we do it.
Rick McGuire wrote: > 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 -- Gil Barmwater ------------------------------------------------------------------------- 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
