OpenEuphoria

2. RE: How to handle crashes?

• Posted by rforno at tutopia.com Jun 09, 2003
• 538 views

You know, the set of *all* integers (abstract integers, not Euphoria nor C
nor computer integers) is infinite, but larger than the set of *even*
integers, that is also infinite.
----- Original Message -----
From: <jbrown105 at speedymail.org>
Subject: Re: How to handle crashes?


>
>
> On Sat, Jun 07, 2003 at 07:33:52PM +0200, Juergen Luethje wrote:
> >
> >
> > 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'd work too (tho I think it might be slightly more likely to be a
> program's valid data).
>
> > >> 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.
>
> LOL!
>
> >
> > > 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.
>
> Perhaps its cuz the PI constant isnt accurate enough?
>
> >
> > > ...etc for every possible way of calculating NAN.
> >
> > I also found the following 
> >
> >    addNAN = inf + (-inf)
>
> Why isnt this zero?
>
> x + (-x) == 0, and if x == inf, that should still hold true, or am I
overlooking
> something? (Like, how 2 sets can be of inf size (i.e. are infinite sets)
but
> still have one set larger than the other?)
>
> >    mulNAN = 0 * inf
>
> You'd think that'd be 0 too ... (or maybe it has to do with the 1/inf == 0
and
> 1/0 != inf sort of thing?) /me faintly remembers reading somewhere that
0*inf
> == 1
>
> >    remNAN = remainder(inf, 1)
>
> This one I can understand (barely).
>
> >
> > > 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?
> >
>
> Yes. But we'd have to write our own (unless Rob wants to make such a beast
> builtin, or some wise human decides to wrap a C version via
define_c_func).
>
> > Best regards,
> >    Juergen
> >
>
> Of course, if we used nan, then the error lib would NOT be as usable for,
say,
> a program which did complex floating point math (in which cases NAN might
be a
> valid return value). In that case, that program would still have to do the
> checks anyways.
>
> IOW, since no user-defined value will always be an invalid result or
> value, some programs will still have to do costly checks to be sure that
> no error occurred.
>
> At least my way (using -1), it becomes more of a habit.
>
> Besides, you'd still have to check for procedures (which return no
> value).
>
> jbrown
>
> > --
> >  /"\  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     |
> >
>
> --
>  /"\  ASCII ribbon              | http://www.geocities.com/jbrown1050/
>  \ /  campain against           | Linux User:190064
>   X   HTML in e-mail and        | Linux Machine:84163
>  /*\  news, and unneeded MIME   |
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
>