On Jul 7, 2009, at 6:32 PM, William Stein wrote: > > 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.
The fix below didn't take long at all to find. Here they're talking about using a user-defined type as a complex. This would be nice, but even being able to cast a user-defined type to a complex is the most important part. I believe this has been resolved in 2.6 (see below). >>>> 2) sin, sqrt etc. should understand, act on, and return NumPy >>>> arrays >>>> (probably by calling corresponding functions in numpy) Not even the builtin math.sin does this. To bad numpy arrays don't have a sin method, or it would already work. It shouldn't be to hard to support (generically), though for speed reasons we avoid importing numpy unless we want to use it. Hopefully http://trac.sagemath.org/sage_trac/ticket/6497 isn't too hackish. >>>> 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. Sure. >>>> 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 This really doesn't make sense--a[2] and a[4] are np.uint8 scalars. We'd really have to hack numpy to get Integers back. However, this would be like changing range. >>>> >>>> 5) #4571 (cimport numpy in notebook), obviously. +1. Thanks for fixing numpy.pxd. >>>> 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.... What may be possible, though I'm not sure how easy, is a dtype that is internally an int64 (or float64, etc.) with all the overflow issues, but whose getitem creates an Integer/RDF. It looks like user- defined types are quite powerful, but still have some rough edges. See http://trac.sagemath.org/sage_trac/ticket/5081 . ---------------------------------------------------------------------- | Sage Version 4.0.2, Release Date: 2009-06-18 | | Type notebook() for the GUI, and license() for information. | ---------------------------------------------------------------------- sage: from scipy import stats sage: stats.uniform(0,15).ppf([0.5,0.7]) array([ 7.5, 10.5]) sage: numpy.array([1, 2, 3.0]) array([ 1., 2., 3.]) sage: numpy.array([1, 2, 3.0]).dtype dtype('float64') sage: numpy.array([3.000000000000000000000000000000000000000000000]) array([3.000000000000000000000000000000000000000000000], dtype=object) sage: numpy.array([1, 10, 100]).dtype dtype('int64') sage: numpy.arange(5) array([0, 1, 2, 3, 4], dtype=int64) Still doesn't fix the complex case (which is a different issue), sage: import numpy sage: numpy.array([RDF(2)], dtype=complex) array([ 2.+0.j]) sage: numpy.array([CDF(2)], dtype=complex) ------------------------------------------------------------ Traceback (most recent call last): File "<ipython console>", line 1, in <module> TypeError: a float is required Better news, this may be fixed with PyComplex_AsCComplex - http:// bugs.python.org/issue1675423 (see also numpy/core/src/ arraytypes.inc.src:174) - Robert --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
