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

*To*: srfi-25@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx*Subject*: Re: Not quite enough abstraction*From*: Brad Lucier <lucier@xxxxxxxxxxxxxxx>*Date*: Mon, 18 Feb 2002 00:05:37 -0500 (EST)*Cc*: lucier@xxxxxxxxxxxxxxx (Brad Lucier), oleg@xxxxxxxxx, noelwelsh@xxxxxxxxx, kumo@xxxxxxxxxxxxx, jpiitula@xxxxxxxxxxxxxxxx, feeley@xxxxxxxxxxxxxxxx*Delivered-to*: srfi-25@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

I see that there has been some followup discussion on my previous post, but since no-one except Oleg CC'ed me on their message, I didn't see them until I browsed the archive today. I have no desire to delay or derail this SRFI. I'm just trying to make some comments on what level of abstraction I think data structures in scientific computing should have. Basically, my point is that an array is conceptually a mapping g: [0,n1) \times [0,n2) \times ... \to \text{Scheme objects} that is accessed by some notation like (array-ref g i j k ...). (One could simply use functional notation if there were easier ways to construct and manipulate function arguments in Scheme.) There need be no backing store. This is sometimes helpful when applying functions to arrays (now just composing functions), to delay their evaluation and the construction of intermediate storage results. One just constructs the new mapping; that's why I sent the previous code for abstract-vectors. When you want to use an array multiple times, it may be more efficient to convert it to the form that Bawden and this SRFI use. Or if you want to construct new arrays as slight modifications of old arrays, then Bawden's form is also most efficient, with array component setters, but one should not have one's ideas fixed by this particular happenstance of computer programming and implementation efficiency. One hits a similar problem when talking about how to do numerical linear algebra in computer programs. There are whole template packages with names like matrix++, etc., that deal with all kind of hairy issues of allocation, access, composition, application, etc., at the component level. But that level is too low for numerical linear algebra applied to the numerical solution of partial differential equations. What one needs are linear maps. Some of these linear maps never have explicit representations. Some of them you want to apply to vectors (which can look nothing at all like Scheme vectors or Fortran arrays or ...); some of them you can't apply to vectors, but you apply their *inverse* to vectors; etc., etc. In other words, arrays of numbers, matrices of numbers, vectors of numbers, are all too low-level constructs on which to build a useful PDE solver system. For an implementation that incorporates some of these ideas, see the PDE solver library at http://www.math.purdue.edu/~lucier/615/software/ So the SAC and Sisal ideas of arrays are too low-level for me, too. Brad

- Prev by Date:
**toner supplies** - Next by Date:
**Can array-ref return (values ...) ?** - Previous by thread:
**Re: Not quite enough abstraction** - Next by thread:
**do not delete ! get rich - hurry up and act now !** - Index(es):