| Date: Tue, 22 Sep 2009 11:23:46 -0400 | From: John Cowan <[email protected]> | | Brian Harvey scripsit: | | > Yes, this /does/ make me feel queasy about the numeric tower. | > WG1 /should/ make it clear that if you have both reals and | > integers then (= 3 3.0) must return true. But I'm willing to be | > meta-inconsistent about this (by which I mean that I'm okay with | > an inconsistency in the charter, but not about an inconsistency | > in Scheme). | | R6RS (and I presume large Scheme) mandates the whole tower. Should | small Scheme? I don't know. My thoughts, which don't amount to a | proposal yet, are that fixnum-only Schemes are just toys, and that | the following types are reasonable alternatives for a small Scheme: | | 1) Fixnums + bignums (exact integers only) | | 2) Fixnums + flonums (limited range and precision types only) | | 3) Fixnums + bignums + flonums | | 4) 3 + ratios (all numbers are real) | | 5) Fixnums + flonums + compnums (2 with inexact complex numbers) | | 6) The whole tower
SCM supports fixnums + bignums + flonums + compnums. SCM deliberately doesn't support exact-ratios or mixed exactness compnums. Mixed exactness compnums are an anathema to my mathematical sensibilities -- I will vote against any proposal which requires them of an implementation. Why no ratios? Let me explain: Shortly after bignums get implemented in SCM, I found that SCM started seizing while I was debugging programs; no segfault, just hung. Eventually I found that these seizures were in fact bignum arithmetic creating larger and larger numbers because a loop test had the wrong polarity. My solution was to limit the number of bits in a bignum, in SCM's case 16000. Why this limit? Bignum operations have widely varying asymptotic time requirements. SCM's multiplication is O(N^2). So repeated doubling of a bignum value can quickly generate numbers which would outlast anyone's patience to multiply. To the extent possible, I want SCM's primitive operations to take bounded time and space. 1600 bits is adequate to do any cryptographic calculation for the next several years. The only people doing larger bignum calculations are Number Theorists; and they need asymptotically faster multiplication and division algorithms for their huge numbers. There are numerical packages devoted to Number Theory. Why no ratios? When I was porting numerical code to a full-numeric-tower implementation I found that the program was running much more slowly than it did in SCM and sometimes hanging. I eventually tracked down the problem to higher and higher precision exact-rational numbers being generated by ratnum code from a computation like (set! foo (* foo (/ 3 5))). It was either that the numbers required more and more storage, or that the GCDs between numerator and denominator were taking longer and longer. In any case, limits on the size of numerator and denominator are much less intuitive than limits on integer magnitude. And exact-rational support is halfbaked: (expt 27 1/3) should return exact 3, but doesn't in the implementations I have tried. _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
