Re: [Numpy-discussion] Conversion float64->int bugged?

[saintmlx]

I opened a new ticket for this:
http://projects.scipy.org/scipy/numpy/ticket/549

Xavier

Timothy Hochberg wrote:

>
>
> On 7/9/07, *Xavier Saint-Mleux* <[EMAIL PROTECTED] 
> > wrote:
>
> Hi all,
>
> The conversion from a numpy scalar to a python int is not consistent
> with python's native conversion (or numarray's):  if the scalar is out
> of bounds for an int, python and numarray automatically create a long
> while numpy still creates an int... with the wrong value.
>
> N.B. I am new to numpy, so please forgive me if this issue has already
> been discussed.  I've quickly searched the archives and Travis's
> "Guide
> to NumPy", with no success.
>
> e.g. (using numpy 1.0.3):
>
> Python 2.4.3 (#2, Apr 27 2006, 14:43:58)
> [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
> Type "help", "copyright", "credits" or "license" for more
> information.
> >>> from numpy import *
> >>> l= [1e3, 1e9, 1e15, -1e3, -1e9, -1e15]
> >>> a= array(l)
> >>> map(int, l)
> [1000, 10, 1000L, -1000, -10,
> -1000L]
> >>> map(int, a)
> [1000, 10, -2147483648, -1000, -10, -2147483648]
> >>> map(long, a)
> [1000L, 10L, 1000L, -1000L, -10L,
> -1000L]
> >>>
>
> IMHO, numpy's conversions to int should behave like Python's
> 'float_int'
> or 'long_int' functions (see $PYTHON_SRC_DIR/Objects/floatobject.c,
> $PYTHON_SRC_DIR/Objects/longobject.c): if it doesn't fit in an int,
> return a long.  For now (svn), it seems that numpy is always using
> PyInt_FromLong after an implicit C cast to long (which silently fails;
> see $NUMPY_SRC_DIR/numpy/core/src/scalarmathmodule.c.src)
>
> Is there any reason not to change this? 
>
>
> FWIW, it seems like a good idea to me.
>  
>
>
> -- 
> .  __
> .   |-\
> .
> .  [EMAIL PROTECTED] 
>
>
>
>___
>Numpy-discussion mailing list
>Numpy-discussion@scipy.org
>http://projects.scipy.org/mailman/listinfo/numpy-discussion
>  
>

___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] another broadcast/fancy indexing question

[Timothy Hochberg]

On 7/10/07, Mark.Miller <[EMAIL PROTECTED]> wrote:


Sorry...can you clarify?  I think that some of your message got cut off.

-Mark

Timothy Hochberg wrote:
> It's because you are using arrays as indices (aka Fancy-Indexing). When
> you do this everything works differently. In this case, everything is
> being broadcast to the same shape. As I understand it (and I try to use
> only the simplest forms of fancy indexing), what you are doing is
> equivalent to:




Sorry about that. The missing line is:

a[zeros([5,5]),:,b,c].shape

That is, your '0' is being broadcast into a 5x5 array to match the shapes of
b and c. That is why the two forms you give are not equivalent. As to why
you get that exact shape, I'd have to peruse the fancy indexing docs to
figure it out -- things are a little weird when you use multidimensional
indexing.




> --
> .  __
> .   |-\
> .
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion





--
.  __
.   |-\
.
.  [EMAIL PROTECTED]
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] another broadcast/fancy indexing question

[Mark.Miller]

Sorry...can you clarify?  I think that some of your message got cut off.

-Mark

Timothy Hochberg wrote:
> It's because you are using arrays as indices (aka Fancy-Indexing). When 
> you do this everything works differently. In this case, everything is 
> being broadcast to the same shape. As I understand it (and I try to use 
> only the simplest forms of fancy indexing), what you are doing is 
> equivalent to:
> 
> -- 
> .  __
> .   |-\
> .
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] How do I tell f2py to generate Numeric modules?

[Ben ZX]

I ran f2py. It seems to always generate NumPy modules.

How do I tell f2py to generate Numeric modules?

Ben
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Problems building SVN on Windows

[numpy-discussion]

Hi,

