RE: How to handle crashes?
- Posted by rforno at tutopia.com Jun 09, 2003
- 537 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! > >