Hi Travis
2008/5/13 Travis E. Oliphant <[EMAIL PROTECTED]>:
> I think Stefan is asking me, not you.I don't think you should feel
> any sense of guilt. I was the one who closed the ticket sans
> regression test. I tend to still be of the opinion that a bug fix
> without a regression tes
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 S
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
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:
> 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.
>> >
>> > Stran
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 pa
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:
>
> (*&@#*&
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
>>>
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
This is a test
-teo
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
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
> nump
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. Speci
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 to more situations where the ma
> version
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 b
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
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]>:
> The earlier strategy, of putting the old version solely in oldnumeric,
> is somewhat less likely to cause the problem because it requires anyone
> wanting the old version to deliberately select it--so at least the
> person is then aware that somethin
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 def
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. (Pie
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 50837
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 /usr/lib/
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 c
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 cr
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 2434
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
Numpy-discussion@s
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
___
Numpy-di
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 np.oldn
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 f
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
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.
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
> wh
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
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
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
> corre
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
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 de
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 pa
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 b
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...
>
>
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
> (np.seterr(invalid='rai
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 subcl
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 eni
> 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
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-bas
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 undesirab
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 t
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 have
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 the
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 b
49 matches
Mail list logo
