On Nov 24, 12:19 pm, Jason Grout <[EMAIL PROTECTED]> wrote:
<SNIP>
> >> Firstly, Sage is based on an object oriented language (Python
> >> respectively Cython).
> >> For example, having different flavours of matrices (sparse, dense,
> >> special implementation over GF(2), defined in various interfaces,...)
> >> will usually not matter to the user, since the code usually relies on
> >> the methods of the objects. Now, dense and sparse matrices have most
> >> methods in common. So, your code would not feel any difference between
> >> dense and sparse matrices.
>
> > The problem, as I see, is in the construction of a new matrix.
> > If user creates just a matrix, and suppose, it is stored as a dense matrix.
> > Now, s/he starts invoking different methods that end-up C-library that
> > actually expects sparse matrices.
> > Suppose, we do a thousand calls, does it mean that our dense matrix
> > will be converted to a sparse matrix one thousand times?
>
> It's a possibility. If there was a library that only worked for sparse
> matrices, but the user wanted to use a function on a dense matrix, I
> don't see any way around converting the matrix.
I don't think this is really a good example that happens in the real
world. Many of the high level algorithms in the Sage library do not
depend on the representation of the matrix internally and if you do
some operation like multiplying two matrices the "low level stuff" is
dealt with under the hood. Obviously the performance of multiplying
two dense matrices is much better since one can use BLAS for example
for many fields. But doing the same operation with a dense and a
sparse version of the same matrices is in some cases much better and
much worst in others cases, so it all depends. Conversation cost can
play a role in certain operations, but in general the cost is not as
big as one assumes. Converting sparse to dense matrices is usually
linear while most matrix algorithms have a much worst complexity, so
that drowns out in the end. I am not discounting your argument :)
> Of course, the user could ask for a sparse version of their matrix, then
> call the library routine a thousand times, then convert back to dense,
> if they wanted.
Sure, but that is not a realistic example IMHO and in case there are
occurrences like that in the library they need to get fixed. I have
some plan to hook vtune into the doctesting suite to hunt for certain
performance problems, but that will happen once I got a handle on
muppy since heap leaks are a potential much greater concern for me.
> Jason
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
