On 29 Sep 2009, at 5:33 pm, Brian Mastenbrook wrote: > I think that's flat wrong. On a 32-bit system, 2^30 is a bignum on > most implementations because at least three tag bits are reserved for > objects. I work with numbers larger than that frequently and have > absolutely no issues with using bignums. As far as I can tell, there > are essentially no negative consequences to fixnum->bignum overflow. > You can work with bignums at least 32738 times larger in > representation size without dire problems on all implementations of > Scheme that I have tested.
I have a great interest in being able to obtain exact answers for the sizes of files, and many of them are many GB in size... indeed, in Ugarit (my Venti-esque backup/archival system), the backend opens a new backup file every GB, as even with the numbers egg loaded, Chicken's procedure to find the position of a port in a file starts returning flonums beyond 2^30; and I need to record the current position in the file to update an index of what block is where :-( > Once again, I'm having trouble understanding what all of these really > horrible problems associated with a full numeric tower are. I have not > run into any of them on implementations of Scheme that support a full > tower, nor in any of my years of using Common Lisp commercially. I > have, on the other hand, counted past a 24-bit or 29-bit fixnum > frequently. If you could at least point me to a real life scenario on > where these terrible bignum semantics have caused problems, I'd like > to hear about it. Me neither. As I said in IRC (paraphrasing here for the benefit of the rest of the class), I think it's useful to be able to have Scheme systems with castrated numbers, because it's fun to shoehorn Scheme into tiny embedded systems, BUT: 1) It's fine if we have to call those implementations "Not quite complete, as we have castrated numbers"; if it's a pain to specify this in the standard, then it's not a big deal to make very-minimal Schemes, which may well have many other restrictions beyond what's in the standard anyway. 2) I really think that exact integers should stay that way up to some implementation-specified limit, and then they should raise overflow conditions, the handlers of which can then opt to make the arithmetic operation return some arbitrary value of their choosing. I think that any other semantics of arithmetic should be handled by differently- named functions, to reflect their unusual overflow semantics, rather than being some spooky global property of the implementation, which would hamper portability. Providing them as part of the dynamic environment, either as an arithmetic-mode flag reminiscent of IEEE float semantics or just by letting people provide suitable overflow condition handlers, is also fine by me, although I personally feel that an addition that might overflow to inexact should be signalled as such by the author of some code, not the caller of that code. 3) Whether that limit should be required to be at least some value in the R7RS specification (2^16? 2^32? 2^65536?) or not is open to conjecture. Any value you pick will, necessarily, be arbitrary, and so any particular choice is hard to justify; but on the other hand, it's nice to think that programmers who aren't using "unusually large" numbers (which pretty much boils down to "not doing any cryptography") can just not worry about numeric limits. 4) fixnum/bignum is a side issue that confuses matters. That's just an issue of representation. Saying a given Scheme "has bignums" or not isn't the issue, so I question John's approach to having a feature called %bignums. The issue is how big exact integers can get before something happens, and then what happens. ABS -- Alaric Snell-Pym Work: http://www.snell-systems.co.uk/ Play: http://www.snell-pym.org.uk/alaric/ Blog: http://www.snell-pym.org.uk/archives/author/alaric/ _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
