For the benefit of people who are only on WG2, and won't have seen Jay's
message, I'm preserving it in its entirety in this reply.

Jay Freeman scripsit:

> A fascinating set of questions; I have several observations.  I hope
> people will forgive me if I use an obsolete R5 term by mistake, Wraith
> Scheme -- my implementation -- stopped there ...

No problem:  R7RS-small mostly uses the same terminology as R5RS.

> First, regarding questions (3) and (4), I suggest that John's
> posting inadvertently and unnecessarily conflates fixnum/flonum with
> exact/inexact.

I shouldn't have brought up IEEE floats in connection with (4) at all.

> Thus it is certainly possible to imagine a complex number whose real
> and imaginary parts are both inexact and both happen to be stored as
> fixnums, and it is also possible to imagine a complex number whose
> real and imaginary parts are both exact and both happen to be stored
> as flonums.

"Fixnum" and "flonum" aren't really R5RS/R7RS terminology: they refer to
common implementation strategies for limited-range exact integers and
limited-range inexact rationals respectively.

> (E.g., a user could type (make-rectangular #i2 #i3) or
> (make-rectangular #e2.1 #e4.7). Users do the strangest things ...)

I assume that #i2 would be stored as a flonum and #e2.1 as a ratio.
So the first complex number would be inexact and made of two flonums,
and the second complex number would be exact and made of ratios if the
Scheme supports exact complex numbers, or else inexact and made of two
flonums if it does not.

> I conjecture that John meant to ask whether the domain of the real and
> imaginary parts of complex numbers should be restricted to numbers
> that can be stored as integers in the range, say of 24-bit signed
> ints.

Not at all.  I was quite literally asking whether exact non-real numbers
should be required and whether inexact non-real numbers should be
required.  Some Schemes provide both, some one, some the other, some
neither.

> Second, and similarly, regarding questions (2) and (1), there is no
> conceptual reason to eschew inexact rationals or inexact integers.

Having inexact rationals implies having inexact integers.

> A user can always construct inexact integers, and may divide two of
> them.  Read again about how users do the strangest things ...

The result would be an inexact rational, unless the Scheme doesn't have
inexact rationals, in which case an implementation restriction would be
reported.  I am presuming, however, that R7RS-large will require the
presence of inexact rationals, typically as flonums.

> Third, regarding question (1), there is a substantial can of worms
> opened when you have bignums available and are worried about exactness
> or precision.  For example, suppose you have two numbers x and y which
> happen to be stored as flonums, and whose absolute values are so large
> that if you multiply them the result will overflow the range of your
> kind of flonum.  Then there are at least a couple of choices for what
> (* x y) should do, namely
>
>     (A) Return an inf.
>
>     (B) Coerce both x and y to bignums and return their bignum
>     product.

No, you can't do (B) unless you have some way of marking the bignums as
inexact, which most implementations don't.  The product of two inexact
numbers must be inexact, modulo special cases.

>     Note that if you have sufficiently large bignums as to run out of
>     memory, you may have to return an inf anyway.

Quite so.  If an implementation can't return an exact result, it may
raise an implementation restriction or silently return an inexact
number.

> In regard to (B), I shouldn't have to say, but I will say anyway, that
> any flonum of sufficiently large absolute value necessarily represents
> an integer -- if the exponent shifts the binary point past the right
> end of the significand, integer it must be, though those who want to
> argue may challenge this point if the sticky bit is set.
>
> This point is particularly telling if both x and y are specified as
> exact, for in that case we have two exact ints (albeit stored as
> flonums), and a system that is perfectly capable of multiplying them
> and returning an exact result.  Shouldn't we do that?

If they are exact, then yes, you should.  But in general, multiplying an
integral flonum by another integral flonum does not give an exact result
if the product exceeds 2^53 (assuming IEEE 64-bit binary).

> And even if they are not exact, doesn't such a coercion do the right
> thing in terms of preserving as much information about the result of
> the multiplication as possible?

No.  Multiplying an inexact value by an inexact value can't give an
exact value.

> At this point, I suspect that any Schemers who use the language for
> scientific or engineering calculations will be jumping up and down,
> waving their arms, and saying "NO!!  NO!!  NO!!", if only because of
> the probable slowness of repeatedly multiplying bignums of, say, a few
> thousand digits each.  And if I were so foolish as to suggest having a
> mode bit to select whether bignum coercion was forced or forbidden, I
> myself might not survive the experience -- a few of you know where I
> live.
>
> A possibly useful rule might be that a calculation may return a bignum
> result only if at least one of its inputs is a bignum, but I am not
> trying to force the discussion, only to make a suggestion.

We should probably for this purpose eliminate all talk of
representations (bignum, flonum, fixnum, etc. etc.) and only talk of
inexact and exact.

> And I might have kept my mouth shut if I hadn't moved recently.
>
> I look forward to the discussion of this matter.

--
John Cowan          http://www.ccil.org/~cowan        cowan@ccil.org
"After all, would you consider a man without honor wealthy, even if his
Dinar laid end to end would reach from here to the Temple of Toplat?"
"No, I wouldn't", the beggar replied.  "Why is that?" the Master asked.
"A Dinar doesn't go very far these days, Master.        --Kehlog Albran
Besides, the Temple of Toplat is across the street."      The Profit

--
You received this message because you are subscribed to the Google Groups "scheme-reports-wg2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheme-reports-wg2+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.