On Wed, 30 Apr 2014 13:52:48 PDT Bear <[email protected]> wrote: > On Mon, 2014-04-28 at 23:48 -0400, John Cowan wrote: > > > 1) Should R7RS-large require arbitrarily large (up to implementation > > restrictions like memory) exact integers? > > It should require exact integers. It should encourage range > limits much higher than typical programming languages. It > should not require an implementation to exhaust all memory > and crash in an attempt to represent a very large exact integer.
I translate this to mean this: An implementation neeeds to specify this limit in a symbolic constant in some form. It should probably be a pair (x y) to indicate x^y (otherwise just the "constant" will eat up all memory!). > > 2) Should R7RS-large require support for exact rational numbers? > > It should require exact ratios. It should not require an > implementation to exhaust all memory and crash in an attempt > to represent a very precise ratio. Ditto. > > 3) Should R7RS-large require support for exact complex numbers? > > Previously I voted 'yes' subject to the same representation limits > as other exact numbers. But as I consider this there's an issue. > > I would vote 'yes' for consistency with the rest of the numeric > tower, but it is hard to say exactly what a 'yes' here means in > the absence of any constraint on whether the exact numbers > represented are, eg, stored in polar or cartesian format, or in > some union that could be either, and if in polar format whether > the angle measurement is given in radians (either directly or as > some product of pi like degrees), or as a slope ratio. I have difficulty imagining the usefulness of "exact" polar representation. Seems to me, if you do allow exact complex numbers, for polar<->cartesian conversion you would need big-floats. But must admit I am unclear about what "target audience or market" R7RS-large is being designed for. I use it to solve practical problems or for exploratory programming, in place of perl/python/ruby/language-du-jour :-) _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
