|
Comments
Bradley Lucier
(20 Jul 2026 21:14 UTC)
|
|
Re: Comments
John Cowan
(20 Jul 2026 22:40 UTC)
|
|
Re: Comments
Bradley Lucier
(21 Jul 2026 00:43 UTC)
|
|
Re: Comments
Peter McGoron
(21 Jul 2026 02:58 UTC)
|
|
Re: Comments
Bradley Lucier
(21 Jul 2026 20:11 UTC)
|
|
Re: Comments
Peter McGoron
(21 Jul 2026 14:53 UTC)
|
|
Re: Comments Bradley Lucier (21 Jul 2026 20:09 UTC)
|
|
Re: Comments
Marc Feeley
(21 Jul 2026 21:43 UTC)
|
|
Re: Comments
Peter McGoron
(22 Jul 2026 02:43 UTC)
|
|
Re: Comments
Bradley J Lucier
(22 Jul 2026 02:59 UTC)
|
Thank you for your responses. On 7/21/26 10:50, Peter McGoron wrote: > > On 7/20/26 17:13, Bradley Lucier wrote: >> I think we're piling complexity on complexity to accommodate what I >> consider to be some implementations' limitations (no mixed-exactness >> complex numbers). > > I agree. However, my wish for real? etc. to have the R6RS definitions > was voted down in the Working Group. Exporting the more correct > definitions under a different name allows programmers to use those > definitions, and hopefully we can modify the definitions in a future > Report. (Then people can use the import renaming facility to port their > code.) We're now looking at nearly 30 years of complexity to accommodate a decision made in a standard (R5RS) that might have matched a few implementations at the time, but of which few people might have truly cared. I'm beginning to see some of the benefit that Racket has from not claiming to be Scheme. And, to be honest, I can't see Gambit adopting some of the definitions (like defining (real? x) to be (zero? (imag? x))) and conventions while I'm doing the numerics there. Perhaps we'll just document the exceptions, I don't know. But that's up to Marc, and neither I nor Marc will live forever so it probably doesn't matter all that much. > > If you have this rule and allow mixed exactness complex numbers, then > the problems of (* +i (* +i (* +i (* +i z)))) not being z goes away. Let's get back to this for a minute, specifically, to quote your original language: ======================= 2. Many implementations widen real arguments to have a +0i (or +0.0i) imaginary part when multiplying them with complex numbers. This causes some unfortunate issues, such as (* 1 z) and (* +i (* +i (* +i (* +i z)))) not being the identity when passed a complex number with infinities or NaNs. ======================= The question here is, what does "not being the identity" mean, specifically in a Scheme context? Does it mean the same object? That the two things are eq? Probably not. Does it mean that the two numbers are =? Do you think (* 1 +1.i) being 0.+1.i is OK? or being -0.+1.0i is OK? I'd say not. And now I'm getting strong vibes of what Kahan used to complain about before the IEEE floating-point standards, about machines where 1.*x did not equal x, or where x = y is true, but x-y is not zero. I'd say that "not being the identity" means that the numbers are not eqv?, and I take two numbers to be eqv? if you can substitute them into any combination of Scheme procedures other than eq? and get the same answer. Because 0.+1.i is not "substitutable" for +1.i so (* 1 +1.i) should not return 0.+1.i. So I'd have a problem with (* +i (* +i (* +i (* +i 1.0)))) being 1.0+0.0i. And that's not getting into the problem that you want (* 1.0 +inf.0+0.0i) to be +inf.0+0.0i, and if the 1.0 is lifted to complex 1.0+0.0i) you get (* 1.0+0.0i +inf.0+0.0i), which is +inf.0+nan.0i. > Is there a major benefit to having general mixed exactness complex > numbers, versus having imaginary numbers (a special case of mixed > exactness complex numbers)? That might be easier for people to implement. Now, this is in some ways a natural question, but it's the kind of question that Kahan would come down hard on in the context that concerned him, which was complex numbers with both parts floating-point numbers. (I don't mean to speak for Kahan here, just how I interpret his writings.) And the question he would come down hard on would have been "Does it really matter whether an argument or a result should distinguish between +0. and -0. in an arithmetic with signed zeros?" (I can be pretty sure about this because he entitled a paper basically with this question.) And to him the answer was yes. His paper also considers algorithms with arithmetics that have only an *unsigned* zero; these are in some cases subtly different. But I have not come across any place where he considers routines for arithmetic with three zeros, +0., -0., and unsigned zero (which I'm not going to write as 0. for now). But this is precisely the situation in Gambit (and other Schemes) with mixed exactness complex numbers, because a real or imaginary part could be floating-point +0. or -0. or exact integer 0. So I tried to adapt his routines to this mixed situation. To answer your question directly, the Gambit routine for (expt x y) returns results that might have an exact nonzero real or imaginary part and an inexact nonzero real or imaginary part in the special case when x is negative and y is a fraction with denominator 3 or 6. I'm not Kahan, so I cannot come up with better examples at the current moment. Brad