On 7/21/26 16:08, Bradley Lucier wrote:
> 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.

CHICKEN 6 and Chibi currently agree with Gambit in this regard.

Maybe it would be a better to leave it unspecified if the zero needs to
be exact or not. This is apparently the case with the R7RS-Small due to
it not being written as the group intended it. It is also the de-facto
case, and at least it doesn't force the incorrect behavior. (It's
similar to how the reports moved from the empty list being false to
being true, not that I was even alive to witness it.)

I'm leaning towards exporting `real?`, `integer?`, etc. from this SRFI
as the R6RS procedures (exact zero imaginary part), and ditching the
`strictly-` and non-`strictly-` dichotomy.

> 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.
Thank you for the example. I'll look more into it. I assume it's this
behavior?

     (expt -1 1/3) => 1/2+.8660254037844386i

I will also add a suggestion to this SRFI that implementations should
support mixed exactness complex numbers. (The SRFI specifically is
designed for both R7RS-Small implementations, that might be limited in
their numeric tower, and for R7RS-Large integration. For the R7RS-Small
implementations I think recommending mixed-exactness complex numbers is
appropriate, because they might not support complex numbers at all. I
think we will ballot mixed-exactness complex numbers for R7RS-Large.)

-- Peter McGoron