Yegor Bryukhov wrote: >> Probably other people have a more substantial answer, but let's try... > > Thank you, Simon, it did bring some light. > I was thinking about this problem not from an end-user point of view > but as a (potential) developer of one of these libraries.
Great! Welcome! What sort of library are you thinking of? > >> 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. 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. Jason --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
