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)

Re: Comments Bradley Lucier 21 Jul 2026 20:08 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