This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.
Aubrey Jaffer wrote:
I am open to mandating bignums.
I agree. The core has to provide "small" integers and normal arithmetic operators so that you can do thinks like iterate through a vector without having to convert it to a list. Once you have done that, you have to deal with "small" integers not being closed under normal arithmetic operations. There are many options, and if this were another language we would signal an error or define "normal" to be "modular" or use some other hack. However, we are designing Scheme, and the Right Thing is to mandate unlimited size integers.
Yes, I know you can run out of memory with unlimited size integers, but that is no different to other resource exhaution scenarios.
Flonums often are the most difficult feature to port to new architectures. But computer science is a half-centry old already -- tiny implementations can say they implement a subset of R6RS.
Why do you say that? IEEE singles and doubles (although unfortunately not extended doubles) are part of all modern architectures and are implemented transparently (i.e., in hardware or in software by the OS) almost everywhere. Denorms can be tricky, but it's normally just a case of finding the right global flags.
IEEE singles and double are not difficult for an implementation, but they are often not necessary for an application. I would vote to move them out of the core and into the library.
That is, I would mandate only unlimited size integers in the core. The rest of the tower should be moved to the library.
Both Common-Lisp and SLIB implement MOST-POSITIVE-FIXNUM and MOST-NEGATIVE-FIXNUM, which would be good additions to R6RS.
If unlimited size integers are not mandated, these constants are useful. If they are, these constants are not useful.
In well-written interpreted implementations, fixnum operations would provide no speed increase. SCM's type dispatch for immediate numbers is just 3 instructions: mask, test, and conditional jump. With modern processors executing scores of instructions in the time it takes for a single cache line to be retrieved from memory, most data type dispatches use time which would otherwise be spent waiting for program or data caches.
What you write is correct as far as it goes, but imagine having two number types (say fixnums and flonums) and comparing specific operators for each type with a generic operator. On at least some processors, the generic operator will mispredict the branch for one type or the other. Mispredicted branches are often more painful than L1 cache misses. Specific operators can almost always manage to avoid misdirected branches.
SCM has real-only operations like $log and $sin, which I never use; even though I do substantial floating point computing. In most nontrivial computations, a couple percent speed improvement from fiddling with the minutia of low-level procedures is dwarfed by the speed improvements netted by memoizing the results of certain sub-calculations or vectorizing computations in SRFI-63 uniform arrays.
Yes and no. I can imaging writing Lisp-style macros to walk code and replace generic operations with specific ones.
-0.0 is insufficiently specified by SRFI-77; it will be a portability killer.
It is perfectly specified by the IEEE standard.
quotient+remainder introduces a new procedure naming convention which doesn't play well with -. The mathematical term for quotient with remainder is division; the verb form being divide. How about changing QUOTIENT+REMAINDER to DIVIDE.
Or quotient-and-remainder. Isn't "+" sufficiently overloaded as it is without having it stand for "and" :-)
Mathematically, mixed exactness complex numbers makes no sense. Twisting the whole numeric tower around this artifice is wrong.
Maybe, but a cheap way to get an inexact imaginary is an number with an exact zero for its real part and an inexact real for its imaginary part.
Regards, Alan -- Dr Alan Watson Centro de Radioastronomía y Astrofísica Universidad Astronómico Nacional de México