On Tue, Nov 2, 2010 at 11:43 AM, Charles R Harris
wrote:
>
> It seems to be more of a problem on 32 bits, what with the variety of sse*.
> OTOH, all 64 bit systems have at least sse2 available together with more sse
> registers and I believe the x87 instruction set is not available when
> running
On Mon, Nov 1, 2010 at 7:49 PM, Robert Kern wrote:
> On Mon, Nov 1, 2010 at 20:21, Charles R Harris
> wrote:
> >
> > On Mon, Nov 1, 2010 at 5:30 PM, Joon wrote:
> >>
> >> Hi,
> >>
> >> I just found that using dot instead of sum in numpy gives me better
> >> results in terms of precision loss. F
Thanks for the replies. I tried several stuff like changing dot into sum in the gradient calculations just to see how they change the results, but it seems that part of the code is the only place where the results get affected by the choice of dot/sum. I am using 64bit machine and EPD python (I
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:
>
>
On Mon, Nov 1, 2010 at 20:21, Charles R Harris
wrote:
>
> On Mon, Nov 1, 2010 at 5:30 PM, 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. Fo
On Mon, Nov 1, 2010 at 5:30 PM, 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 t
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.
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 arc
On Mon, Nov 1, 2010 at 12:35, Juanjo Gomez Navarro
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
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 vers
Hi Friedrich,
On Wed, Oct 27, 2010 at 10:30 PM, Ralf Gommers
wrote:
> On Wed, Oct 27, 2010 at 1:23 AM, Friedrich Romstedt
> 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/
On Mon, Nov 1, 2010 at 7:39 PM, Ralf Gommers
wrote:
> On Sun, Oct 31, 2010 at 2:46 PM, David Cournapeau 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
On Sun, Oct 31, 2010 at 2:46 PM, David Cournapeau 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 app
13 matches
Mail list logo
