[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
# fixnumXXX and fxXXX names, and other things

`SRFI 77 specifies two classes of operations on fixnums: operations
``which perform modulo arithmetic (with fixnumXXX names), and those
``which signal an error on overflow (with fxXXX names). This naming
``convention is obscure because nothing in the name helps distinguish
``the two classes of operations. Why not be explicit and say
`

` (fxring+ x y) for the version which implement arithmetic on a
``quotient ring of the integers,
`and

` (fx+ x y) for the version which returns the same result as (+ x
``y) as long as x, y and x+y are fixnums.
`

`There is a high degree of duplication of functionality among the
``fixnum operations. Take for example,
`
(fixnum= X Y Z) which is identical to (fx= X Y Z)
There is also duplication in

` fx<, fx>, fx<=, fx>=, fxzero?, fxpositive?, fxnegative?, fxodd?,
``fxeven?, fxmax, fxmin, fxnot, fxif, and so on...
`

`What is the rationale for all this duplication? Is there some subtle
``difference in semantics I'm missing? When should the fixnumXXX
``version be preferred over the fxXXX version?
`

`There are relatively few fixnum operations where it makes sense to
``have a version which implements arithmetic on a quotient ring of the
``integers (mainly +, -, *, quotient, modulo, remainder). So I expect
``few fxringXXX procedures and many fxXXX procedures.
`

`I find it odd that some fixnum operations return multiple values
``(fxdiv+mod, fixnum+/carry, fixnum*/carry, ...). The main motivation
``for fixnum specific operations is that they are much faster than
``generic arithmetic. But in many implementations of Scheme multiple
``values are rather slow because the values are packaged up in a vector
``that is allocated on the heap, this vector must then be accessed to
``get to the values. Moreover the main use of the XXX/carry operations
``is to implement bignum arithmetic, but this will not be practical if
``these operations are slow. I'm sure if you take the time to
``benchmark this on some of the main implementations of Scheme you will
``see that it is considerably faster to perform two independent
``operations (for example use calls to fxdiv and fxmod instead of a
``call to fxdiv-mod). Have you analyzed performance on current Scheme
``systems, and if so, on which implementations of Scheme is the
``multiple values API faster and by how much?
`

`Finally, I haven't counted the number of procedures defined in this
``SRFI, but it is clearly very high. Do you realistically think that
``current implementations of Scheme will be updated to implement all
``these procedures efficiently? If for expediency implementors decide
``to use the portable implementation, I'm afraid that "portability" of
``arithmetic code will only have a theoretical meaning. Can we expect
``a portable and reasonably efficient implementation of this SRFI to be
``written as the reference implementation? That would greatly help its
``acceptance.
`
Marc