Arithmetic issues
Michael Sperber
(18 Oct 2005 06:03 UTC)
|
Re: Arithmetic issues
felix winkelmann
(18 Oct 2005 07:00 UTC)
|
Re: Arithmetic issues
John.Cowan
(18 Oct 2005 17:36 UTC)
|
Re: Arithmetic issues
Aubrey Jaffer
(19 Oct 2005 18:13 UTC)
|
Re: Arithmetic issues
John.Cowan
(19 Oct 2005 18:21 UTC)
|
Re: Arithmetic issues
bear
(18 Oct 2005 19:52 UTC)
|
Re: Arithmetic issues
John.Cowan
(18 Oct 2005 21:12 UTC)
|
Re: Arithmetic issues bear (19 Oct 2005 02:13 UTC)
|
Re: Arithmetic issues
John.Cowan
(19 Oct 2005 02:19 UTC)
|
Re: Arithmetic issues
bear
(19 Oct 2005 03:23 UTC)
|
Re: Arithmetic issues
Andre van Tonder
(19 Oct 2005 11:47 UTC)
|
Re: Arithmetic issues
Aubrey Jaffer
(19 Oct 2005 14:14 UTC)
|
Re: Arithmetic issues
Andre van Tonder
(19 Oct 2005 16:00 UTC)
|
On Tue, 18 Oct 2005, John.Cowan wrote: >bear scripsit: > >> I think the problem with that is that you then need to be able to hack >> the reader/writer so as to recognize or write the syntax of rational >> and complex numbers depending on whether the library is loaded. >Writing is not really an issue: the logic can be present even if it is not >used. The lexer has to be able to detect various kinds of potential numbers >anyway so as to be sure they are not identifiers. Hmmm. CL does a pretty good thing here; they have a syntactic entity called a "potential number" and guarantee that no potential number will ever be read as an identifier or non-numeric datum. Potential numbers are a pretty liberal regular expression that all actual number syntaxes are subsets of. And if some implementation wants to provide an extension of the numeric tower, they just need to pick a syntax for their new numeric type that is also a subset of the potential numbers. Then they're guaranteed that no implementation will misread its extended numbers as identifiers. In scheme, on the other hand, it's fairly common for the lexer to treat any entity that doesn't parse as a number as an identifier. This allows some traditional names such as 1+ for functions, but doesn't reserve any lexical space for expansion of the numeric tower. Maybe that behavior should be forbidden. > Ratnums are cheap if you have flonums, as has been shown. I would > like evidence that complex numbers other than complex flonums are > actually useful. Um. Ratnums are cheap if you have bignums. Flonums don't actually get you any significant part of the way toward ratnums. > Even if you waive the fact that flonum and fixnum + and * are not > associative, it's easy to write macros that transmute multiple-argument > versions into 2-argument fx+ and fx*. This is true, but somewhat inconvenient. Bear