Hi,
I recently upgraded to numpy 1.5.0 and now I get warnings when I take
the logarithm of 0.
In [5]: np.log(0.)
Warning: divide by zero encountered in log
Out[5]: -inf
I want to evaluate x * log(x) where its value is defined as 0 when x=0
so I have the following function:
def safe_x_log_x(x
Hi,
My array of integers is printed like this by default in numpy:
array([[ 4.7500e+02, 9.5000e+02, -1.e+00],
[ 2.6090e+03, 9.5000e+02, -7.0900e+02]])
Can I set an option so that numpy never uses this scientific notation or
raise the threshold at whic
Benjamin Root wrote:
> On Tue, Jul 13, 2010 at 12:45 PM, Kurt Smith <mailto:kwmsm...@gmail.com>> wrote:
>
> On Tue, Jul 13, 2010 at 11:54 AM, John Reid
> mailto:j.r...@mail.cryst.bbk.ac.uk>>
> wrote:
> > Hi,
> >
> > I ha
Hi,
I have some arrays of various shapes in which I need to set any NaNs to
0. I have been doing the following:
a[numpy.where(numpy.isnan(a)] = 0.
as you can see here:
In [20]: a=numpy.ones(2)
In [21]: a[1]=numpy.log(-1)
In [22]: a
Out[22]: array([ 1., NaN])
In [23]: a[numpy.where(numpy
David Cournapeau wrote:
> (Continuing the discussion initiated in the neighborhood iterator thread)
> - Chuck suggested to drop python < 2.6 support from now on. I am
> against it without a very strong and detailed rationale, because many OS
> still don't have python 2.6 (RHEL, Ubuntu LTS).
I
Charles R Harris wrote:
>
>
> On Sat, Mar 28, 2009 at 5:32 AM, John Reid <mailto:j.r...@mail.cryst.bbk.ac.uk>> wrote:
>
>
>
> Charles R Harris wrote:
> > What really matters is if python is 64 bits. Most 64 bit systems also
> > run 32
Charles R Harris wrote:
> What really matters is if python is 64 bits. Most 64 bit systems also
> run 32 bit binaries.
Are you saying that even if "uname -m" gives i686, I still might be able
to build a 64 bit python and numpy?
___
Numpy-discussion
Charles R Harris wrote:
> What platform are you on? I'm guessing Mac. You can check python on unix
> type systems with
>
> $[char...@f9 ~]$ file `which python`
> /usr/bin/python: ELF 32-bit LSB executable, Intel 80386, version 1
> (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.
Charles R Harris wrote:
> What platform are you on? I'm guessing Mac. You can check python on unix
> type systems with
>
> $[char...@f9 ~]$ file `which python`
> /usr/bin/python: ELF 32-bit LSB executable, Intel 80386, version 1
> (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.
David Cournapeau wrote:
> from platform import machine
> print machine()
>
> Should give you something like x86_64 for 64 bits intel/amd architecture,
In [3]: from platform import machine
In [4]: print machine()
i686
Now I'm wondering why the OS isn't 64 bit but that's not for discussion
her
Sorry for noise, it is my mistake. My assumption that the box is 64 bit
was wrong :(
At least the processors are 64 bit :
Intel® Core™2 Duo Processor T9600
but uname -m reports:
i686
which as far as I understand means it thinks it is a 32 bit processor.
If anyone knows better please let me
I imagine I'm using 64 bit numpy as I made a vanilla install from recent
source on a 64 bit box but how can I tell for sure? I have some problems
creating large arrays.
In [29]: a=numpy.empty((1024, 1024, 1024), dtype=int8)
works just fine
In [30]: a=numpy.empty((1024, 1024, 2048), dtype=int8
Ok so crashing is always bad. What I should have said is that I think
errors are bad in almost all cases as well. The norm returning zero
seems sensible to me so perhaps inversions and such should raise exceptions.
I would much prefer no errors were raised except where necessary.
Like I said I
David Cournapeau wrote:
> Hi,
>
> I was wondering what an empty matrix is, and what it is useful for
> (by empty matrix, I mean something created by numpy.matrix([])) ? Using
> those crash some functions (see for example scipy ticket #381), and I am
> not sure how to fix this bug.
>
>
David Cournapeau wrote:
> John Reid wrote:
> I think most developers use subversion, indeed. It is not enforced, but
> my impression is that people try pretty hard to avoid breaking the main
> trunk (that is using the last subversion is not more buggy than a
> release). At leas
David Cournapeau wrote:
> John Reid wrote:
>> Ok I'll try that although I guess that it turns off all warnings. that
>> I'm concerned as well that scipy's release cycle isn't as quick as it
>> could be.
>>
> Well, quite the contrary, it is as
Ok I'll try that although I guess that it turns off all warnings. that
I'm concerned as well that scipy's release cycle isn't as quick as it
could be.
John.
Alexandre Fayolle wrote:
> On Wed, Jul 04, 2007 at 11:15:58AM +0100, John Reid wrote:
>> Hi,
>>
>
Hi,
Is there going to be a scipy release anytime soon?
I'm using numpy 1.0.3 with scipy 0.5.2 and I get these ugly warnings all
the time:
c:\apps\python25\lib\site-packages\scipy\misc\__init__.py:25:
DeprecationWarning: ScipyTest is now called NumpyTest; please update
your code
test = Scip
18 matches
Mail list logo
