[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: jaffer@ai.mit.edu*Subject*: Re: Generic Arithmetic*From*: david carlton <carlton@math.mit.edu>*Date*: Tue, 14 May 1996 11:40:50 -0400 (EDT)*Cc*: carlton@math.mit.edu, rrrs-authors@martigny.ai.mit.edu, carlton@math.mit.edu*In-Reply-To*: <m0uJBMO-000alUC@jacal>*References*: <199605131622.MAA19077@severi.mit.edu><m0uJBMO-000alUC@jacal>

On Tue, 14 May 96 00:05 EDT, Aubrey Jaffer <jaffer@martigny.ai.mit.edu> said: > From: david carlton <carlton@math.mit.edu> [ 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 > breaks. 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 associative, either. >> 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. david carlton carlton@math.mit.edu Are we THERE yet? My MIND is a SUBMARINE!!

**Follow-Ups**:**Re: Generic Arithmetic***From:*Aubrey Jaffer <jaffer@martigny.ai.mit.edu>

**References**:**Re: Why would anyone want opacity?***From:*david carlton <carlton@math.mit.edu>

**Generic Arithmetic***From:*Aubrey Jaffer <jaffer@martigny.ai.mit.edu>

- Prev by Date:
**R4RS compliance: negative numbers** - Next by Date:
**Re: Efficiency of unlimited precision integer arithmetic** - Prev by thread:
**Generic Arithmetic** - Next by thread:
**Re: Generic Arithmetic** - Index(es):