This is the mail archive of the gsl-discuss@sourceware.org mailing list for the GSL project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Row/column majority question comes from the times when God was REAL and Infinity was INTEGER (FORTRAN). But even at that time, some people, I hope, knew that the question of row/column majority is irrelevant. Think about it!
So think.... Sorry, but I will use capital letters...
COLUMN-MAJOR or ROW-MAJOR ??? IT IS ALL IN YOUR HEAD!!!! IT IS NOT REAL AND DOES NOT EXIST!!! THE MATRIX IS STORED AS A CONTINUOUS OBJECT AND ADDRESSING IS DONE VIA a FORUMLA LIKE THIS
index = j*Ni+i!!!
SO GIVE THE MAJORITY A REST!!!
Once again, sorry if I offended anyone, but someone had to point it out.
Yes, but CPUs really HATE doing arithmetic with a string of objects separated by a large offset. They much prefer to do arithmetic with a string of objects with unit offset. That way caches, prefetch and so on work. They indicate their disapproval by running really really slowly.
In other words, it is good if "j" isn't the rapidly varying index in your example of offset arithmetic.
Lazar
--- James Bergstra <james.bergstra@umontreal.ca> wrote:
On Wed, Mar 29, 2006 at 07:04:39PM +0100, J.J.Green wrote:I think the problem with calling fortran from C is that it is compiler, OS and (I think) architecture dependant. CLAPACK solves the portability problem, but as you have noticed, not the arcane interface which puts most poeple off using it.
Exactly the motivation for a gsl wrapper (or extension)! A gsl module would serve both as a gentle introduction to using lapack, as well as a hook to place normal documentation.
It seems to me that the largest barrier to a lapack wrapper is that gsl_matrix is an implicitly row-major structure, so that in general, arguments must be out-of-place transposed before a lapack call. Although this is not significant in terms of either O(n) time or space, the overhead is more noticeable in the case of large numbers of calls with small arguments.
Anyway, it seems like the concensus is that lapack is annoying to use but good in theory, once it's working. If someone (eg. me) writes an extension that makes (at least part of lapack) less annoying to use in practice, share with the list?
James
PS. My extension would probably introduce a column-major version of gsl_matrix.
-- james bergstra http://www-etud.iro.umontreal.ca/~bergstrj
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
-- Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@phy.duke.edu
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |