Re: Including fix for #1637 in 1.5.1 ?

On Sun, Oct 31, 2010 at 2:46 PM, David Cournapeau <cournape <at> gmail.com> wrote:
> Hi,
>
> I just committed a quick fix for
> http://projects.scipy.org/numpy/ticket/1637. I did want to include it
> for 1.5.x branch as it is already in RC stage, but it may still be
> useful to do so if the release managers think it is appropriate (there
> is a test for it):
> http://github.com/numpy/numpy/commit/cdcbaa4ce4b47a7bfd8905222124fd22460252a5
>

I would prefer not to include it at this stage - this doesn't seem an
important enough bug to me to throw in compiled code at the last
moment. Backporting after 1.5.1 is released may make sense though, in
case there's a 1.5.2.

Cheers,
Ralf

Re: Including fix for #1637 in 1.5.1 ?

On Mon, Nov 1, 2010 at 7:39 PM, Ralf Gommers
<ralf.gommers <at> googlemail.com> wrote:
> On Sun, Oct 31, 2010 at 2:46 PM, David Cournapeau <cournape <at> gmail.com> wrote:
>> Hi,
>>
>> I just committed a quick fix for
>> http://projects.scipy.org/numpy/ticket/1637. I did want to include it
>> for 1.5.x branch as it is already in RC stage, but it may still be
>> useful to do so if the release managers think it is appropriate (there
>> is a test for it):
>> http://github.com/numpy/numpy/commit/cdcbaa4ce4b47a7bfd8905222124fd22460252a5
>>
>
> I would prefer not to include it at this stage - this doesn't seem an
> important enough bug to me to throw in compiled code at the last
> moment.

Ok, no problem. I will backport it to 1.5.x, if only to help during
the 1.5 -> 2.0 transition.

cheers,

David

Re: ANN: NumPy 1.5.1 release candidate 1

Hi Friedrich,

On Wed, Oct 27, 2010 at 10:30 PM, Ralf Gommers
<ralf.gommers <at> googlemail.com> wrote:
> On Wed, Oct 27, 2010 at 1:23 AM, Friedrich Romstedt
> <friedrichromstedt <at> gmail.com> wrote:
>> I found some issues on Mac OS X 10.5 ppc in py2.5.4:

Can you please check if this takes care of all test failures you
reported: http://github.com/rgommers/numpy/commit/2ac0be7171f.

If not can you please adapt the patch a bit to make it work (should be
straightforward)?

Thanks,
Ralf

Path to numpy installation

_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion <at> scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: Path to numpy installation

On Mon, Nov 1, 2010 at 12:35, Juanjo Gomez Navarro
<juanjo.gomeznavarro <at> gmail.com> wrote:
> Hi, I have just updated my old version of numpy 1.01 to the version 1.5 in
> my Mac. The problem is that the system does not seem to recognize the new
> version.
> When I type print numpy.__path__ I get
> /System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/numpy
> But the new version I have just installed is in
> /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/numpy
> I don't know
> how to change the path of the installation, or how to say python to search numpy in the new path
> Any idea???

When you run "python", apparently you are picking up the system's
Python executable in /System/Library, not the other Python interpreter
that you installed under /Library. You need to adjust your $PATH
environment variable to put
/Library/Frameworks/Python.framework/Versions/Current/bin before
/usr/bin. Then when you type "python", you will get this installation
of Python and all of its libraries.

--

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion <at> scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: np.ma.masked_invalid and precision

Pierre GM-2 wrote:
> 
> Mmh, probably a bug, I'd say.
> Mind opening a ticket ? 
> Thanks in advance
> P.
> 
> 

Done - Ticket #1657
--

-- 
View this message in context: http://old.nabble.com/np.ma.masked_invalid-and-precision-tp30100542p30107931.html
Sent from the Numpy-discussion mailing list archive at Nabble.com.

Precision difference between dot and sum

Hi,

I just found that using dot instead of sum in numpy gives me better  
results in terms of precision loss. For example, I optimized a function  
with scipy.optimize.fmin_bfgs. For the return value for the function, I  
tried the following two things:

