Mirko, My philosophy is that specialty cases like these are best handled with iterate forms and the appropriate iterate extensions. I think too much effort is spent trying to make things "elegant" for unusual cases, and it's just not worth it. Of course you're free to define your own macros, but I don't find the form using the macro to be more transparent than an iterate form would be. Of course if I were thoroughly versed in the application and using similar constructs a lot, I might think otherwise.
So I guess I'm after easy of use/transparency for the common linear algebra and similar cases, and willing to let the users write their own iterate forms for unusual cases. Liam On Sat, Jan 16, 2010 at 9:44 PM, Mirko Vukovic <[email protected]> wrote: > This is a follow up on the syntactic sugar for array referencing that I > referred to in my wish list. Here is what I had in mind. > > A few weeks ago, I needed the inverse of a tridiagonal matrix. I found an > algorithm on the web. See the first page of the following pdf document. > > I am looking for a cleaner and simpler way to transcribe equations (1.1) > and the two below in lisp. Note a few things. In the equation for `theta', > the index of `theta' varies from 0...n, while all the other ones are from > 1...n. > > Another problem of interest is the Yee algorithm for the numerical solution > of time-dependent Maxwell equations. Take a look at the equations following > (4.12) on the following page. The indices are, among other things, i+1/2. > The notation stems from the fact that the algorithm uses two staggered > grids, one for the electric, and the other for the magnetic fields. The 1/2 > reflects the grid offset. Of course, in actual implementation, the fields > are stored in matrics, and the indices are integers. > > For both of these cases, one has to do some kind of index transformation, so > that E_{i+1/2} becoms (aref E (some-function-of i)). With many equations, > for scatterbrains like me, that is a recipe for a missed or miscalculated > offset. > > I came up with a macros that will transform code that contains symbols like > E_i+1/2 into an appropriately referenced `aref' or `maref' by using > symbol-macrolet. > > For the theta equations, see the following code snippet on paste.lisp.org, > where the with-_-indexing1 macro does the transforming. One thing to be > aware of is that the macros expand into code of `finite' length. So, > inserting this macro as follows > (if (...) > (with-_-indexing () > (if clause) > (else clause)) > will be inaccurate. One has to move the `with-_-indexing' outside of the > `if'. > > When I clean up my routines, I will post them (somewhere, not yet sure > where). And if anyone has a better idea how to name the macros, please let > me know. > > Mirko > > > On Tue, Jan 12, 2010 at 5:20 PM, Mirko Vukovic <[email protected]> > wrote: >> >> Features that I would like: >> >> Compatibility with GSLL and LAPACK (and NETLIB for that matter). When >> doing numerics, I would use grid (or xarray) and forget about cl-arrays. >> More forgiving interface in array creation: coerce supplied values to >> declared type >> syntactic sugar: refer to array subscripts using underscores: a_i_j or >> a_2:5_* >> >> On that last point, I have a small utility that does the first example. I >> am not sure where to post it for your review. I think github is overkill >> to post three files (asd, package, and lisp). >> >> I am intrigued by xarrays' generic interface, so that xarrays can >> interface with `any type of object'. I fail to see its use now, but that is >> just my lack of imagination. >> >> On a `lack of imagination' topic, can someone give me an example of >> indexing that xarray has, and that the affine indexing cannot accomplish? >> >> Thanks, >> >> Mirko >> >> On Sun, Jan 10, 2010 at 3:20 PM, Liam Healy <[email protected]> >> wrote: >>> >>> I don't think there's any doubt we all want one all-singing >>> all-dancing interface that provides array utility for everything in CL >>> that needs it. The reason there are two starts is because we both >>> started in parallel without the being aware of the other's work. The >>> reason that GSD only got as far as it did was because I had addressed >>> the complaints on this mailing list and elsewhere (including me) and I >>> had no more time. I do not think of it as complete. >>> >>> So the real work here is going through both sets of code and figuring >>> out how to unify them. I think all the help we can get would be >>> welcome; I'm certainly willing to work toward the goal. >>> >>> To get the ball rolling, start with a feature at a user's level that >>> you need; I mean by this some very specific thing that you've coded in >>> CL already and found to be clumsy. Then see how each package >>> implements it or would implement it. Then post to the list your >>> findings, together with your example if possible, to start a >>> discussion. Anyone can do this; I don't think there's a need to >>> restrict to a "third party"; we lack a first party at the moment. By >>> picking single feature(s) and working from there, we will >>> incrementally get to the goal we all seek. If we try to do everything >>> at once or at the most abstract level, we're likely not going to get >>> there as quickly. >>> >>> Liam >>> >>> On Sun, Jan 10, 2010 at 11:50 AM, A.J. Rossini <[email protected]> >>> wrote: >>> > My cursory look suggests a fair amount of similarity as well, and I >>> > find attractive features in both -- but want just one API! >>> > >>> > A reasonable proposal, from my highly biased perspective, would be a >>> > 3rd party merge of the better components of each. >>> > >>> > (I've spent time with the xarray interface, which is the source of my >>> > biases -- it mostly works for what I want to do, despite being a >>> > simplification of the lisp-matrix access approach -- which isn't bad, >>> > there are some lisp-matrix functionality which is strictly edge-case >>> > relevant... >>> > >>> >>> _______________________________________________ >>> Gsll-devel mailing list >>> [email protected] >>> http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel >> > > > _______________________________________________ > Gsll-devel mailing list > [email protected] > http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel > > _______________________________________________ Gsll-devel mailing list [email protected] http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
