Robert Bradshaw <[EMAIL PROTECTED]> writes: > This is due to the inplace operator stuff using refcounts to > determine if it's safe to mutate. The simple workaround is to not use > numpy arrays of SAGE objects. Another question is why would one do so > (i.e. what is lacking in the SAGE linear algebra types?) I think the > benifits of inplace operators in terms of performance are to great to > abandon, but am at loss to find a clean solution so that external > extension classes don't mess them up... other than perhaps a global > option that can be enabled/disabled.
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. Dan --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-support@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-support URLs: http://sage.math.washington.edu/sage/ and http://sage.scipy.org/sage/ -~----------~----~----~----~------~----~------~--~---