I am trying to build numpy on Windows from the current SVN (rev. 3884 I
think) and I'm having some problems.

I've successfully built ATLAS and LAPACK. I've installed Python 2.5.1
from the standard windows installer. I also have a fresh install of
Cygwin with all mingw development tools etc. I created a site.cfg file
from the template with the following entries:
---
[blas_opt]
libraries = f77blas, cblas, atlas
library_dirs = C:\cygwin\home\mqbxfri2\ATLAS\atlas_win32\lib
include_dirs = C:\cygwin\home\mqbxfri2\ATLAS\atlas_win32\include
#
[lapack_opt]
libraries = lapack, f77blas, cblas, atlas
library_dirs = C:\cygwin\home\mqbxfri2\ATLAS\atlas_win32\lib
include_dirs = C:\cygwin\home\mqbxfri2\ATLAS\atlas_win32\include
[fftw]
libraries = fftw3
library_dirs = "C:\fftw"
---

So the first problem is this file doesn't seem to be recognised (and
these library paths aren't picked up). I've tried from the cygwin shell
and windows cmd and with the file next to setup.py and also in
numpy/distutils. However the only paths searched are
C:\,C:\Python25\Libs,C:\Python25\lib.
I got around this by copying the .a files to C:\. This is a bit messy
but at least it finds ATLAS and LAPACK.

Then when I try to run config/build as described on the wiki I get an
error about no valid fortran compiler being defined. The full output of
python setup.py -v build --compiler=mingw32 is attached.

I would be greatful if anyone could help me to get this working. Also if
someone could provide more details on how to ensure fftw is used. The
precompiled fftw library I downloaded provides libfftw3-3.dll as well as
couple of others. Will this be picked up correctly by my fftw entry in
site.cfg (if site.cfg was working) or should it be "libraries=fftw3-3"?
Is it OK to use this DLL or do I have to build a static library myself
from source.

Finally, I gather the very nice scipy website/wiki is relatively new...
I was wondering if you had considered a phpbb type forum for support
issues such as this. I think this can be a lot more accessible for new
users (such as myself)...

Thanks in advance,

Robin


build-v.out
Description: Binary data
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] another broadcast/fancy indexing question

[Timothy Hochberg]

On 7/10/07, Mark.Miller <[EMAIL PROTECTED]> wrote:


Just ran across something that doesn't quite make sense to me at the
moment.

Here's some code:

>>> numpy.__version__
'1.0.2'
>>>
>>> def f1(b,c):
b=b.astype(int)
c=c.astype(int)
return b,c

>>> b,c = numpy.fromfunction(f1,(5,5))
>>> a=numpy.zeros((2,12,5,5),int)
>>> a1=a[0]
>>> a1[:,b,c].shape
(12, 5, 5)
>>> a[0,:,b,c].shape
(5, 5, 12)   ###why does this not return (12,5,5)?
>>>

So in a nutshell, it's not completely clear to me why these are
returning arrays of different shapes.  Can someone shed some light?



It's because you are using arrays as indices (aka Fancy-Indexing). When you
do this everything works differently. In this case, everything is being
broadcast to the same shape. As I understand it (and I try to use only the
simplest forms of fancy indexing), what you are doing is equivalent to:

--
.  __
.   |-\
.
.  [EMAIL PROTECTED]
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] another broadcast/fancy indexing question

[Mark.Miller]

Just ran across something that doesn't quite make sense to me at the moment.

Here's some code:

 >>> numpy.__version__
'1.0.2'
 >>>
 >>> def f1(b,c):
b=b.astype(int)
c=c.astype(int)
return b,c

 >>> b,c = numpy.fromfunction(f1,(5,5))
 >>> a=numpy.zeros((2,12,5,5),int)
 >>> a1=a[0]
 >>> a1[:,b,c].shape
(12, 5, 5)
 >>> a[0,:,b,c].shape
(5, 5, 12)   ###why does this not return (12,5,5)?
 >>>

So in a nutshell, it's not completely clear to me why these are 
returning arrays of different shapes.  Can someone shed some light?

Thanks,

-Mark
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Should bool_ subclass int?

[Alan Isaac]

