OpenEuphoria

Re: How to handle crashes?

• Posted by Juergen Luethje <j.lue at gmx.de> Jun 07, 2003
• 432 views

Hi Jim, you wrote:

> On Sat, May 31, 2003 at 08:25:41PM +0200, Juergen Luethje wrote:
>>
>>
>> Hi Jim, you wrote:
>>
>> <snip>
>>
>>> It's an interesting suggestion. I'd think, that 1/0 should return nan, that
>>> invalid assignments to variables would simply be ignored, and that invalid
>>> slices of a sequence would return {} ... but those are just the details.
>>>
>>> The basic concept, looks ok to me, tho it seems to be not the best way. My
>>> lib
>>> will just flatly return -1 on error, and then you have to check the variable
>>> eu_errno to see what the error was (you'd have to check eu_errno every time
>>> if -1 is a valid return value btw).
>>
>> That's exactly the reason, why I'd prefer using a value as a flag for an
>> invalid result, that never can be a valid number or sequence (such as
>> NIL/NAN/UNKNOWN/UNDEFINED), rather than -1. This is especially important
>> for writing generic routines.
>
> Yes, but its very hard to find one like that.
>
> I used to like to do what DC did in Py:
>
> global constant UNDEFINED = {-102354, -102354}
>
> He called it PyUndef and used different numbers tho, but the general concept
> (use an ugly looking sequence that is unlikely to every be a valid result)
> still works.

Yes. Some time ago, I had the idea of using
   global constant UNKNOWN = {"UnkNOWn"}

>> That's why I was happy when I discovered, that NAN can be returned from
>> user defined functions.
>
> Shouldn't have, since NAN can be a perfectly valid return value.
>
>> And that's why I was unhappy, when I recently
>> read on this list, that this self-defined NAN can't be used reliable.
>
> The reason behind that, is that there is more than one NAN.
>
> You can get a NAN from tan(), power(), -inf/inf, ...
>
> And, each way of calculating NAN gives a different NAN.

Interesting, thank you!
Now I know, that I didn't know too much about NAN.

> What should be done, is to do this.
>
> global constant
> divNAN = -inf/inf,
> powNAN = power(2, inf),
> tanNAN = --however you get a NAN from tan()

Because of tan(x) = sin(x)/cos(x),
tan(x) is undefined, if cos(x) = 0 (i.e. for x = .., -PI/2, PI/2, 3*PI/2, ..).
BTW: With Euphoria, 'cos(PI/2)' does *not* return 0.

> ...etc for every possible way of calculating NAN.

I also found the following 

   addNAN = inf + (-inf)
   mulNAN = 0 * inf
   remNAN = remainder(inf, 1)

> So, that, divNAN is reliable when using NANs from division, but not with
> comparisons
> to tanNANs, for example.
>
> Then, you can choose one NAN, to use as the return value ... as long as its
> always the same NAN there is no problem. (Except of course, that NAN could be
> a valid return value ... but so could {-102354, -102354}, so theres no good
> way of getting around that.)

In "What Every Computer Scientist Should Know About Floating-Point Arithmetic"
<http://docs.sun.com/source/806-3568/ncg_goldberg.html>, David Goldberg
writes, that the IEEE recommends a function Isnan(). In my imagination,
this function would return TRUE for *any* NAN, and so help with this
issue, right?

Best regards,
   Juergen

-- 
 /"\  ASCII ribbon campain  |
 \ /  against HTML in       |  This message has been ROT-13 encrypted
  X   e-mail and news,      |  twice for higher security.
 / \  and unneeded MIME     |