On Sun, Jul 5, 2009 at 3:15 AM, Dag Sverre Seljebotn<da...@student.matnat.uio.no> wrote: > > Jason Grout wrote: >> 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! > > That's what I'm thinking too -- even if a change isn't accepted > upstream, Sage could patch it's own version of NumPy. > >>> 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)? > > Not necesarrily (4), no, although they may be linked somewhat in the > API, I didn't check that. > > Which dtype is used is at least conceptually somewhat independent of > what Python object is used to represent its elements. E.g. both arrays > with uint8 and int64 would convert to/from a Python int on a Python access. > > Regarding (1), what I meant was to have ZZ elements input to arange > result in an array of int64 (on a 64-bit system), like if the preparser > wasn't in effect. > > I suppose if ZZ is made a possible NumPy dtype it may make sense to have > that be the default -- it is just surprising because then NumPy would > have "different default types" depending on whether the preparser is on > or not.
I just want to make a quick comment that -- except for "object" -- there are no dtypes that aren't homogenous data types. ZZ would be totally different than all other (non object) datatypes in numpy, since the size of an element depends on the element. There was a challenge at the Sage days at Enthought to add mpz_t as a dtype to numpy, but it didn't end up going anywhere. I personally don't think it is likely that ZZ will ever be a numpy dtype.... -- William --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
