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

*To*: carlton@math.mit.edu*Subject*: Re: Why would anyone want opacity?*From*: Matthias Blume <blume@CS.Princeton.EDU>*Date*: Mon, 13 May 1996 17:49:16 -0400*Cc*: rrrs-authors@martigny.ai.mit.edu, oz@nexus.yorku.ca*In-Reply-To*: Your message of "Mon, 13 May 1996 17:26:23 -0400 (EDT)"*References*: <199605132126.RAA22919@severi.mit.edu>

From: david carlton <carlton@math.mit.edu> Subject: Re: Why would anyone want opacity? Date: Mon, 13 May 1996 17:26:23 -0400 (EDT) > On Mon, 13 May 1996 15:02:07 -0400, Matthias Blume <blume@CS.Princeton.EDU> said: > > > [ example of why one sometimes needs generic arithmetic deleted ] > > > Of course there are times when one needs such things. My objection > > is to making generic numbers the *default*. Most of the numbers in > > my programs are small integers, and I expect this to be true even in > > heavy generic math packages. We can safely assume that loop > > indices, array subscripts, etc., are not quaternions most of the > > time. And most of the numbers (at least in my programs) are loop > > indices of some sort. > > Different styles, I guess - I prefer to use lists to do my looping, so > it's not so much of an issue. Well, not everybody writes heavy math code. I, for example, almost never do. In fact, the last time I wrote large amounts of Scheme code was when I was working on VSCM's compiler. Small integers come up all over the place -- for various offsets, indices, ... > > If you really need to use a generic Number type it would be better to > > define a signature for the corresponding algebraic structure (pun > > intended) and abstract your code over this structure. > > Better for whom? My code was easy to write, expresses what I mean, > and works fast enough for what I want it to do. I don't see what the > problem is that signatures are supposed to solve. Scheme, with its numeric type tower, makes some fairly restricting assumptions of what kind of algebraic structure I am working with. For example, the number 2 is basically considered an element of the field of complex numbers. What if I really had the -1 from Z3 (integers mod 3) in mind? I can imagine Galois fields to be a very useful thing, but Scheme only caters to one kind of possible applications. On the other hand, if I abstract over the actual field by making it the argument of an ML functor I can make my code work with *any* kind of field that is either available already, or that I choose to implement when necessary. > So in Scheme you're likely to be able to use bignums, but aren't > absolutely guaranteed to be able to, whereas in ML you certainly (or > almost certainly?) can't, and this is an advantage for ML? I think > I'm missing something here. In both languages you can roll your own > bignums, in both languages it's probably a pain to do so, but at least > in Scheme you probably won't have to. Most certainly someone has already done it for ML, so you can use it from a library. > Given that rolling my own > bignum package isn't my idea of fun, Scheme seems like a clear win to > me. I don't understand this line of argumentation. Providing implementations for more algebraic structures is really a library issue. In both languages you are at the mercy of the implementor (of either the compiler or the library). Rolling your own bignum package in Scheme seems to be quite complicated -- especially if you want to hook it into the language as the report suggests (by completely and transparently replacing ordinary integers with it). The parameterized module approach seems like a real win to me here. There is only one thing you loose -- the illusion that all numbers are ideal complex numbers by default. -Matthias

**Follow-Ups**:**Efficiency of unlimited precision integer arithmetic***From:*William D Clinger <will@ccs.neu.edu>

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

- Prev by Date:
**Re: Why would anyone want opacity?** - Next by Date:
**Re: Why would anyone want opacity?** - Prev by thread:
**Re: Why would anyone want opacity?** - Next by thread:
**Efficiency of unlimited precision integer arithmetic** - Index(es):