On Tue, 10 Jul 2007, Timothy Hochberg wrote: 
> 1. 
> +,- are arithmetic operators and return ints not booleans 
> 2. 
> *,** are arithmetic operators on scalars and arrays and return ints as above. 
> 3. 
> &,|,^ are the logical operators and return booleans. 
> 4. 
> *,** are defined on matrices to perform logical matrix multiplication and 
> exponation. 

I am not objecting to this, but I want to make sure the 
costs are not overlooked.

Will multiplication of boolean matrices will be different 
than `dot`? (It will certainly be different than `dot` for 
"equivalent" 2-d arrays).

If I understand, unary complementation (using `-`) will be lost:
so there will be no operator for unary complementation.
(You might say, what about `~`, which currently works, but 
if we are to match Python's behavior, that is lost too.)

Cheers,
Alan Isaac




___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Conversion float64->int bugged?

[Timothy Hochberg]

On 7/9/07, Xavier Saint-Mleux <[EMAIL PROTECTED]> wrote:


Hi all,

The conversion from a numpy scalar to a python int is not consistent
with python's native conversion (or numarray's):  if the scalar is out
of bounds for an int, python and numarray automatically create a long
while numpy still creates an int... with the wrong value.

N.B. I am new to numpy, so please forgive me if this issue has already
been discussed.  I've quickly searched the archives and Travis's "Guide
to NumPy", with no success.

e.g. (using numpy 1.0.3):

