Hello
- Original Message -
From: "Peter C. Norton" <[EMAIL PROTECTED]>
To:
Sent: Saturday, April 28, 2007 12:27 AM
Subject: [Numpy-discussion] Building numpy - setting the run path
> Building numpy for my company's solaris distribution involves requring
> a run_path for the lapack+blas
Building numpy for my company's solaris distribution involves requring
a run_path for the lapack+blas libraries we're using (libsunperf,
though I'm considering swapping out for gsl since we may use that).
The situation we're in is that we need gcc to get the -R for paths
like /usr/local/gnu/lib /u
Russell E. Owen wrote:
> I often find myself doing simple math on sequences of numbers (which
> might or might not be numpy arrays) where I want the result (and thus
> the inputs) coerced to a particular data type.
>
> I'd like to be able to say:
>
> numpy.divide(seq1, seq2, dtype=float)
>
>
I often find myself doing simple math on sequences of numbers (which
might or might not be numpy arrays) where I want the result (and thus
the inputs) coerced to a particular data type.
I'd like to be able to say:
numpy.divide(seq1, seq2, dtype=float)
but ufuncs don't allow on to specify a r
Actually, all the points in this thread have been very good points but
I just want to add my 2 cents since I was in your boat just a month
ago and decided to try out python after seeing what it could do.
In short, I decided to look elsewhere as I was dealing with vector
data in database and mainta
Jouni K. Seppänen wrote:
> Hi,
>
> Either I have completely misunderstood what the out= arg to the take
> function is supposed to do, or there is a bug in numpy 1.0.2, as
> demonstrated below.
>
Thanks. Silly bug in C-code caused this.
-Travis
___
N
Anton Sherwood wrote:
>>> Jan Grant wrote:
>>>
. . . the space of doubles include a small number of things
that aren't representable by a rational (+/- inf, for instance).
>
>
>> Anton Sherwood wrote:
>>
>>> +1/0, -1/0
>>>
>
> David Goldsmith wrote:
>
Hi,
Either I have completely misunderstood what the out= arg to the take
function is supposed to do, or there is a bug in numpy 1.0.2, as
demonstrated below.
First, some initialization:
In [1]: from numpy import *
In [2]: a=arange(12).reshape((3,4))
In [3]: a
Out[3]:
array
Is there really no single method to call on an ndarray that asks: "what
endian are you"
I know not every two-liner should be made into a convenience method, but
this seems like a good candidate to me.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR
Hi,
Ed Schofield has created a patch for NumPy to work with BioPython (see below).
Bruce
-- Forwarded message --
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Mar 27, 2007 8:08 AM
Subject: [Biopython-dev] [Bug 2251] New: [PATCH] NumPy support for BioPython
To: [EMAIL PROTECTED
> > Jan Grant wrote:
> >> . . . the space of doubles include a small number of things
> >> that aren't representable by a rational (+/- inf, for instance).
> Anton Sherwood wrote:
> > +1/0, -1/0
David Goldsmith wrote:
> Are not unique representations for inf/-inf, (if that matters).
No rational
Anton Sherwood wrote:
> Jan Grant wrote:
>
>> . . . the space of doubles include a small number of things
>> that aren't representable by a rational (+/- inf, for instance).
>>
>
> +1/0, -1/0
>
>
Are not unique representations for inf/-inf, (if that matters).
DG
___
Jan Grant wrote:
> . . . the space of doubles include a small number of things
> that aren't representable by a rational (+/- inf, for instance).
+1/0, -1/0
--
Anton Sherwood, http://www.ogre.nu/
___
Numpy-discussion mailing list
Numpy-discussion@scip
Guido van Rossum wrote:
> On 4/27/07, Jan Grant <[EMAIL PROTECTED]> wrote:
>
>> On Thu, 26 Apr 2007, Dan Christensen wrote:
>>
>>
>>> Note also that double-precision reals are a subset of the rationals,
>>> since each double precision real is exactly representable as a
>>> rational number,
Bill Janssen wrote:
>> Jeffrey, is there any way you can drop the top of the tree and going
>> straight from Number to Complex -> Real -> Rational -> Integer? These
>> are the things that everyone with high school math will know.
>>
>
> I think knowledge of the concepts of group, ring, and fie
[EMAIL PROTECTED] wrote:
> Dear community,
>
> I have a question regarding the installation process of the Biopython
> toolbox ( http://biopython.org/DIST/docs/install/Installation.html#htoc14 ):
>
> I want to make sure that Numerical Python is correctly installed under
> Windows XP which it is n
On Thu, 26 Apr 2007, Dan Christensen wrote:
> Note also that double-precision reals are a subset of the rationals,
> since each double precision real is exactly representable as a
> rational number, but many rational numbers are not exactly
> representable as double precision reals. Not sure if t
Dear community,
I have a question regarding the installation process of the Biopython
toolbox ( http://biopython.org/DIST/docs/install/Installation.html#htoc14 ):
I want to make sure that Numerical Python is correctly installed under
Windows XP which it is not in my case:
>>> from Numeric import
On Apr 26, 6:58 am, "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> I would like to let users modify the
> built-ins, but such changes ought to be isolated from other
> interpreters running in the same address space. I don't want to be the
> one to tell the mod_python community they won't be able t
In article <[EMAIL PROTECTED]>,
Francesc Altet <[EMAIL PROTECTED]> wrote:
> El dj 26 de 04 del 2007 a les 11:38 -0700, en/na Russell E. Owen va
> escriure:
> > In converting some code from numarray to numpy I had this:
> > isBigendian = (arr.isbyteswapped() != numarray.isBigEndian)
> >
> > The o
> Jeffrey, is there any way you can drop the top of the tree and going
> straight from Number to Complex -> Real -> Rational -> Integer? These
> are the things that everyone with high school math will know.
I think knowledge of the concepts of group, ring, and field is
supposed to be standard know
> Are the base number operations in Python all that difficult to
> understand?
Well, they're a little tricky.
But the basic problem with "number" support, in almost every
programming language, is that they are too low-level an abstraction.
A number in a program is never *just* an integer or a flo
In article <[EMAIL PROTECTED]>,
Christopher Hanley <[EMAIL PROTECTED]> wrote:
> Russell,
>
> This should work as a consistent test for bigendian:
>
> -> isBigEndian = (obj.dtype.str[0] == '>')
>
> Also, I have ported numarray's numdisplay to numpy if you would like to
> directly display an ar
On Fri, 27 Apr 2007, Jeffrey Yasskin wrote:
> Then again, doubles aren't a group either because of this
> imprecision, and I'm suggesting claiming they're
> a subclass of that, so maybe there's room in a practical
> language to make them a subclass of the rationals too.
Would using language f
On 4/27/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 4/27/07, Jan Grant <[EMAIL PROTECTED]> wrote:
> > On Thu, 26 Apr 2007, Dan Christensen wrote:
> >
> > > Note also that double-precision reals are a subset of the rationals,
> > > since each double precision real is exactly representable a
On 4/27/07, Jan Grant <[EMAIL PROTECTED]> wrote:
> On Thu, 26 Apr 2007, Dan Christensen wrote:
>
> > Note also that double-precision reals are a subset of the rationals,
> > since each double precision real is exactly representable as a
> > rational number, but many rational numbers are not exactly
On Fri, Apr 27, 2007 at 07:52:16AM -0600, Charles R Harris wrote:
> On 4/27/07, Glen W. Mabey <[EMAIL PROTECTED]> wrote:
> >
> >The following works fine with a python 2.4.3 installation, but with
> >2.5.1 I get:
> >
> >
> >In [1]:import numpy
> >
> >In [2]:fid = file( '/tmp/tfile', 'w' )
> >
> >In
On 4/27/07, Glen W. Mabey <[EMAIL PROTECTED]> wrote:
The following works fine with a python 2.4.3 installation, but with
2.5.1 I get:
In [1]:import numpy
In [2]:fid = file( '/tmp/tfile', 'w' )
In [3]:fid.write( numpy.zeros( 55 ).data )
---
On Fri, Apr 27, 2007 at 08:38:28AM -0500, Glen W. Mabey wrote:
> The following works fine with a python 2.4.3 installation, but with
> 2.5.1 I get:
>
>
> In [1]:import numpy
>
> In [2]:fid = file( '/tmp/tfile', 'w' )
>
> In [3]:fid.write( numpy.zeros( 55 ).data )
> -
The following works fine with a python 2.4.3 installation, but with
2.5.1 I get:
In [1]:import numpy
In [2]:fid = file( '/tmp/tfile', 'w' )
In [3]:fid.write( numpy.zeros( 55 ).data )
---
Traceback (most recent
Stefan van der Walt wrote:
>
> Ah, yes, I was confused. What I meant to ask was, couldn't
> dtype.str[0] sometimes be '|'?
>
>
That is true. It would happen for an array of strings.
>>> a = n.array(['1','2','3','4'])
>>> a.dtype.str[0]
'|'
I haven't needed to worry about that case in te
On Fri, Apr 27, 2007 at 08:49:16AM -0400, Christopher Hanley wrote:
> >> -> isBigEndian = (obj.dtype.str[0] == '>')
> >
> > Is this test always safe, even on big endian machines? Couldn't the
> > dtype.str[0] sometimes be '='?
> >
> The test does would on big endian machines. What wouldn't wor
Stefan van der Walt wrote:
> On Thu, Apr 26, 2007 at 05:22:42PM -0400, Christopher Hanley wrote:
>
>> This should work as a consistent test for bigendian:
>>
>> -> isBigEndian = (obj.dtype.str[0] == '>')
>>
>
> Is this test always safe, even on big endian machines? Couldn't the
> dtype.str
On Thu, Apr 26, 2007 at 05:22:42PM -0400, Christopher Hanley wrote:
> This should work as a consistent test for bigendian:
>
> -> isBigEndian = (obj.dtype.str[0] == '>')
Is this test always safe, even on big endian machines? Couldn't the
dtype.str[0] sometimes be '='?
Regards
Stéfan
___
34 matches
Mail list logo
