[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Generic Arithmetic
On Tue, 14 May 96 00:05 EDT, Aubrey Jaffer <firstname.lastname@example.org> said:
> From: david carlton <email@example.com>
[ talking about the merits of generic arithmetic. ]
First, I should say that I'm _not_ proposing that Scheme actually
adopt a broader generic arithmetic system; I'm just saying that I'd be
annoyed if it were any narrower than it is and that I personally would
find it convenient for it to be broader though I can understand why
other people might think that that's a bad idea. Numerical systems
definitely become a lot trickier when you have a numerical lattice
instead of numerical tower, for example.
>> For me, lots of time, it is. I'm a mathematician, and these days most
>> of the time that I'm programming I'm implementing algorithms that
>> would work largely or entirely without change over much larger classes
>> of "numbers" than rationals or reals or whatever.
> Changing the arithmetic which the procedures +, *, etc. use is a bad
> idea because programs use properties guaranteed by R4RS which are
> derived from the ring of integers. If you change the ring, stuff
Sure, but so what? You can already write lots of functions that work
fine when passed integral arguments and not so well when passed
complex arguments; this isn't a problem per se, it just means that you
have to be careful.
> Let us suppose you are interested in computing in Z mod 3,
> the function:
> (lambda (x) (modulo (+ (expt x 3) (expt x 5) 1) 3))
> is *NOT* equivalent to:
> (lambda (x) (modulo (+ (expt x 2) 1) 3))
> If you changed all arithmetic to be mod 3, then you run the risk of
> performing invalid reductions like:
> (expt a (+ 2 1)) ==> (expt a 0) ==> 1
Only if you're particularly naive. If R is an arbitrary ring and N is
the natural numbers, say, then exponentiation is a function from RxN
to R, not from RxR to R, after all, so there's no reason why what you
are proposing should be considered a valid reduction. And this is
already a problem with the numerical types that Scheme has, anyways -
once you choose one branch of log, then log and expt stop satisfying
nice algebraic properties.
> An example of larger class of "numbers" is quaternions. Introducing
> quaternions means that * will not always be commutative and / will
> be an inverse of only one handedness of *.
Multiplicative inverses are still two-sided in the quaternions; in
general, in an arbitrary ring with unity, if an element has both a
left inverse and a right inverse then the inverses are equal.
And sure, multiplication isn't commutative. Is this really a problem?
Subtraction isn't commutative; this doesn't stop people from
profitably using it. Multiplying floating-point reals isn't
>> And when I say "would work" in the above, I'm not talking about
>> some sort of abstract possibility; I mean that it happens all the
>> time that I wish that I could run some of my code in a more generic
>> number system, that I didn't have to go running to Maple (which I
>> can't stand) every time that I want to allow the possibility of
>> dealing with polynomials, say, rather than rational numbers.
> There is a simple way to do just what you want, portably, in R4RS
> Scheme. Just change the names of calls to arithmetic procedures in
> your code to versions with "gen:" prepended. This gives you control
> over which operations are performed with the new number system, and
> which are done using integers.
> If this is not what you had in mind, then are you are expecting GCD to
> be automatically extended from an extended definition of REMAINDER?
> This won't necessarily work, because GCD for integers can be
> implemented without using REMAINDER.
I'm not expecting that any more than I expect GCD to behave sensibly
when passed complex numbers as arguments. All I'm saying is that it
would be profitable for me personally to be able to extend the
numerical system so that certain numerical functions would behave on a
larger class of objects. I don't expect numerical functions to
magically become defined, I don't expect them to be completely
defined. But these are issues that already arise with the curret
numerical system, and don't bother anybody.
Again, I should say that I am not proposing that the numerical system
be changed in the slightest. It would be convenient for me personally
if it were, but that's a different issue. I just wanted to respond to
the claims that bignums were, apparently because real programmers
need to squeeze the last ounce of efficiency out of their 32-bit
operating system instead of, say, writing some simple math code to do
some calculations that are too tedious to do by hand.
Are we THERE yet? My MIND is a SUBMARINE!!