-
-
Notifications
You must be signed in to change notification settings - Fork 482
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update numpy to 1.7.0 #11334
Comments
comment:1
CCing fbissey since he's been extremely helpful in previous numpy upgrades. |
comment:2
Thx. it looks like numpy has been bumped to 1.6 in Gentoo so I can do some quick compatibility tests. It looks like a flag for gfortran has been added in the ebuild to help with the compiler autodetection madness it may be worth having it sage side too. Do you know if a scipy release is to follow, if not it would be best to revbump scipy to make sure it is rebuilt after numpy. Other matter there has been noise about lapack in numpy do we want to disable it, make it optional or keep the status quo? |
comment:3
I don't remember seeing anything on the scipy lists about an imminent scipy release. |
comment:4
just in:
there may be more |
This comment has been minimized.
This comment has been minimized.
comment:5
I have cut a new spkg for 1.6.0, I decided to go for plain update for now. |
comment:6
seems my home install has problems. Probably stuff messed around between python 2.6 and 2.7 because I am working on #9958. Another install didn't report any problems. So I will check on a vanilla sage but I think we won't need to do any patching. |
comment:7
For some reason the other install didn't upgrade that's why I didn't see anything on the second machine. So right now it looks like we have the following to correct:
The first one is already in the ticket, then we have
The last three are particularly concerning, could you check what's up with these in numpy? |
comment:8
This seems to have installed fine on OS X 10.4 PPC. I'm running doctests now (which will take a LONG time) but I did already see the matrix/matrix1.pyx one while testing something else. |
comment:9
That's good that it at least install. On gentoo there are interactions problem between numpy and scipy to get cblas/blas/lapack right in scipy. I should check if the resulting scipy in vanilla sage suffers from the same problem. The last few failing tests are show stoppers as far as I am concerned. |
comment:10
Okay, I got pretty much the same failures on a long run. One weird thing... did we change
|
comment:11
1.6.1 is now available. I'll have a look sometimes this week. |
comment:12
Looks like more of the same but maybe a little bit more. There are a few other things that may interfere on my setup and I had to solve that bit: |
comment:13
Once I had cleared a few blas problem that I had while solving the gentoo bug. I get exactly the same results. I also get the output from Karl in optimize. This is a verbose output of glpk which get called at some point. You only get to see the such verbose output if there was a failure in the test but not necessarily the test for which glpk is called funnily enough. |
comment:14
Should we try to move forward on this again? I will have a go at trying it with 4.8.alpha2. Any ideas about the current failures? |
comment:15
Ok this is still broken in 4.8.alpha2. Some food for thought
with numpy-1.5.1 we just have
I suspect that for this one (functions/other.py) and functions/trig.py the pynac interface may need to be touched. All stuff that takes an numpy array and return a numpy array may have trouble. |
comment:16
Just to add a bit of info. Same python and ipython
So it works in ipython but we don't have the dtype=object attached to the array. Anyone knows what that means actually? |
comment:17
numpy-1.5.1
numpy-1.6.1
|
comment:18
For some reason numpy.linspace return an array with sage objects rather than just floats. I am guessing it may be deeper than that. Numpy probably uses sage types rather than converting to numpy types. The types of a[0] to a[4] is strange, is there a sage type for floats? I mean I tried numpy.linspace(0,2.0,6) and I got <type 'sage.rings.real_mpfr.RealNumber'> for a[0] to a[4] and <type 'sage.rings.real_mpfr.RealLiteral'> for a[5]. Doing a cast numpy.array(a,dtype=float) returns something that will work. |
This comment has been minimized.
This comment has been minimized.
comment:20
I'll be starting to make patches to correct the doctests and document the new behavior in numpy 1.6.x. Some documentation may need updating. |
comment:21
Actually I am a bit confused by one of the tests:
That function is independent of x, the next example after this depend on both x and y. I am suspecting the messages we get in this particular case is quite justified and it is surprising we didn't get any before. I am not sure what the correct formula should be. |
comment:22
I am guessing it should have been
y being the time and x the population in thousands. That satisfy a simple dimensional analysis. |
comment:23
No, wasn't it right before? That's the standard logistic population model, where y is the population. See http://en.wikipedia.org/wiki/Logistic_function#In_ecology:_modeling_population_growth, for example. |
comment:24
|
comment:25
Sorry for that noise. Jason is right.
This should be ok. The point is that the slope dy/dx is a function of y only; this can be completely symbolically solved using separation of variables to get the logistic function.
If this is the division by zero stuff, it's the whole business with the arrowheads having zero length. See #11208. I think Jason has a fix for this, actually, but I don't recall the whole story of what happened once it was reported to mpl. |
suppress divide warnings in riemann.pyx |
comment:117
Attachment: trac_11334-suppressdivide.patch.gz OK, so the above
does not fail when testing using |
comment:118
Yes very curious things like that happens. I am preparing a new set of patch with a different strategy to deal with riemann.pyx. I already uploaded one but I need to make a new patch for other divide warnings not coming from riemann.pyx - people willingly wanting to see 1/0 results. |
Attachment: trac_11334-divide-v2.patch.gz fix non riemann.pyx divivde by zero warnings |
This comment has been minimized.
This comment has been minimized.
comment:119
OK new patch set. If that doesn't work for you we have a serious problem. Back to need review. |
Reviewer: Steven Trogdon |
comment:120
It's odd that one has to resort to such "trickery" to ignore warnings. However, it is not without warrant since the ignore mechanism was already operative at a certain level in riemann.pyx. This works for me here - all "divide by zero" warnings have been removed from output and everything survives |
comment:121
I suspect the strange behavior we have seen may be a symptom of something deeper on the way the doctesting framework deals with warnings. Anyway it should be sorted by that last couple of patch for this case. |
Author: François Bissey |
comment:124
Attachment: 11334_noise2.patch.gz attachment: 11334_noise2.patch (numerical noise on OS X 10.8) needs review. |
This comment has been minimized.
This comment has been minimized.
comment:126
When I first saw that I was wondering if it was a combination with python 2.7.4 but I haven't conducted any test on OS X 10.8. The patch looks fine to me and is compatible with the rest. I am taking it as a reviewer patch and putting this back to positive review. |
Changed reviewer from Steven Trogdon to Steven Trogdon, Jeroen Demeyer |
Merged: sage-5.10.beta0 |
Numpy-1.7.0 is now available and fixes the coercion problem that prevented us to go to numpy-1.6.x.
New spkg: http://spkg-upload.googlecode.com/files/numpy-1.7.0.spkg
Apply:
Depends on #12415
Depends on #13992
Upstream: Fixed upstream, in a later stable release.
CC: @kiwifb @kini @SnarkBoojum
Component: packages: standard
Keywords: sd40.5
Author: François Bissey
Reviewer: Steven Trogdon, Jeroen Demeyer
Merged: sage-5.10.beta0
Issue created by migration from https://trac.sagemath.org/ticket/11334
The text was updated successfully, but these errors were encountered: