From: Raymond T. <ray...@er...> - 2008-11-26 18:38:20
|
Consider this: (let ((x (complex 0.0))) (check-type x complex)) I believe CL must return NIL here, but clisp produces an error that X is not of type COMPLEX. I understand why clisp does this, but this is valid ANSI code that ought to work. Should there be (yet another!) flag control how complex contagion works, like there is for float contagion? Ray |
From: Sam S. <sd...@gn...> - 2008-11-26 20:34:44
|
Raymond Toy wrote: > Consider this: > > (let ((x (complex 0.0))) > (check-type x complex)) > > I believe CL must return NIL here, but clisp produces an error that X > is not of type COMPLEX. > > I understand why clisp does this, but this is valid ANSI code that > ought to work. > > Should there be (yet another!) flag control how complex contagion > works, like there is for float contagion? looks like it. what does this have to do with "contagion"? I think the flag should be *complex-ansi* or *complex-imagpart=0-ansi* |
From: Raymond T. <toy...@gm...> - 2008-11-26 22:06:14
|
Sam Steingold wrote: > Raymond Toy wrote: > >> Consider this: >> >> (let ((x (complex 0.0))) >> (check-type x complex)) >> >> I believe CL must return NIL here, but clisp produces an error that X >> is not of type COMPLEX. >> >> I understand why clisp does this, but this is valid ANSI code that >> ought to work. >> >> Should there be (yet another!) flag control how complex contagion >> works, like there is for float contagion? >> > > looks like it. > what does this have to do with "contagion"? > Because I was looking at clhs #C entry and it refers to contagion in numeric operations. So it's not complex contagion, but is it float contagion. I assume that if the flag is set, the complex numeric stuff in imp notes will also have to be changed to reflect this. Ray |
From: Sam S. <sd...@gn...> - 2008-11-26 22:25:07
|
Raymond Toy wrote: > Sam Steingold wrote: >> Raymond Toy wrote: >>> >>> (let ((x (complex 0.0))) >>> (check-type x complex)) >>> >>> I believe CL must return NIL here, but clisp produces an error that X >>> is not of type COMPLEX. >>> >>> I understand why clisp does this, but this is valid ANSI code that >>> ought to work. >>> >>> Should there be (yet another!) flag control how complex contagion >>> works, like there is for float contagion? >>> >> looks like it. >> what does this have to do with "contagion"? >> > Because I was looking at clhs #C entry and it refers to contagion in > numeric operations. So it's not complex contagion, but is it float > contagion. > > I assume that if the flag is set, the complex numeric stuff in imp notes > will also have to be changed to reflect this. on a second thought (and the first reading of http://www.lispworks.com/documentation/HyperSpec/Body/f_comp_2.htm), clisp is fine. clisp extends the COMPLEX type to hold different types in real and imaginary parts, and the behavior you observe is consistent with this extension. note that COMPLEX is permitted to return a rational (not a complex), so (let ((x (complex 0))) (check-type x complex)) will signal an error in a compliant implementation. I think this is on par with PI not being a constant (because it changes when long-float-digits is modified), i.e., the behavior you observe is a side effect of an extension. |
From: Raymond T. <toy...@gm...> - 2008-11-27 00:49:39
|
Sam Steingold wrote: > Raymond Toy wrote: >> Sam Steingold wrote: >>> Raymond Toy wrote: >>>> >>>> (let ((x (complex 0.0))) >>>> (check-type x complex)) >>>> >>>> I believe CL must return NIL here, but clisp produces an error that X >>>> is not of type COMPLEX. >>>> >>>> I understand why clisp does this, but this is valid ANSI code that >>>> ought to work. >>>> >>>> Should there be (yet another!) flag control how complex contagion >>>> works, like there is for float contagion? >>>> >>> looks like it. >>> what does this have to do with "contagion"? >>> >> Because I was looking at clhs #C entry and it refers to contagion in >> numeric operations. So it's not complex contagion, but is it float >> contagion. >> >> I assume that if the flag is set, the complex numeric stuff in imp notes >> will also have to be changed to reflect this. > > on a second thought (and the first reading of > http://www.lispworks.com/documentation/HyperSpec/Body/f_comp_2.htm), > clisp is fine. > clisp extends the COMPLEX type to hold different types in real and > imaginary parts, and the behavior you observe is consistent with this > extension. > note that COMPLEX is permitted to return a rational (not a complex), so > > (let ((x (complex 0))) > (check-type x complex)) > > will signal an error in a compliant implementation. > But the section on complex says complex returns either a rational or a complex. (complex 0.0) returns neither. Ray |
From: Sam S. <sd...@gn...> - 2008-11-27 01:48:04
|
> * Raymond Toy <gbl.enlzbaq@tznvy.pbz> [2008-11-26 19:49:25 -0500]: > Sam Steingold wrote: >> Raymond Toy wrote: >>> Sam Steingold wrote: >>>> Raymond Toy wrote: >>>>> >>>>> (let ((x (complex 0.0))) >>>>> (check-type x complex)) >>>>> >>>>> I believe CL must return NIL here, but clisp produces an error that X >>>>> is not of type COMPLEX. >>>>> >>>>> I understand why clisp does this, but this is valid ANSI code that >>>>> ought to work. >>>>> >>>>> Should there be (yet another!) flag control how complex contagion >>>>> works, like there is for float contagion? >>>>> >>>> looks like it. >>>> what does this have to do with "contagion"? >>>> >>> Because I was looking at clhs #C entry and it refers to contagion in >>> numeric operations. So it's not complex contagion, but is it float >>> contagion. >>> >>> I assume that if the flag is set, the complex numeric stuff in imp notes >>> will also have to be changed to reflect this. >> >> on a second thought (and the first reading of >> http://www.lispworks.com/documentation/HyperSpec/Body/f_comp_2.htm), >> clisp is fine. >> clisp extends the COMPLEX type to hold different types in real and >> imaginary parts, and the behavior you observe is consistent with this >> extension. >> note that COMPLEX is permitted to return a rational (not a complex), so >> >> (let ((x (complex 0))) >> (check-type x complex)) >> >> will signal an error in a compliant implementation. >> > But the section on complex says complex returns either a rational or a > complex. (complex 0.0) returns neither. yes, and if ANSI CL supported (complex float rational), it would have said that COMPLEX returns a real or a complex. what I am trying to say is that what you observe is a part of the CLISP (COMPLEX t t) type extension which is hard to make optional - about as hard as ripping out the arbitrary precision floats, and about as useful. however, in keeping with out ANSI compliance commitment, http://www.cygwin.com/acronyms/#PTC -- Sam Steingold (http://sds.podval.org/) on Ubuntu 8.10 (intrepid) http://thereligionofpeace.com http://jihadwatch.org http://honestreporting.com http://openvotingconsortium.org http://mideasttruth.com UNIX, car: hard to learn/easy to use; Windows, bike: hard to learn/hard to use. |
From: Raymond T. <toy...@gm...> - 2008-11-27 13:57:29
|
Sam Steingold wrote: >> * Raymond Toy <gbl.enlzbaq@tznvy.pbz> [2008-11-26 19:49:25 -0500]: >> >>> on a second thought (and the first reading of >>> http://www.lispworks.com/documentation/HyperSpec/Body/f_comp_2.htm), >>> clisp is fine. >>> clisp extends the COMPLEX type to hold different types in real and >>> imaginary parts, and the behavior you observe is consistent with this >>> extension. >>> note that COMPLEX is permitted to return a rational (not a complex), so >>> >>> (let ((x (complex 0))) >>> (check-type x complex)) >>> >>> will signal an error in a compliant implementation. >>> >>> >> But the section on complex says complex returns either a rational or a >> complex. (complex 0.0) returns neither. >> > > yes, and if ANSI CL supported (complex float rational), it would have > said that COMPLEX returns a real or a complex. > This is makes sense. > what I am trying to say is that what you observe is a part of the CLISP > (COMPLEX t t) type extension which is hard to make optional - about as > hard as ripping out the arbitrary precision floats, and about as useful. > Wouldn't most of the issues be fixed just by making COMPLEX apply float contagion on the components? > however, in keeping with out ANSI compliance commitment, > "out" or "our"? Ray |
From: Hoehle, Joerg-C. <Joe...@t-...> - 2008-11-28 13:12:05
|
Hi, > * Raymond Toy <gbl.enlzbaq@tznvy.pbz> [2008-11-26 19:49:25 -0500]: > (let ((x (complex 0.0))) > (check-type x complex)) > I believe CL must return NIL here, but clisp produces an > error that X is not of type COMPLEX. > I understand why clisp does this, but this is valid ANSI > code that ought to work. It's not just ANSI nitpicking. Contagion issues also affect FFI code. E.g. I remember when testing IIRC cl-sdl with my UFFI wrapper macros that I got some run-time errors because either a) some defclass slot had :type FLOAT specifications, or b) FFI types said FLOAT. The FFI errors out when given an integer 0 instead. Initially, to run the cl-sdl demos, I took the short-circuit and set the *CONTAGION* variable. IIRC later I located all relevant code and added COERCE, because the *CONTAGION* is a *global* variable and some library like cl-sdl should not depend on it. Or how would you mix that with another library B that expects settings the other way round? Wrapping all cl-sdl calls inside (let ((*CONTAGION* :ANSI)) #) also does not work in the presence of callbacks, which might again call library B. Global variables are just a hindrance in the way to system construction. Regards, Jorg Hohle |
From: Sam S. <sd...@gn...> - 2008-11-27 14:35:19
|
> * Raymond Toy <gbl.enlzbaq@tznvy.pbz> [2008-11-27 08:57:20 -0500]: > >> what I am trying to say is that what you observe is a part of the CLISP >> (COMPLEX t t) type extension which is hard to make optional - about as >> hard as ripping out the arbitrary precision floats, and about as useful. > Wouldn't most of the issues be fixed just by making COMPLEX apply float > contagion on the components? "most of the issues"? what are the issues? I don't see any. what I do see is a valuable and useful extension of the standard. E.g., in CLISP, (- (complex (* 2 pi) 4) (complex pi 4)) is a real number pi, while in a compliant lisp it would be #C(pi 0L0). I think the CLISP behavior is preferable. yes, it can be detected by the code you posted, but I really don't see any reasonable application using such code. can you offer an ENGINEERING reason to limit complex number in the standard way (e.g., the contagion rules do have an engineering rationale behind them, see the impnotes)? >> however, in keeping with out ANSI compliance commitment, > "out" or "our"? `our', sorry -- Sam Steingold (http://sds.podval.org/) on Ubuntu 8.10 (intrepid) http://israelunderattack.slide.com http://iris.org.il http://ffii.org http://jihadwatch.org http://openvotingconsortium.org http://memri.org Lisp is not dead, it just smells funny. |
From: Raymond T. <toy...@gm...> - 2008-11-27 15:31:19
|
Sam Steingold wrote: >> * Raymond Toy <gbl.enlzbaq@tznvy.pbz> [2008-11-27 08:57:20 -0500]: >> >> >>> what I am trying to say is that what you observe is a part of the CLISP >>> (COMPLEX t t) type extension which is hard to make optional - about as >>> hard as ripping out the arbitrary precision floats, and about as useful. >>> >> Wouldn't most of the issues be fixed just by making COMPLEX apply float >> contagion on the components? >> > > "most of the issues"? > what are the issues? > You said it would be hard to make optional. I merely suggested you only need to make COMPLEX different. But I have no knowledge if that is true or not. > I don't see any. > what I do see is a valuable and useful extension of the standard. > > E.g., in CLISP, > > (- (complex (* 2 pi) 4) (complex pi 4)) > > is a real number pi, while in a compliant lisp it would be #C(pi 0L0). > 2*pi - pi isn't necessarily pi, but I get your point. But a "compliant" lisp would be #c(pi 0l0). It's your choice if you want to a compliant lisp or not. Isn't this why for a long time float contagion was different, until the ansi float contagion flag was added? > > >>> however, in keeping with out ANSI compliance commitment, >>> >> "out" or "our"? >> > > `our', sorry > > Maybe "out" was actually correct. :-) I accept your arguments to keep things as is, and that's fine with me. But you don't get both to claim a desire for compliance and to willingly choose non-compliance. :-) Ray |
From: Sam S. <sd...@gn...> - 2008-11-27 16:18:01
|
> * Raymond Toy <gbl.enlzbaq@tznvy.pbz> [2008-11-27 10:31:09 -0500]: >> what are the issues? > You said it would be hard to make optional. I merely suggested you only > need to make COMPLEX different. But I have no knowledge if that is true > or not. it is not consistent to change COMPLEX and keep the main feature. > a "compliant" lisp would be #c(pi 0l0). It's your choice if you want > to a compliant lisp or not. Isn't this why for a long time float > contagion was different, until the ansi float contagion flag was > added? as I said in a previous message, there is a solid engineering reason to do float contagion the standard way. see the impnotes. as I already asked in a previous message, what is the engineering reason to require complex number to have the same type of real and imaginary parts? > But you don't get both to claim a desire for compliance and to > willingly choose non-compliance. :-) please read the FAQ on ANSI compliance again. I will not spend my valuable time on adding a feature I consider to be useless. however, as I said before, http://www.cygwin.com/acronyms/#PTC I don't see this discussion progressing anywhere unless you either - convince me that there is a technical, engineering reason why (COMPLEX integer float) should not be allowed, in which case I will add the feature you are asking about in my CFT - OR submit a patch yourself. -- Sam Steingold (http://sds.podval.org/) on Ubuntu 8.10 (intrepid) http://mideasttruth.com http://iris.org.il http://truepeace.org http://jihadwatch.org http://pmw.org.il http://openvotingconsortium.org If a cat tells you that you lost your mind, then it is so. |
From: Raymond T. <toy...@gm...> - 2008-11-27 16:31:47
|
Sam Steingold wrote: >> * Raymond Toy <gbl.enlzbaq@tznvy.pbz> [2008-11-27 10:31:09 -0500]: >> >>> what are the issues? >>> >> You said it would be hard to make optional. I merely suggested you only >> need to make COMPLEX different. But I have no knowledge if that is true >> or not. >> > > it is not consistent to change COMPLEX and keep the main feature. > I meant if you added the flag. I'm not proposing you change it completely. You're free to do whatever you feel like. Ray |
From: Bruno H. <br...@cl...> - 2008-12-07 14:39:50
|
Sam Steingold wrote: > what does this have to do with "contagion"? (complex 0.0) is equivalent to (complex 0.0 0). With ANSI-CL contagion rules, the imaginary part becomes 0.0, and therefore the result is #c(0.0 0.0). With CLISP contagion rules, the imaginary part stays 0, an exact zero, therefore the result is 0.0. > > (let ((x (complex 0.0))) > > (check-type x complex)) Either you run clisp in ANSI mode, with all its drawbacks, or update this code to not assume the ANSI CL idiosyncracies. What is this code trying to accomplish? Why (check-type x complex) since you cannot destructively modify the realpart and imagpart of a complex number? Bruno |
From: Raymond T. <toy...@gm...> - 2008-12-07 15:02:49
|
Bruno Haible wrote: > > >>> (let ((x (complex 0.0))) >>> (check-type x complex)) >>> > > Either you run clisp in ANSI mode, with all its drawbacks, or update > this code to not assume the ANSI CL idiosyncracies. > > What is this code trying to accomplish? Why (check-type x complex) since > you cannot destructively modify the realpart and imagpart of a complex number? > > Nothing. It was just a simple example illustrating what I thought was a bug. But I accept clisp's extension of the spec in this area. Ray |