Dag Sverre Seljebotn wrote: > > 1) I must be able to use NumPy together with the preparser (it's just > too much hassle to turn it on and off, and it kind of defeats the > purpose.). That is, with the preparser on, I should be able to run most > NumPy-using code without changes. (I don't think is a difficult to > achieve, but certainly didn't look at it in detail.) > > One example is: > > sage: np.arange(4) > array([0, 1, 2, 3], dtype=object) > > This is not what I want, and I can never remember to pass in > dtype=np.int64. I don't think it makes sense either -- passing in > np.arange(int(4)) gives the desired behaviour, and a Python int and a > Sage Integer are equally far from an np.int64 anyway. > > > I think that's all, actually -- this would stop Sage from getting in my > way. But this is on my strongly wanted-list too: >
I asked on the numpy list a while ago about why numpy was not calling the conventional .__complex__() to automatically convert sage complex numbers to python complex numbers. The answer I received indicated that it would be very difficult for numpy to use the standard python convention of calling .__complex__() to get a complex representation of a number. That indicated to me that the problem was probably hard-coded in numpy! See http://thread.gmane.org/gmane.comp.python.numeric.general/25251/focus=25273 "The reason is that PyArray_ISCOMPLEX is used in various places, and this is a hard-coded macro. There is no way to extend numpy's complex behavior to support user added types. I wish there was." However, I haven't looked at it beyond that. So, pay no attention to the complainers and whiners; just do it! > 2) sin, sqrt etc. should understand, act on, and return NumPy arrays > (probably by calling corresponding functions in numpy) > > 3) It would be nice with better plotting support for NumPy arrays, so > that I don't have to use pylab directly, but haven't given any thought > to what I want here. > > 4) Not sure if this can be done in a reasonable way, but: I'd like to > not have to use Python ints/floats at all, it's just nicer to know that > I have a Sage element. So ideally > > sage: a=np.arange(5, dtype=np.uint8) > sage: a[2]/a[4] > 1/2 > > 5) #4571 (cimport numpy in notebook), obviously. > > 6) One of the things drawing me towards using Sage is the "attach" > feature. However, it is too limited for my use (and so makes me > frustrated, so that it is better not to use it at all). Something being > a combination for an "attach" and a pure Python "import" is what I want; > that is, "import" with automatically calling "reload" on change. (The > recent work in pyximport may come into play here; if the sources are in > Cython.) > > 7) Make NumPy dtypes for all Sage rings. I think that NumPy is quite > extensible in this respect and that it shouldn't be too difficult to > have arrays over Sage rings. > > sage: a = np.arange(10, dtype=ZZ.numpy()) # or dtype=ZZ if possible If this is possible, doesn't it take care of item (1) and (4)? Thanks, Jason --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
