On Mon, May 12, 2008 at 12:37 AM, Anne Archibald
[EMAIL PROTECTED] wrote:
2008/5/11 Robert Kern [EMAIL PROTECTED]:
Perhaps, but ufuncs only allow 0 or 1 for this value, currently.
That's a shame, minus infinity is the identity for maximum too.
Also, I was wrong about using PyUFunc_ff_f.
On Sun, May 11, 2008 at 10:42 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
I dunno. I tend to agree with Mike Ressler that Numpy really shouldn't
change very quickly. We can add new features now and then, or move more
stuff to type specific functions, but those aren't really user visible.
On Mon, May 12, 2008 at 12:43 AM, Jarrod Millman [EMAIL PROTECTED] wrote:
On Sun, May 11, 2008 at 9:42 PM, Robert Kern [EMAIL PROTECTED] wrote:
The semantics of major.minor.micro for numpy got confused because of
an early mistake (IMO) wherein we designated 1.1 as a release which
would allow
On Mon, May 12, 2008 at 12:17 AM, Jarrod Millman [EMAIL PROTECTED]
wrote:
On Sun, May 11, 2008 at 10:42 PM, Charles R Harris
[EMAIL PROTECTED] wrote:
I dunno. I tend to agree with Mike Ressler that Numpy really shouldn't
change very quickly. We can add new features now and then, or move
Could we add a from __future__ import something along with a
deprecation warning?
This could be used for Tim's new matrix class, or any other API change.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/ORR(206) 526-6959 voice
7600 Sand
On Mon, 2008-05-12 at 00:39 -0600, Charles R Harris wrote:
Which makes the spot where a gets initialized almost invisible. It is
amazing how much easier the code is to read and understand with these
simple changes. But if we plan tasks for the release, then we also
have to assign people to
On Sun, May 11, 2008 at 11:31 PM, Robert Kern [EMAIL PROTECTED] wrote:
That's not what I'm referring to. Before 1.0 was released, people were
worried about the stability of the API, and Travis said that 1.0.x
would maintain API compatibility, but that 1.1, maybe a year from
now, would be the
2008/5/12 Jarrod Millman [EMAIL PROTECTED]:
I agree, but we also have the problem that we don't have adequate
tests. I don't think we realized the extent to which MaskedArrays
necessitated code rewrites until Charles Doutriaux pointed out how
much difficulty the change was causing to their
On Mon, May 12, 2008 at 12:09 AM, Stéfan van der Walt [EMAIL PROTECTED] wrote:
Which brings me to my next point: we have very limited (human)
resources, but releasing frequently is paramount. To what extent can
we automate the release process? I've asked this question before, but
I haven't
ma, 2008-05-12 kello 09:09 +0200, Stéfan van der Walt kirjoitti:
[clip]
As for the NumPy unit tests: I have placed coverage reports online
(http://mentat.za.net/numpy/coverage). This only covers Python (not
extension) code, but having that part 100% tested is not impossible,
nor would it take
On 12 May 2008, at 04:59, David Cournapeau wrote:
Also, time-based releases are by definition predictable, and
as such, it is easier to plan upgrades for users
As long as it does not imply that users have to upgrade every 3
months, because for some users this is impossible and/or
Joris De Ridder wrote:
As long as it does not imply that users have to upgrade every 3
months, because for some users this is impossible and/or undesirable.
By 'upgrading' I'm not only referring to numpy/scipy, but also to
external packages based on numpy/scipy.
As I said, time-based
On Sun, May 11, 2008 at 12:16 PM, Alan G Isaac [EMAIL PROTECTED] wrote:
To be specific: I do not recall any place in the NumPy Book
where this behavior is promised.
On Sun, 11 May 2008, Robert Kern apparently wrote:
It's promised in the docstring! A matrix is
a specialized 2-d array
On Mon, May 12, 2008 at 1:46 AM, Chris.Barker [EMAIL PROTECTED] wrote:
Could we add a from __future__ import something along with a
deprecation warning?
That's a Python language feature. It is not available to us.
--
Robert Kern
I have come to believe that the whole world is an enigma, a
All,
I fixed the power function in numpy.ma following Anne's suggestion: compute
first, mask the problems afterwards. It's a quick and dirty fix that crashes
if the user has set its error system to raise an exception on invalid
(np.seterr(invalid='raise')), but it works otherwise and keeps
2008/5/12 Pierre GM [EMAIL PROTECTED]:
I fixed the power function in numpy.ma following Anne's suggestion: compute
first, mask the problems afterwards. It's a quick and dirty fix that crashes
if the user has set its error system to raise an exception on invalid
On Monday 12 May 2008 12:04:24 Stéfan van der Walt wrote:
2008/5/12 Pierre GM [EMAIL PROTECTED]:
What should I do with oldnumeric.ma.power ? Try to fix it the same
way, or leave the bug ? I'm not that enthusiastic to have to debug the
old package, but if it's part of the job...
We should
On Mon, May 12, 2008 at 2:08 AM, Jarrod Millman [EMAIL PROTECTED] wrote:
Are you saying that the changes to histogram and median should require
waiting until 2.0--several years from now? When I say that we may
allow minor API breakage this is the kind of thing I mean. I think
that both
On Mon, May 12, 2008 at 5:31 AM, Joris De Ridder
[EMAIL PROTECTED] wrote:
As long as it does not imply that users have to upgrade every 3
months, because for some users this is impossible and/or undesirable.
By 'upgrading' I'm not only referring to numpy/scipy, but also to
external
Hello,
I'm having trouble getting the python-numpy RPM to build under
CentOS 4.6. I've already built and installed atlas, lapack3 and
refblas3 from the CentOS 5 source RPMS, but numpy won't build
correctly. Although the ultimate error may be unrelated to Atlas,
clearly not all the atlas
On Mon, May 12, 2008 at 9:18 AM, Robert Kern [EMAIL PROTECTED] wrote:
The MA situation was handled slightly differently, which is
unfortunate. I think that it is a reasonable change to make in a
minor release, but we should have provided a warning first. At least,
we are
On Mon, May 12, 2008 at 11:50 AM, Chris Miller [EMAIL PROTECTED] wrote:
Hello,
I'm having trouble getting the python-numpy RPM to build under
CentOS 4.6. I've already built and installed atlas, lapack3 and
refblas3 from the CentOS 5 source RPMS, but numpy won't build
correctly.
Jarrod Millman wrote:
I can't imagine why anyone would have to upgrade. Could you explain
under what circumstances you would see having to upgrade just because
their is a new upstream release? I think I must be misunderstanding
your concern.
One circumstance in which you would need to
On Mon, May 12, 2008 at 5:41 AM, David Cournapeau
[EMAIL PROTECTED] wrote:
Joris De Ridder wrote:
As Mike, I'm a bit sceptic about the whole idea. The current way
doesn't seem broken, so why fix it?
If the recent events do not show that something went wrong, I don't know
what will
Robert Kern wrote:
It looks like nothing actually executed python setup.py install to
put the files into /var/tmp/python-numpy-1.0.4-build/. I suspect a
problem in the spec file. Unfortunately, I am not familiar with
building RPMs, so I don't know where you got the spec file from or
where
On Mon, May 12, 2008 at 10:30 AM, Pierre GM [EMAIL PROTECTED] wrote:
numpy.oldnumeric.ma is not bug-free, however: Charles recently pointed out a
problem with power, that failed to work properly with a float exponent. We
fixed the problem in numpy.ma, but left the old package unmodified. In
On Mon, May 12, 2008 at 10:02 AM, Christopher Hanley [EMAIL PROTECTED] wrote:
One circumstance in which you would need to upgrade is if you distribute
software with a numpy dependency. If your user base upgrades to the
latest numpy release, and that latest release breaks your code, you will
On Mon, May 12, 2008 at 12:29 PM, Chris Miller [EMAIL PROTECTED] wrote:
Robert Kern wrote:
It looks like nothing actually executed python setup.py install to
put the files into /var/tmp/python-numpy-1.0.4-build/. I suspect a
problem in the spec file. Unfortunately, I am not familiar
On Monday 12 May 2008 13:48:55 you wrote:
1. It seemed to me that a lot of the users of the old ma
implementation called it from np.core. Since the new implementation
doesn't get called from there, would it make sense to have the old
implementation reside in np.core rather than in
Robert Kern wrote:
Can you show us
$ ls -l /usr/lib/atlas/sse2
# ls -l /usr/lib/atlas/sse2
total 3868
-rw-r--r-- 1 root root 3705240 May 11 13:02 libblas.so.3.0
-rw-r--r-- 1 root root 243466 May 11 13:02 liblapack.so.3.0
Chris
___
To close out this thread:
With r5155 Travis fixed the problem, so the ticket is closed.
Thank you!
Eric
Eric Firing wrote:
I have added a patch to the ticket. I believe it fixes the problem. It
___
Numpy-discussion mailing list
On Mon, May 12, 2008 at 1:10 PM, Chris Miller [EMAIL PROTECTED] wrote:
Robert Kern wrote:
Can you show us
$ ls -l /usr/lib/atlas/sse2
# ls -l /usr/lib/atlas/sse2
total 3868
-rw-r--r-- 1 root root 3705240 May 11 13:02 libblas.so.3.0
-rw-r--r-- 1 root root 243466 May 11
Hi,
As Fernando mentioned, we are considering moving to a time-based
released process with IPython1. Obviously, IPython1 is a very
different project than numpy, but I figured it might be useful to
state some of the other reasons we are thinking about going this
direction:
1. It stops feature
Jarrod Millman wrote:
[...]
It is very clear that our users are not happy with the amount of API
breaks in 1.1. All I can say, is that I am sorry that the current
release is going to break some code bases out there. I am trying to
figure out if there is a way to mitigate the problems
Robert Kern wrote:
Okay, can you also do the following:
$ ls -l /usr/lib/lib{lapack,f77blas,cblas,atlas}.*
$ ls -l /usr/lib/atlas/lib{lapack,f77blas,cblas,atlas}.*
-rw-r--r-- 1 root root 5083708 May 9 16:10 /usr/lib/liblapack.a
lrwxrwxrwx 1 root root 18 May 11 10:47
On Mon, May 12, 2008 at 2:19 PM, Chris Miller [EMAIL PROTECTED] wrote:
Robert Kern wrote:
Okay, can you also do the following:
$ ls -l /usr/lib/lib{lapack,f77blas,cblas,atlas}.*
$ ls -l /usr/lib/atlas/lib{lapack,f77blas,cblas,atlas}.*
-rw-r--r-- 1 root root 5083708 May 9
This is a patch for the previous message; I got distracted and failed to
finish a sentence.
Eric Firing wrote:
[...]
versions are unintentionally mixed. This will probably work if an
old_ma array ends up as input for a new_ma function, but the reverse
often will not work correctly.
Robert Kern wrote:
On Mon, May 12, 2008 at 2:19 PM, Chris Miller [EMAIL PROTECTED] wrote:
On the f77 stuff, I read specifically to delete the gcc-f77 package
as that conflicts with gcc-gfortran. The latter we are using is
actually gcc4 not gcc3 (fyi). I see in Atlas that G77 is defined as
Brian Granger wrote:
Hi,
As Fernando mentioned, we are considering moving to a time-based
released process with IPython1. Obviously, IPython1 is a very
different project than numpy, but I figured it might be useful to
state some of the other reasons we are thinking about going this
2008/5/12 Eric Firing [EMAIL PROTECTED]:
To close out this thread:
With r5155 Travis fixed the problem, so the ticket is closed.
Strange, when I look over that patch, my keyboard automatically holds
in Shift and starts typing 1 through 9:
(*@#*@#[EMAIL PROTECTED](*)@#
I ask you with tears
On Mon, May 12, 2008 at 12:57 PM, Stéfan van der Walt [EMAIL PROTECTED] wrote:
I think that's a good idea. If I recall correctly, numpy.core.ma had
been exposed as numpy.ma, and some code uses it. Having an old and a
new version in places where previously only the old version used to be
Robert,
I looked in the build directory from Atlas and it is indeed
generating the additional libraries. I copied them over to /usr/lib
and rebuilt the numpy RPM. Indeed the behavior is different, and
numpy sees the libraries. Of course some new oddities have entered
the equation.
On Mon, May 12, 2008 at 3:44 PM, Chris Miller [EMAIL PROTECTED] wrote:
Robert,
I looked in the build directory from Atlas and it is indeed
generating the additional libraries. I copied them over to /usr/lib
and rebuilt the numpy RPM. Indeed the behavior is different, and
numpy sees
This is a test
-teo
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
2008/5/12 Jarrod Millman [EMAIL PROTECTED]:
On Mon, May 12, 2008 at 12:05 PM, Eric Firing [EMAIL PROTECTED] wrote:
As one who pushed for the MA transition, I appreciate your suggestion.
It may have one unintended consequence, however, that may cause more
trouble than it saves: it may lead
Anne Archibald wrote:
2008/5/12 Jarrod Millman [EMAIL PROTECTED]:
On Mon, May 12, 2008 at 12:05 PM, Eric Firing [EMAIL PROTECTED] wrote:
As one who pushed for the MA transition, I appreciate your suggestion.
It may have one unintended consequence, however, that may cause more
trouble than
Stéfan van der Walt wrote:
2008/5/12 Eric Firing [EMAIL PROTECTED]:
To close out this thread:
With r5155 Travis fixed the problem, so the ticket is closed.
Strange, when I look over that patch, my keyboard automatically holds
in Shift and starts typing 1 through 9:
(*@#*@#[EMAIL
On Mon, May 12, 2008 at 6:00 PM, Eric Firing [EMAIL PROTECTED] wrote:
Stéfan van der Walt wrote:
2008/5/12 Eric Firing [EMAIL PROTECTED]:
To close out this thread:
With r5155 Travis fixed the problem, so the ticket is closed.
Strange, when I look over that patch, my keyboard
Robert Kern wrote:
On Mon, May 12, 2008 at 6:00 PM, Eric Firing [EMAIL PROTECTED] wrote:
Stéfan van der Walt wrote:
2008/5/12 Eric Firing [EMAIL PROTECTED]:
To close out this thread:
With r5155 Travis fixed the problem, so the ticket is closed.
Strange, when I look over that
Chris Miller wrote:
Hello,
I'm having trouble getting the python-numpy RPM to build under
CentOS 4.6. I've already built and installed atlas, lapack3 and
refblas3 from the CentOS 5 source RPMS, but numpy won't build
correctly. Although the ultimate error may be unrelated to Atlas,
Robert Kern wrote:
It's still called libf77blas regardless. Well, you don't have ATLAS
installed. Or if you do, it's an extremely weird installation of
ATLAS.
It is weird, but there is a rationale to the weirdness :) It is
basically imposible to build a rpm for ATLAS, because every build
Eric Firing wrote:
Stéfan van der Walt wrote:
2008/5/12 Eric Firing [EMAIL PROTECTED]:
To close out this thread:
With r5155 Travis fixed the problem, so the ticket is closed.
Strange, when I look over that patch, my keyboard automatically holds
in Shift and starts typing
52 matches
Mail list logo
