On Sat, Apr 19, 2008 at 12:20 AM, Travis E. Oliphant <[EMAIL PROTECTED]>
wrote:
> Charles R Harris wrote:
> > The signature for a ufunc is something like
> >
> > @[EMAIL PROTECTED]@kind@(char **args, intp *dimensions, intp *steps, void
> > *func)
> >
> > Which contains all the info necessary to d
On Sat, Apr 19, 2008 at 1:32 AM, Joe Harrington <[EMAIL PROTECTED]> wrote:
> What wasn't obvious was how to cast an array to bool.
Just like any other type:
x.astype(bool)
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by ou
> Just cast your arrays to booleans if you want to do boolean operations
> on them.
It turns out there's an even better way: logical_and() and its friends
do boolean operations on arrays.
IDL solves the problem exactly as numpy does, erroring on arrays in
conditionals and short-circuiting boolean
Charles R Harris wrote:
> The signature for a ufunc is something like
>
> @[EMAIL PROTECTED]@kind@(char **args, intp *dimensions, intp *steps, void
> *func)
>
> Which contains all the info necessary to do a sort. Means and other
> such functions could also be implemented that way.
I dont' think t
On Fri, Apr 18, 2008 at 11:29 PM, Charles R Harris <
[EMAIL PROTECTED]> wrote:
>
>
> On Fri, Apr 18, 2008 at 11:23 PM, Robert Kern <[EMAIL PROTECTED]>
> wrote:
>
> > On Sat, Apr 19, 2008 at 12:18 AM, Charles R Harris
> > <[EMAIL PROTECTED]> wrote:
> > > On Fri, Apr 18, 2008 at 11:02 PM, Robert Ker
On Fri, Apr 18, 2008 at 11:23 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> On Sat, Apr 19, 2008 at 12:18 AM, Charles R Harris
> <[EMAIL PROTECTED]> wrote:
> > On Fri, Apr 18, 2008 at 11:02 PM, Robert Kern <[EMAIL PROTECTED]>
> wrote:
> > > On Fri, Apr 18, 2008 at 11:58 PM, Charles R Harris
> > >
>
On Sat, Apr 19, 2008 at 12:18 AM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
> On Fri, Apr 18, 2008 at 11:02 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> > On Fri, Apr 18, 2008 at 11:58 PM, Charles R Harris
> >
> > <[EMAIL PROTECTED]> wrote:
> > >
> > > On Fri, Apr 18, 2008 at 10:53 PM, Robert Ker
On Fri, Apr 18, 2008 at 11:02 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 18, 2008 at 11:58 PM, Charles R Harris
> <[EMAIL PROTECTED]> wrote:
> >
> > On Fri, Apr 18, 2008 at 10:53 PM, Robert Kern <[EMAIL PROTECTED]>
> wrote:
> > >
> > > On Fri, Apr 18, 2008 at 11:47 PM, Charles R Harr
On Fri, Apr 18, 2008 at 11:58 PM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
>
> On Fri, Apr 18, 2008 at 10:53 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> >
> > On Fri, Apr 18, 2008 at 11:47 PM, Charles R Harris
> > <[EMAIL PROTECTED]> wrote:
> > > The signature for a ufunc is something like
> >
On Fri, Apr 18, 2008 at 10:53 PM, Robert Kern <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 18, 2008 at 11:47 PM, Charles R Harris
> <[EMAIL PROTECTED]> wrote:
> > The signature for a ufunc is something like
> >
> > @[EMAIL PROTECTED]@kind@(char **args, intp *dimensions, intp *steps, void
> > *func)
>
On Fri, Apr 18, 2008 at 11:47 PM, Charles R Harris
<[EMAIL PROTECTED]> wrote:
> The signature for a ufunc is something like
>
> @[EMAIL PROTECTED]@kind@(char **args, intp *dimensions, intp *steps, void
> *func)
>
> Which contains all the info necessary to do a sort. Means and other such
> function
The signature for a ufunc is something like
@[EMAIL PROTECTED]@kind@(char **args, intp *dimensions, intp *steps, void *func)
Which contains all the info necessary to do a sort. Means and other such
functions could also be implemented that way.
Chuck
__
On Fri, Apr 18, 2008 at 8:19 PM, Vincent Broman <[EMAIL PROTECTED]> wrote:
> I reported back on August 30 to this list,
> with some discussion following on September 4 and 5,
> about my attempt to build numpy on an ancient powerpc setup.
> I'm running yellow dog linux 2.1, gcc 2.95.3.20010111, o
I reported back on August 30 to this list,
with some discussion following on September 4 and 5,
about my attempt to build numpy on an ancient powerpc setup.
I'm running yellow dog linux 2.1, gcc 2.95.3.20010111, on processors from
Curtiss-Wright Controls.
Don't tell me to just upgrade; this confi
[ Sorry for the cross-post, but I know this is something that has hit
quite a few people on this list. If you have any questions on it,
please ask on the ipython list, this is just an FYI ]
Hi all,
there's a very old, *extremely* annoying bug that multiple people have
asked about (on list and in
On 18/04/2008, Robert Kern <[EMAIL PROTECTED]> wrote:
> On Fri, Apr 18, 2008 at 3:33 PM, Joe Harrington <[EMAIL PROTECTED]> wrote:
> > For that matter, is there a reason logical operations don't work on
> > arrays other than booleans? What about:
>
> The keywords "and", "or", and "not" only wor
On Fri, 18 Apr 2008, Joe Harrington apparently wrote:
> For that matter, is there a reason logical operations don't work on
> arrays other than booleans? What about:
> import numpy
> x = numpy.ones((10), dtype='Bool')
> y = numpy.ones((10), dtype='Bool')
> y[6] = False
> z = x and y # logical
On Fri, Apr 18, 2008 at 3:33 PM, Joe Harrington <[EMAIL PROTECTED]> wrote:
> For that matter, is there a reason logical operations don't work on
> arrays other than booleans? What about:
The keywords "and", "or", and "not" only work on bool objects; Python
tries to convert the operands using boo
For that matter, is there a reason logical operations don't work on
arrays other than booleans? What about:
import numpy
x = numpy.ones((10), dtype='Bool')
y = numpy.ones((10), dtype='Bool')
y[6] = False
z = x and y # logical AND: this one fails with an error about arrays
On 18/04/2008, Olivier <[EMAIL PROTECTED]> wrote:
> Let's restrict the discussion the case to boolean arrays (dtype bool),
> since all the comparisons (A==B, A!=B, A arrays).
>
> So I have an array filled with booleans. Is there a reason not to map
> "bool(A)" to "A.all()" but instead raise an
Hi,
I must say, I agree with the other posters here, that it is not
completely obvious to me that:
a = np.array([True, False])
bool(a)
should return False. Especially given:
L = [True, False]
bool(L)
returns True.
Given that it's not completely obvious, and
a.all()
is completely obvious
Let's restrict the discussion the case to boolean arrays (dtype bool),
since all the comparisons (A==B, A!=B, A wrote:
> On Fri, 18 Apr 2008, Olivier Verdier apparently wrote:
> > What is ambiguous about "bool(A==B)"?
>
> A==B is an array. Compare:
>
> >>> bool([])
> False
> >>> bool([0
On Fri, 18 Apr 2008, Olivier Verdier apparently wrote:
> What is ambiguous about "bool(A==B)"?
A==B is an array. Compare:
>>> bool([])
False
>>> bool([0])
True
Even if you decide the second should be false,
what about [0,1]? (I.e., all or any?)
Cheers,
Alan Isaac
__
On Fri, Apr 18, 2008 at 8:43 AM, Matthieu Brucher
<[EMAIL PROTECTED]> wrote:
>
>
> 2008/4/18, Olivier Verdier <[EMAIL PROTECTED]>:
> > I certainly didn't mean that "A==B" should return a boolean!!
> >
> > "A==B" should return an array of boolean as it does now. This is all
> right.
> >
> > *However
Hi Eric
On 18/04/2008, Eric Firing <[EMAIL PROTECTED]> wrote:
> The motivation for the patch is that in matplotlib color mapping, such as
[...]
Beautiful patch, good motivation. Thank you!
Applied in r5044.
Regards
Stéfan
___
Numpy-discussion maili
2008/4/18, Olivier Verdier <[EMAIL PROTECTED]>:
>
> I certainly didn't mean that "A==B" should return a boolean!!
>
> "A==B" should return an array of boolean as it does now. This is all
> right.
>
> *However* "bool(A==B)" should return a boolean, *not* raise an
> exception. Why raise an exception?
I certainly didn't mean that "A==B" should return a boolean!!
"A==B" should return an array of boolean as it does now. This is all right.
*However* "bool(A==B)" should return a boolean, *not* raise an
exception. Why raise an exception? What is ambiguous about
"bool(A==B)"??
This is what happens
On Fri, Apr 18, 2008 at 01:11:37PM +0200, Olivier Verdier wrote:
> In mathematics, if I compare two function, it means that I compare on
> all its "coordinates". If I say "f < g" I mean "f(x) < g(x) for all
> x".
>
> The same holds for a vector, if I write "v == w" I mean "v[i] == w[i]
> for all i
In mathematics, if I compare two function, it means that I compare on
all its "coordinates". If I say "f < g" I mean "f(x) < g(x) for all
x".
The same holds for a vector, if I write "v == w" I mean "v[i] == w[i]
for all i".
How come this doesn't work in numpy? And why the message about the
truth
Stefan, (or anyone else who might be interested)
Since you committed my fast putmask patch many months ago, I thought you
might like to deal with my fast take patch. Attached is the diff
relative to 5043, ignoring whitespace. (Yes, those pesky whitespace
anomalies are still cropping up.)
T
30 matches
Mail list logo