sum(Xb) - sum(denominator)

and

dot(ones(Xb.shape), Xb) - dot(ones(denominator.shape), denominator)

Both of them are supposed to yield the same thing. But the first one gave  
me -589112.30492110562 and the second one gave me -589112.30492110678.

In addition, with the routine using sum, the optimizer gave me "Warning:  
Desired error not necessarily achieved due to precision loss." With the  
routine with dot, the optimizer gave me "Optimization terminated  
successfully."
I checked the gradient value as well (I provided analytical gradient) and  
gradient was smaller in the dot case as well. (Of course, the the  
magnitude was e-5 to e-6, but still)

I was wondering if this is well-known fact and I'm supposed to use dot  
instead of sum whenever possible.

It would be great if someone could let me know why this happens.
Thank you,
Joon

_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion <at> scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: Precision difference between dot and sum

_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion <at> scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: Precision difference between dot and sum

On Mon, Nov 1, 2010 at 20:21, Charles R Harris
<charlesr.harris <at> gmail.com> wrote:
>
> On Mon, Nov 1, 2010 at 5:30 PM, Joon <groups.and.lists <at> gmail.com> wrote:
>>
>> Hi,
>>
>> I just found that using dot instead of sum in numpy gives me better
>> results in terms of precision loss. For example, I optimized a function with
>> scipy.optimize.fmin_bfgs. For the return value for the function, I tried the
>> following two things:
>>
>> sum(Xb) - sum(denominator)
>>
>> and
>>
>> dot(ones(Xb.shape), Xb) - dot(ones(denominator.shape), denominator)
>>
>> Both of them are supposed to yield the same thing. But the first one gave
>> me -589112.30492110562 and the second one gave me -589112.30492110678.
>>
>> In addition, with the routine using sum, the optimizer gave me "Warning:
>> Desired error not necessarily achieved due to precision loss." With the
>> routine with dot, the optimizer gave me "Optimization terminated
>> successfully."
>>
>> I checked the gradient value as well (I provided analytical gradient) and
>> gradient was smaller in the dot case as well. (Of course, the the magnitude
>> was e-5 to e-6, but still)
>>
>> I was wondering if this is well-known fact and I'm supposed to use dot
>> instead of sum whenever possible.
>>
>> It would be great if someone could let me know why this happens.
>
> Are you running on 32 bits or 64 bits? I ask because there are different
> floating point precisions on the 32 bit platform and the results can depend
> on how the compiler does things.

Eh, what? Are you talking about the sometimes-differing intermediate
precisions? I wasn't aware that was constrained to 32-bit processors.

--

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion <at> scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: Precision difference between dot and sum

On 11/02/2010 08:30 AM, Joon wrote:
> Hi,
>
> I just found that using dot instead of sum in numpy gives me better
> results in terms of precision loss. For example, I optimized a function
> with scipy.optimize.fmin_bfgs. For the return value for the function, I
> tried the following two things:
>
> sum(Xb) - sum(denominator)
>
> and
>
> dot(ones(Xb.shape), Xb) - dot(ones(denominator.shape), denominator)
>
> Both of them are supposed to yield the same thing. But the first one
> gave me -589112.30492110562 and the second one gave me -589112.30492110678.

Those are basically the same number: the minimal spacing between two 
double floats at this amplitude is ~ 1e-10 (given by the function 
np.spacing(the_number)), which is essentially the order of magnitude of 
the difference between your two numbers.

> I was wondering if this is well-known fact and I'm supposed to use dot
> instead of sum whenever possible.

You should use dot instead of sum when application, but for speed 
reasons, essentially.

>
> It would be great if someone could let me know why this happens.

They don't use the same implementation, so such tiny differences are 
expected - having exactly the same solution would have been surprising, 
actually. You may be surprised about the difference for such a trivial 
operation, but keep in mind that dot is implemented with highly 
optimized CPU instructions (that is if you use ATLAS or similar library).

cheers,

David