On Tue, Jan 18, 2011 at 07:55:30PM +0000, Garth N. Wells wrote: > > > On 17/01/11 18:16, Anders Logg wrote: > > On Mon, Jan 17, 2011 at 06:07:19PM +0000, Garth N. Wells wrote: > >> > >> > >> On 17/01/11 18:03, Anders Logg wrote: > >>> On Mon, Jan 17, 2011 at 04:30:23PM +0000, Garth N. Wells wrote: > >>>> > >>>> > >>>> On 17/01/11 16:28, Anders Logg wrote: > >>>>> The following doesn't seem to work in Python any longer: > >>>>> > >>>>> A = Matrix(10, 10) > >>>>> > >>>>> Is matrix initialization broken? > >>>>> > >>>> > >>>> Probably not broken - more like > >>>> > >>>> A = Matrix(10, 10) > >>>> > >>>> is not supported. Since a Matrix is in general sparse, it doesn't make > >>>> sense to initialise it as above (some backends even insist on the > >>>> sparsity being defined at construction). > >>>> > >>>> Garth > >>> > >>> It would be good to allow simple initialization of a Matrix without > >>> requiring to go through all the hassle of creating a SparsityPattern. > >>> > >>> I generally don't think we should disallow certain operations just > >>> because they are potentially slow. > >> > >> It's not just that they're slow. They cannot be supported by all backends. > > > > Then we throw an error. > > > > Better still, use an appropriate data structure ;). If a user wants a > dense matrix, we should make it easy to use a dense matrix. > > The Matrix class in DOLFIN is sparse and the premise should be that it's > distributed. Being consistent in this makes life a lot easier in parallel.
Yes, but being sparse does not mean it should be impossible to assign individual entries. This can be very helpful in debugging (small) problems. > >>> Some operations (like Matrix index > >>> access) will only be performed for toy problems or while testing and > >>> then speed is not very important (since the problem is small anyway). > >>> > >> > >> If it's made available, it will be used. This type of operation is main > >> reason for things breaking in parallel. We have getitem and setitem > >> which are sufficiently unfriendly that hopefully users get the idea that > >> they're for testing only. > > > > Just because something can be misused, it shouldn't be disallowed. > > Doesn't sound like a strong argument. It should not be easy to misuse a > library. That's why I can live with get/setitem, but not indexing into a > sparse distributed matrix via A(i, j). Everything can be misused. We still allow overloading eval for Expressions in the Python interface. It's very slow compared to jit-compiling an Expression, but it's very convenient to have. > > It would be easy (and more helpful) to add a message the first time > > getitem/setitem is used in a program: > > > > Warning: Index access to matrix/vector values is potentially very > > slow and it breaks in parallel. To disable this warning, set the > > parameter "warning_index_access" to false. > > > > Yes, I would like to see a set/getitem warning. Yes + operator[] mapping to those. I think that would be a good compromise, don't you think? ;-) -- Anders _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
