[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: wolfgang@mgm.mit.edu (Wolfgang Rupprecht)*Subject*: Re: sqrt/complex bug*From*: quiroz@cs.rochester.edu*Date*: Tue, 24 Nov 87 22:48:27 -0500*Cc*: kcl@rascal.ics.UTEXAS.EDU*In-reply-to*: Your message of Tue, 24 Nov 87 20:21:53 -0500. <8711250121.AA09937@mgm.mit.edu>

Of course, you realize that this reflects the underlying arithmetic (ergo, can hardly be called a KCL bug). I observe the following behavior in a Sun3: >(sqrt -1) #C(-4.371139S-8 1.0S0) >(sqrt -1.0) #C(6.123031769111886E-17 1.0) >(sqrt #C(-1.0 0.0)) #C(6.123031769111886E-17 1.0) Ten-to-the-minus-17 is as close to zero in the real part as I would expect from this machine, especially because the advertised value of long-float-epsilon is 1.110223024625157E-16. Enter Daydreaming-mode: a truly decent symbolic system would, upon seeing its sign, convert the integer argument -1 into the (gaussian-)integer #C(-1 0) and try the square root there, giving the (gaussian-)integer #C(0 1). And, if impossible in QxQ, would only then coerce to floats and try in C. That would be great for Computer Algebra, but *always* looking for the correct algebraic closure will make sqrt too expensive an operation for numerical purposes, so we better not mess with it. =Cesar -------- Cesar Augusto Quiroz Gonzalez Department of Computer Science ...allegra!rochester!quiroz University of Rochester or Rochester, NY 14627 quiroz@cs.rochester.edu

- Prev by Date:
**sqrt/complex bug** - Next by Date:
**Panic** - Previous by thread:
**sqrt/complex bug** - Next by thread:
**Panic** - Index(es):