Re: SRFI-77 with more than one flonum representation William D Clinger (26 Jun 2006 23:31 UTC)
Re: SRFI-77 with more than one flonum representation Alan Watson (29 Jun 2006 16:13 UTC)
Re: SRFI-77 with more than one flonum representation John Cowan (30 Jun 2006 15:03 UTC)
Re: SRFI-77 with more than one flonum representation Alan Watson (03 Jul 2006 16:16 UTC)
Re: SRFI-77 with more than one flonum representation Michael Sperber (05 Jul 2006 18:26 UTC)
Re: SRFI-77 with more than one flonum representation Michael Sperber (05 Jul 2006 18:28 UTC)
Re: SRFI-77 with more than one flonum representation Alan Watson (03 Jul 2006 16:17 UTC)

Re: SRFI-77 with more than one flonum representation John Cowan 30 Jun 2006 15:03 UTC

Alan Watson scripsit:

> The only motivation for the flonum-specific part of SRFI 77 seems to be
> efficiency. Thus, in implementations that have more than one
> floating-point representation, one either has to sacrifice efficiency or
> priviledge one representation. Thus, the motivation of SRFI 77 would in
> this case encourage an implementor to bestow priviledged status on a
> particular representation.

I think the burden of persuasion now lies on you (or someone else in
your position) to show that:

1) there are still significant architectures in which different kinds
of floating-point numbers represent a significant tradeoff (as was
historically the case, single-float being faster but less precise and
with a smaller range), such that it does not make sense to privilege
one over the other; and that

2) this feature warrants support, even if halfhearted, from the Scheme
standard rather than being left as implementation-dependent.

I believe this will be a difficult burden to meet.

(I exclude here the matter of bulk storage: SRFI-4 shows that single-float
arrays may still make sense even if all arithmetic is done in double.)

> Forgive me if I put words into your mouth, but you seem to be saying
> that existing implementations use only one floating-point
> representation, therefore it is okay to standardize interfaces that are
> well-adapted to such implementations but ill-adapted to implementations
> that might use more than one floating-point representation.

I think this overstates the case: SRFI-77 is ill-adapted to implementations
that not only provide more than one representation but have no clear-cut
preference between them.

--
John Cowan    http://ccil.org/~cowan  xxxxxx@ccil.org
The Penguin shall hunt and devour all that is crufty, gnarly and
bogacious; all code which wriggles like spaghetti, or is infested with
blighting creatures, or is bound by grave and perilous Licences shall it
capture.  And in capturing shall it replicate, and in replicating shall
it document, and in documentation shall it bring freedom, serenity and
most cool froodiness to the earth and all who code therein.  --Gospel of Tux