Python 2.4.3 (#2, Apr 27 2006, 14:43:58)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from numpy import *
>>> l= [1e3, 1e9, 1e15, -1e3, -1e9, -1e15]
>>> a= array(l)
>>> map(int, l)
[1000, 10, 1000L, -1000, -10,
-1000L]
>>> map(int, a)
[1000, 10, -2147483648, -1000, -10, -2147483648]
>>> map(long, a)
[1000L, 10L, 1000L, -1000L, -10L,
-1000L]
>>>

IMHO, numpy's conversions to int should behave like Python's 'float_int'
or 'long_int' functions (see $PYTHON_SRC_DIR/Objects/floatobject.c,
$PYTHON_SRC_DIR/Objects/longobject.c): if it doesn't fit in an int,
return a long.  For now (svn), it seems that numpy is always using
PyInt_FromLong after an implicit C cast to long (which silently fails;
see $NUMPY_SRC_DIR/numpy/core/src/scalarmathmodule.c.src)

Is there any reason not to change this?



FWIW, it seems like a good idea to me.



--
.  __
.   |-\
.
.  [EMAIL PROTECTED]
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Should bool_ subclass int?

[Charles R Harris]

On 7/10/07, Timothy Hochberg <[EMAIL PROTECTED]> wrote:



[CHOP: lots of examples]

It looks like bool_s could use some general rejiggering. Let me put forth
a concrete proposal that's based on matching bool_ behaviour to that of
Python's bools. There is another route that could be taken where bool_ and
bool are completely decoupled, but I'll skip over that for now since I don't
really think it's a good idea.

   1. +,- are arithmetic operators and return ints not booleans
   2. *,** are arithmetic operators on scalars and arrays and return
   ints as above.
   3. &,|,^ are the logical operators and return booleans.
   4. *,** are defined on matrices to perform logical matrix
   multiplication and exponation.

This seems like the simplest route towards something that is both
internally self consistent and consistent with Python.



Looks good to me. At least it would make things consistent with bool_ being
a subclass of integers if we go that way.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Should bool_ subclass int?

[Timothy Hochberg]

[CHOP: lots of examples]

It looks like bool_s could use some general rejiggering. Let me put forth a
concrete proposal that's based on matching bool_ behaviour to that of
Python's bools. There is another route that could be taken where bool_ and
bool are completely decoupled, but I'll skip over that for now since I don't
really think it's a good idea.

  1. +,- are arithmetic operators and return ints not booleans
  2. *,** are arithmetic operators on scalars and arrays and return ints
  as above.
  3. &,|,^ are the logical operators and return booleans.
  4. *,** are defined on matrices to perform logical matrix
  multiplication and exponation.

This seems like the simplest route towards something that is both internally
self consistent and consistent with Python.



--
.  __
.   |-\
.
.  [EMAIL PROTECTED]
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Should bool_ subclass int?

[Gael Varoquaux]

On Tue, Jul 10, 2007 at 11:31:35AM -0400, Alan G Isaac wrote:
> Do you agree that the first (!!!) answer is a bug?
> (The basis is apparently performed as follows:
> integer array subtraction is first performed, and
> then nonzero ints are converted to True.  But this
> gives the wrong answer and most critically breaks
> the equivalence of a-b and a+(-b).)

OK, putting aside the useless maths, I agree that specifically having

a-b != a+(-b)

If numpy developpers agree, I think the proper solution is :

"""
def __sub__(self, b):
return self.__add__(-b)
"""

I think to should allow to have more or less consistent operations.

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Should bool_ subclass int?

[Alan G Isaac]

Hi Gael,

More important is the following.


On Tue, 10 Jul 2007, Alan G Isaac apparently wrote: 
 N.array([False])-N.array([True]) 
> array([True], dtype=bool) 
 N.array([False])+(-N.array([True])) 
> array([False], dtype=bool) 

> The second answer is the right one, in this context.  
> I would call this [first!!!] answer a bug. 


Do you agree that the first (!!!) answer is a bug?
(The basis is apparently performed as follows:
integer array subtraction is first performed, and
then nonzero ints are converted to True.  But this
gives the wrong answer and most critically breaks
the equivalence of a-b and a+(-b).)

Cheers,
Alan


___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Should bool_ subclass int?

[Gael Varoquaux]

On Tue, Jul 10, 2007 at 10:36:55AM -0400, Alan G Isaac wrote:
> I found Gael's presentation rather puzzling for two reasons.

> 1. It appears to contain a `+` vs. `*` confusion.
> See http://en.wikipedia.org/wiki/Two-element_Boolean_algebra

Damn it. I used math conventions, for "+" and "*" (in math the "+" law of
a ring is the law for which every element has an inverse). I hadn't
realized it was the opposite for intuitive understanding of booleans.

> 2. MUCH more importantly:
> In implementations of TWO, we interpret `-` as unary 
> complementation (not e.g. as additive inverse; note True 
> does not have one).

Yes, indeed, as the law for which every element has an inverse is "*",
the inverse for the "+" is not defined, and therefore the "-" sign cannot
design it. You are quite right that it is impossible to define "-" on the
boolean set in a way that makes it follow tradition integer operations.

I don't know what the conclusion of this should be in terms of the
original discussion.

Sorry for the noise.

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Should bool_ subclass int?

[Alan G Isaac]

On Mon, 9 Jul 2007, Timothy Hochberg apparently wrote: 
> x*y and x**2 are already decoupled for arrays and matrices. What if x*y was 
> simply defined to do a boolean matrix multiply when the arguments are 
> boolean matrices? 
> I don't care about this that much though, so I'll let it drop. 


So if x and y are arrays and you use `dot` you would get
a different result than turning them into matrices and
using `*`?  I'd find that pretty odd.

I'd also find it odd that equivalent element-by-element 
operations (`+`, `-`) would then return different outcomes 
for boolean arrays and boolean matrices.  (This is what 
I meant by "decoupled".)

This is just a user's perspective.
I do not pretend to see into the design issues.
However, daring to tread where I should not, I
offer two observations:
- matrices and 2-d arrays with dtype 'bool' should
give the same result for "comparable" operations
(where `dot` for arrays compares with `*` for matrices).
- it would be possible to have a new class, say `boolmat`,
that implements the expected behavior for boolen matrices
and then make matrices and arrays of dtype 'bool' behave
in the Python way (e.g., True+True is 2, yuck!).  I am 
definitely NOT advocating this (I like the current arrangement),
but it is a possibility.

Cheers,
Alan Isaac

PS Here is Guido's justification for bool inheriting from 
int (http://www.python.org/dev/peps/pep-0285/).  It seems 
that numpy's current behavior is closer to his "ideal world".

6) Should bool inherit from int?

=> Yes.

   In an ideal world, bool might be better implemented as a
   separate integer type that knows how to perform mixed-mode
   arithmetic.  However, inheriting bool from int eases the
   implementation enormously (in part since all C code that calls
   PyInt_Check() will continue to work -- this returns true for
   subclasses of int).  Also, I believe this is right in terms of
   substitutability: code that requires an int can be fed a bool
   and it will behave the same as 0 or 1.  Code that requires a
   bool may not work when it is given an int; for example, 3 & 4
   is 0, but both 3 and 4 are true when considered as truth
   values.



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Should bool_ subclass int?

[Alan G Isaac]

I found Gael's presentation rather puzzling for two reasons.

1. It appears to contain a `+` vs. `*` confusion.
See http://en.wikipedia.org/wiki/Two-element_Boolean_algebra

2. MUCH more importantly:
In implementations of TWO, we interpret `-` as unary 
complementation (not e.g. as additive inverse; note True 
does not have one).  So

-True is False
-False is True

This matches numpy:
>>> -N.array([False])
array([True], dtype=bool)
>>> -N.array([True])
array([False], dtype=bool) 

This is a GOOD THING.
However, a-b should then just be shorthand for a+(-b).
Here numpy does not in my opinion behave correctly:

>>> N.array([False])-N.array([True])
array([True], dtype=bool)
>>> N.array([False])+(-N.array([True]))
array([False], dtype=bool)

The second answer is the right one, in this context.
I would call this second answer a bug.

Cheers,
Alan Isaac



___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Should bool_ subclass int?

[Charles R Harris]

On 7/10/07, Gael Varoquaux <[EMAIL PROTECTED]> wrote:


On Tue, Jul 10, 2007 at 02:39:28PM +0200, Sebastian Haase wrote:
> When you talk about algebra - one might have to restrict one self to '|'
and '&'
> -- not use '+'  and '-'
> E.g.:
> True - True = False   # right !?
> # but if:
> True+True = True.
> # then
> True+True   -False  = True -False   # 
> # here I'm already lost ... I don't think this can be done in a
consistent way.

It can, its called the Bool algebra, and it is a consistent algebra, in a
mathematical sense of algebra
(http://en.wikipedia.org/wiki/Boolean_algebra), actually what we are
talking about is the two element bool algebra
(http://en.wikipedia.org/wiki/Two-element_Boolean_algebra), and the
mathematical structure we are taling about is a ring, the wikipedia
article is quite comprehensible
(http://en.wikipedia.org/wiki/Ring_(mathematics))

> In other words:  a "+" operator  would also need a corresponding "-"

Yes. In other words (the ensemble theory words) each element needs to
have an opposite concerning the '+' law. To understand this you need a
bit of algebra theory.

* An algebra has 2 laws, lets call them "+" and "*".

* Each law has a neutral element for this law, ie an element a for which
  "a + b = b" for all b in the algebra, lets write these "n+", and "n*".

* Each element a is required to have an inverse for the "+", ie an element
  b for wich b + a = n+, lets write the opposite of b "-b".

For integer, n+ = 0, n* = 1.

For Booleans, n+ = False, and n+ = True, therefore, as Matthieu points
out,
-True = True, as True + True = n+ = True,
and -False = True, as True + False = n+ = True.

So you have a consistent algebra.

Now there is a law for which every element does not have an inverse, it
the "*" law. You can check the out for integers. It is also true for
booleans. In fact, you can proove that in an ring, n+ cannot have an
inverse for the * law (it the famous divide by zero error !).

In conclusion, I would like to stress that, yes, +, - and * are well
defined on booleans, the definition is universal, and please don't try to
change it.



The proper additive operation to make boolean algebra a ring is 'xor', so
that 1 becomes its own inverse. Same thing in sigma rings, where folks used
to use exclusive union just to make the algebra to work. But plain 'or' and
'union' work fine and are more intuitive even if they don't give the ring
structure.

Chuck
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Should bool_ subclass int?

[Gael Varoquaux]

On Tue, Jul 10, 2007 at 02:39:28PM +0200, Sebastian Haase wrote:
> When you talk about algebra - one might have to restrict one self to '|' and 
> '&'
> -- not use '+'  and '-'
> E.g.:
> True - True = False   # right !?
> # but if:
> True+True = True.
> # then
> True+True   -False  = True -False   # 
> # here I'm already lost ... I don't think this can be done in a consistent 
> way.

It can, its called the Bool algebra, and it is a consistent algebra, in a
mathematical sense of algebra
(http://en.wikipedia.org/wiki/Boolean_algebra), actually what we are
talking about is the two element bool algebra
(http://en.wikipedia.org/wiki/Two-element_Boolean_algebra), and the
mathematical structure we are taling about is a ring, the wikipedia
article is quite comprehensible
(http://en.wikipedia.org/wiki/Ring_(mathematics))

> In other words:  a "+" operator  would also need a corresponding "-"

Yes. In other words (the ensemble theory words) each element needs to
have an opposite concerning the '+' law. To understand this you need a
bit of algebra theory. 

* An algebra has 2 laws, lets call them "+" and "*".

* Each law has a neutral element for this law, ie an element a for which 
  "a + b = b" for all b in the algebra, lets write these "n+", and "n*". 

* Each element a is required to have an inverse for the "+", ie an element
  b for wich b + a = n+, lets write the opposite of b "-b".

For integer, n+ = 0, n* = 1.

For Booleans, n+ = False, and n+ = True, therefore, as Matthieu points out, 
-True = True, as True + True = n+ = True,
and -False = True, as True + False = n+ = True.

So you have a consistent algebra.

Now there is a law for which every element does not have an inverse, it
the "*" law. You can check the out for integers. It is also true for
booleans. In fact, you can proove that in an ring, n+ cannot have an
inverse for the * law (it the famous divide by zero error !).

In conclusion, I would like to stress that, yes, +, - and * are well
defined on booleans, the definition is universal, and please don't try to
change it.

Gaël
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Should bool_ subclass int?

[Matthieu Brucher]

When you talk about algebra - one might have to restrict one self to '|'
and '&'
-- not use '+'  and '-'
E.g.:
True - True = False   # right !?




Not exactly because - True = + True
So True - True = True + True = True
You have to stay in the algebra the whole time.

# but if:

True+True = True.
# then
True+True   -False  = True -False   # 
# here I'm already lost ... I don't think this can be done in a consistent
way.

In other words:  a "+" operator  would also need a corresponding "-"
operator, and that will just look funny.  I think if you want algebra,
you should restrict yourself to "|" (or) and "&" (and)



When you make computation in the Bool algebra, you use + and * in every math
book. In IT books, you see | and &. As Numpy is scientists oriented, I
suppose that the definition of + and * is correct.

Matthieu
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Should bool_ subclass int?

[Sebastian Haase]

On 7/10/07, Matthieu Brucher <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> >
> >
> > > On Mon, 9 Jul 2007, Timothy Hochberg apparently wrote:
> > > > Why not simply use & and | instead of + and *?
> > >
> > > A couple reasons, none determinative.
> > > 1. numpy is right a Python is wrong it this case
> >
> >
> > I don't think I agree with this. Once you've decided to make Boolean a
> subclass of Int, then Python's behavior seems to be the most sensible. One
> could argue (and people did) about whether that was a good choice, but it's
> useful for a lot of practical applications. In any event, given that Boolean
> subclasses Int, I think the current behavior is probably for the best.
>
>
> If bool subclasses int, this does not enforce True+True=2. Never. Boolean
> operation live in the Boole algebra and that's it. It's not the case with
> integers that cannot be represented with int.
> Now, if you take the algebra point of view, which is the point here, for a
> scientific application, you have to have True+True = True.
>  Matthieu

When you talk about algebra - one might have to restrict one self to '|' and '&'
-- not use '+'  and '-'
E.g.:
True - True = False   # right !?
# but if:
True+True = True.
# then
True+True   -False  = True -False   # 
# here I'm already lost ... I don't think this can be done in a consistent way.

In other words:  a "+" operator  would also need a corresponding "-"
operator, and that will just look funny.  I think if you want algebra,
you should restrict yourself to "|" (or) and "&" (and)

My two cents,
Sebastian
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion