|
|
Blitz Devel : |
From: Julian Cummings (cummings_at_[hidden])
Date: 2003-12-03 14:00:13
Hi All,
I am forwarding a copy of an e-mail exchange I had with Suresh regarding
the latest version of his vtext package, which he recently posted to the
blitz-support mailing list. The package contains various linear algebra
routines and transform functions, which I think would make useful
additions to blitz. The routines require several key modifications and
extensions to blitz, and I would like to have some feedback and
discussion on whether these extensions make sense and should be adopted.
The main extensions to blitz are
1) Allowing null Ranges such as Range(1,0,1) that do not contain any
valid indices and also allowing null Array slices that contain no elements.
2) Extending the ListInitialization class and the comma operator to
allow for delimiter tags that indicate the beginning and end of the data
stream and the end of the current "row", with the remainder of the row
being filled with zeroes.
3) A set of helper classes that allows one to assign multiple objects as
a single composite object within a single assignment statement, using
lhs() and rhs() notation.
4) A set of macros that allows the user to "expose" data members of a
struct, so that they may be extracted as components when you have a
blitz Array of such struct objects.
As you can see from the discussion below, my sense is that #1 may be a
bit dangerous and is not necessary, #2 and #3 are more or less
syntactical sugar, and #4 seems useful. Most of these proposed
extensions are inspired by MATLAB, which I don't know that well. So I
may not understand the full benefits of some of the extensions. I am
happy to fold them into blitz if enough people like the ideas.
As for the new algorithms in the vtext package, please have a look at
these also and send any comments to this list. My understanding is that
many of the implementations are derived from Numerical Recipes. In the
case of Fourier transforms, there are better things out there such as
FFTW, but it doesn't hurt to have a pre-packaged set of routines to fall
back on. These functions are all written using macros to make the array
interface potentially adaptable to other packages besides blitz. In
addition, MATLAB-like interfaces to the various functions are provided.
Since many of these routines are oriented towards linear algebra, it
might make sense to retarget them at the blitz Matrix and Vector classes
rather than the Array class. A lot of the operations here implicitly
assume a 2D Array. I would also like to see some benchmarking of these
routines against those of an existing freeware package such as the GNU
Scientific Library (GSL) before they are adopted into blitz.
Please have a look at the routines in the vtext package and post your
comments here.
Thanks, Julian C.
-------- Original Message --------
Subject: Re: Comments/Suggestions regarding extensions to blitz
Date: Tue, 2 Dec 2003 20:05:01 -0500 (EST)
From: Sureshkumar Devanathan <mdsuresh_at_[hidden]>
To: Julian Cummings <cummings_at_[hidden]>
Dear Dr. Cumminng
Most of my changes, have roots from MATLAB. In fact, the lhsrhs, null
ranges, delim<';'>() are based on MATLAB programming. In fact, most
the
behaviour, you tell that doesnt make sense, is what makes MATLAB
programming easier.
Since I went to school for electrical engineering, i have grown to
appreciate most of this nonsense, as it makes the code look elegant. For a
lack of a better analogy, 0! = 1, may not mean anything, but it does make
a lot of series, look simple and pretty :-).
As a matter of fact, I had the same questions, you do, right now. But
since MATLAB has become such a successful tool for scientific computing, i
think, emperically, ideas like null ranges, lhsrhs have shown themselves
to be successful.
I definitely think, this issue must be debated on blitz-dev. And if you
dont mind, you can post this message to blitz-dev, and see what others
have to say.
-suresh
On Tue, 2 Dec 2003, Julian Cummings wrote:
> Suresh,
>
> I actually just went through the old version of the vtext stuff that you
> submitted on sourceforge over a year ago. (Shame on me for taking so
> long to pick it up and look at it!) I had to do a lot of surgery on
> that version because it seemed to be very buggy. But after a lot of
> work, I got most of the code to compile and produce correct results.
> Probably you have found and fixed many of these same bugs
> independently. I just downloaded the newer version of vtext that you
> sent around on the blitz-support mailing list. (By the way, the
> blitz-dev mailing list is probably more appropriate for this sort of
> thing, since you are proposing new development for blitz, rather than
> reporting a bug.) I was able to build the blitz library and your test
> code func.cpp and run the test OK. The only minor problem is that you
> named your revised version of the Range header file Range.h instead of
> range.h.
>
> I do have several comments based on what I saw in the earlier version of
> the code. First, you have a portability layer using macros so that you
> can use the vtext with other packages such as Octave. Does this
> portability layer actually work? That is, are you using vtext with
> other array packages? It doesn't really make sense to have this layer
> in code that is to be distributed within blitz. On the other hand, if
> you just want to maintain a separate package that can be installed
> alongside blitz, this might make sense.
>
> Second, your code requires several key extensions and modifications to
> blitz classes, specifically the range and list initializer stuff. I
> remember long ago you requested a change to allow null Ranges, and after
> looking through the vtext code I saw why. You have a lot of loops where
> you are constructing Ranges and then using them to do operations on
> certain subarrays. Allowing null Ranges to be constructed helps you
> avoid errors in these loops when the lower bound of one loop overlaps
> the upper bound of another. I'm not sure what is supposed to happen
> when a null Range is encountered in an array expression in your system.
> The reason null Ranges aren't allowed in blitz is that this behavior is
> undefined. The expression evaluator checks for conformance between the
> left-hand side and right-hand side of an expression, but this is
> meaningless when one or more Arrays have been sliced with a null Range.
> Usually when a null Range is generated, it is due to a mistake on the
> part of the user, so it makes sense to report this as an invalid Range
> and abort. In every instance in your vtext code, I can make the code
> work without null Ranges by making the appropriate checks before
> attempting to slice an Array with a null Range.
>
> As for the ListInitialization extension, it seems like you are trying to
> avoid having to write many zeroes in your list of initial values by
> adding a syntax for indicating the end of the current "line" of values
> and the beginning of the next "line". In principle, this might be a
> useful extension of the ListInitialization class, but your
> implementation is very specific to 2D Arrays. The implementation should
> be generalized for any dimension. A proper way of doing this is to use
> a real ArrayIterator object in the ListInitialization class instead of a
> raw T_numtype pointer. The ArrayIterator keeps track of its array
> position as it iterates, so it can easily detect the end of the current
> "line". This iterator would be capable of filling all the remaining
> values in the current "line" with zero, or even some other fixed value.
> The "marker" for filling the remainder of the "line" could be a simple
> class that holds the fill value. Then you wouldn't need all the special
> delimiter tags that you have added. Using an ArrayIterator in the
> ListInitialization class will be slower than using a raw pointer, but
> speed is probably not an issue for initializing Array values just once.
>
> Another thing to keep in mind is that the Array initialization that you
> want can already be done by taking appropriate slices of your Array
> before assigning to it. For example, you have in your func.cpp test
> code the following lines:
>
> Array k(6,8);
> k = delim<'['>(), 10 , 5, 9, 4, 1, delim<';'>(),
> 2 , 0, 7, 9, 2, delim<';'>(),
> 6 , 8, 2, 1, 2, delim<';'>(),
> 5 , 4, 4, 4, 6, delim<';'>(),
> 9 , 6, 9, 8, 3, delim<';'>(),
> 8 , 8, 9, 0, 2, delim<';'>(),
> delim<']'>();
>
> You could have accomplished the same thing by saying
>
> Array k(6,8);
> k(Range::all(),Range(0,4)) = 10 , 5, 9, 4, 1,
> 2 , 0, 7, 9, 2,
> 6 , 8, 2, 1, 2,
> 5 , 4, 4, 4, 6,
> 9 , 6, 9, 8, 3,
> 8 , 8, 9, 0, 2;
>
> So I'm not so sure how important or necessary this extension really is.
>
> You have a few other extensions here as well. There is the lhsrhs code,
> which I can't really figure out the purpose of. It looks like you use
> it to make multiple assignments with a single statement. Is this really
> necessary? Also there is the member code for exposing data members of a
> struct so that an Array of these struct objects can address specific
> members. This code is pretty slick, and I don't have any major
> objections to including it in Blitz. It's a little weird to be using
> operator-> to access the members, since this operator is usually applied
> to pointer or iterator types. Are you actually using this feature
> somewhere in vtext?
>
> I don't mean to be overly critical of the code you have produced here.
> But I do want to limit the additions or extensions to blitz to items
> that seem truly necessary and useful. These extensions should probably
> be described and debated on the blitz-dev mailing list, to give other
> people besides me a chance to chime in. One more comment I had
> regarding the algorithms that you've written. I was just recently made
> aware of GSL, which is a GNU package of common scientific algorithms
> written in C. It covers an enormous amount of ground, including many of
> the linear algebra routines you have written. I think it provides a
> nice organization of these routines into categories, something which I
> would like to model within the blitz/alg subdirectory. In addition, you
> might want to compare some of the details of the algorithms you have
> written with what is in GSL. Their implementations are not necessary
> the best or most efficient ones (for example, FFTW provides better FFT
> routines) but they provide a useful benchmark for any algorithms we
> might provide in blitz.
>
> Regards, Julian C.
>
>
> Sureshkumar Devanathan wrote:
>
> >Dear Dr. Cummings,
> > I am wondering if you have any comments or suggestion regarding, the
> >function package extensins, i am trying to build. It would be great to
> >know, what is good and what can be improved.
> >
> >thanks
> >-suresh
> >
> >
>
> --
> Dr. Julian C. Cummings E-mail: cummings_at_[hidden]
> California Institute of Technology Phone: 626-395-2543
> 1200 E. California Blvd., Mail Code 158-79 Fax: 626-584-5917
> Pasadena, CA 91125
>
>
>
>
-- Dr. Julian C. Cummings E-mail: cummings_at_[hidden] California Institute of Technology Phone: 626-395-2543 1200 E. California Blvd., Mail Code 158-79 Fax: 626-584-5917 Pasadena, CA 91125