On 11/2/07, Dan Christensen <[EMAIL PROTECTED]> wrote: > numpy arrays are extremely flexible, with broadcasting, view semantics > and in-place operations being the most important reason why. For > example, if x is an array, then x[3:5] is a view of part of x, and > I can adjust the entries in just that region with x[3:5] += [1,2]. > This even works if x is multi-dimensional, with the [1,2] being > broadcast to the right shape. > > At the same time, sage provides some fundamental types that can be > useful as array elements. > > So it is completely natural to use numpy arrays of sage elements, and I > have certainly done so many times. > > More generally, if the current implementation of in-place operations in > sage causes problems in numpy, it is quite likely that there will also > be problems with other python modules. So I regard this as a serious > bug in sage. >
+1 After mulling this over for awhile, I feel exactly the same way about everything said above. The inplace optimizations should be something that have to be explicitly turned on, and they should be off by default. I know they make certain things faster, but correctness by default is *always* a much more important consideration with serious mathematical software such as Sage. Always. I will very likely disable in-place optimization for sage-2.8.11, until this issue gets properly discussed and resolved. -- William --~--~---------~--~----~------------~-------~--~----~ 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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
