[Numpy-discussion] Compiling numpy with 64 bits support under Solaris

[Langella Raphael]

Hi,
I'm trying to compile numpy with 64 bits support under 
Sparc/Solaris 8. I've already compiled Python 2.5.1 with 64 
bits. I've set up my environnement with :

export CC="gcc -mcpu=v9 -m64 -D_LARGEFILE64_SOURCE=1"
export CXX="g++ -mcpu=v9 -m64 -D_LARGEFILE64_SOURCE=1"
export LDFLAGS='-mcpu=v9 -m64'
export LDDFLAGS='-mcpu=v9 -m64 -G'

I also compiled blas and lapack in 64 bits. I know I don't 
need them for numpy, but I will soon when I'll compile scipy. 
I've tried to set up my site.cfg, tu use libfblas and 
libflapack and it didn't work. I tried libsunperf and got the 
same result :

/outils_std/csw/gcc3/bin/g77 -mcpu=v9 -m64 
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
 -L/outils_std/SUNS11/SUNWspro/lib/v9 
-L/outils_std/csw/gcc3/bin/../lib/gcc/sparc-sun-solaris2.8/3.4
.4 -lsunperf -lg2c -o 
build/lib.solaris-2.8-sun4u-2.5/numpy/core/_dotblas.so
Undefined   first referenced
 symbol in file
PyExc_ImportError   
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
PyCObject_AsVoidPtr 
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
PyArg_ParseTuple
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
PyExc_RuntimeError  
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
PyEval_SaveThread   
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
PyObject_GetAttrString  
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
PyExc_ValueError
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
MAIN__  
/outils_std/csw/gcc3/bin/../lib/gcc/sparc-sun-solaris2.8/3.4.4
/../../../sparcv9/libfrtbegin.a(frtbegin.o)
PyErr_SetString 
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
PyErr_Format
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
PyCObject_Type  
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
PyTuple_New 
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
PyErr_Print 
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
PyImport_ImportModule   
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
_Py_NoneStruct  
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
Py_InitModule4_64   
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
PyEval_RestoreThread
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
ld: fatal: Symbol referencing errors. No output written to 
build/lib.solaris-2.8-sun4u-2.5/numpy/core/_dotblas.so
collect2: ld returned 1 exit status
Undefined   first referenced
 symbol in file
PyExc_ImportError   
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
PyCObject_AsVoidPtr 
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
PyArg_ParseTuple
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
PyExc_RuntimeError  
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
PyEval_SaveThread   
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
PyObject_GetAttrString  
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
PyExc_ValueError
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
MAIN__  
/outils_std/csw/gcc3/bin/../lib/gcc/sparc-sun-solaris2.8/3.4.4
/../../../sparcv9/libfrtbegin.a(frtbegin.o)
PyErr_SetString 
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
PyErr_Format
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
PyCObject_Type  
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
PyTuple_New 
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
PyErr_Print 
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
PyImport_ImportModule   
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
_Py_NoneStruct  
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
Py_InitModule4_64   
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
PyEval_RestoreThread
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
ld: fatal: Symbol referencing errors. No output written to 
build/lib.solaris-2.8-sun4u-2.5/numpy/core/_dotblas.so
collect2: ld returned 1 exit status
error: Command "/outils_std/csw/gcc3/bin/g77 -mcpu=v9 -m64 
build/temp.solaris-2.8-sun4u-2.5/numpy/core/blasdot/_dotblas.o
 -L/outils_std/SU

Re: [Numpy-discussion] Compiling numpy with 64 bits support under Solaris

[David Cournapeau]

Langella Raphael wrote:
> Hi,
> I'm trying to compile numpy with 64 bits support under 
> Sparc/Solaris 8. I've already compiled Python 2.5.1 with 64 
> bits. I've set up my environnement with :
>
> export CC="gcc -mcpu=v9 -m64 -D_LARGEFILE64_SOURCE=1"
> export CXX="g++ -mcpu=v9 -m64 -D_LARGEFILE64_SOURCE=1"
> export LDFLAGS='-mcpu=v9 -m64'
> export LDDFLAGS='-mcpu=v9 -m64 -G'
>
>   
I am afraid this won't work really well, because it overwrites LDFLAGS. 
Unfortunately, AFAIK, there is no easy way to change flags used for 
compilation and linking. I don't think this is linked to 32 vs 64 bits 
problem (though I may be wrong; I don't know much about solaris).
> I also compiled blas and lapack in 64 bits. I know I don't 
> need them for numpy, but I will soon when I'll compile scipy. 
> I've tried to set up my site.cfg, tu use libfblas and 
> libflapack and it didn't work. I tried libsunperf and got the 
> same result :
>   
See 
http://projects.scipy.org/pipermail/scipy-user/2007-September/013580.html 
(the problem being about the sun compilers, I think this applies to 
sparc as well).

cheers,

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

[Numpy-discussion] arange and floating point arguments

[Ed Schofield]

Hi everyone,

This was reported yesterday as a bug in Debian's numpy package:

>>> len(numpy.arange(0, 0.6, 0.1)) == len(numpy.arange(0, 0.4+0.2, 0.1))
False

The cause is this:

>>> ceil((0.4+0.2)/0.1)
7.0

>>> ceil(0.6/0.1)
6.0

which holds for both numpy's and the standard library's ceil().

Using arange in this way is a fundamentally unreliable thing to do,
but is there anything we want to do about this? Should numpy emit a
warning when using arange with floating point values when
(stop-start)/step is close to an integer?

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

Re: [Numpy-discussion] arange and floating point arguments

[lorenzo bolla]

this is really annoying.
Matlab handles the "ceil" weirdness quite well, though.

--

>> ceil(0.6/0.1)

ans =

 6

>> ceil((0.4+0.2)/0.1)

ans =

 7

>> 0:0.1:0.6

ans =

 01.000e-001
2.000e-0013.000e-0014.000e-001
5.000e-0016.000e-001

>> 0:0.1:(0.4+0.2)

ans =

 01.000e-001
2.000e-0013.000e-0014.001e-001
5.001e-0016.001e-001


>> length(0:0.1:0.6) == length(0:0.1:(0.4+0.2))

ans =

 1

--

hth,

L.



On 9/14/07, Ed Schofield <[EMAIL PROTECTED]> wrote:
>
> Hi everyone,
>
> This was reported yesterday as a bug in Debian's numpy package:
>
> >>> len(numpy.arange(0, 0.6, 0.1)) == len(numpy.arange(0, 0.4+0.2, 0.1))
> False
>
> The cause is this:
>
> >>> ceil((0.4+0.2)/0.1)
> 7.0
>
> >>> ceil(0.6/0.1)
> 6.0
>
> which holds for both numpy's and the standard library's ceil().
>
> Using arange in this way is a fundamentally unreliable thing to do,
> but is there anything we want to do about this? Should numpy emit a
> warning when using arange with floating point values when
> (stop-start)/step is close to an integer?
>
> -- Ed
> ___
> 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] arange and floating point arguments

[Joris De Ridder]

Might using

min(ceil((stop-start)/step), ceil((stop-start)/step-r))

with r = finfo(double).resolution instead of ceil((stop-start)/step)  
perhaps be useful?

Joris



On 14 Sep 2007, at 11:37, Ed Schofield wrote:

> Hi everyone,
>
> This was reported yesterday as a bug in Debian's numpy package:
>
 len(numpy.arange(0, 0.6, 0.1)) == len(numpy.arange(0, 0.4+0.2,  
 0.1))
> False
>
> The cause is this:
>
 ceil((0.4+0.2)/0.1)
> 7.0
>
 ceil(0.6/0.1)
> 6.0
>
> which holds for both numpy's and the standard library's ceil().
>
> Using arange in this way is a fundamentally unreliable thing to do,
> but is there anything we want to do about this? Should numpy emit a
> warning when using arange with floating point values when
> (stop-start)/step is close to an integer?
>
> -- Ed


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

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

[Numpy-discussion] Requesting svn write access to numpy ?

[David Cournapeau]

Hi,

I would like to know whether I could request svn write access to 
numpy svn. There are several things I would like to work on which are 
big enough so that just patch would be difficult, and branches more 
appropriate, and my understanding is that svn branches requires write 
access. The things I would like to work on are:
- in the immediate futur: support for sunperf, and solaris compilers
- some work on numpy FFT (using KISS FFT, which is a BSD, really 
small library for FFT, see my other email)
- some work on distutils for ctypes support (eg being able to build 
extension to be used with ctypes).

Thank you,

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

Re: [Numpy-discussion] arange and floating point arguments

[Lou Pecora]

I thought this is what the linspace function was
written for in numpy.  Why not use that?  It works
just like you would want always including the final
point.


--- Joris De Ridder <[EMAIL PROTECTED]>
wrote:

> Might using
> 
> min(ceil((stop-start)/step),
> ceil((stop-start)/step-r))
> 
> with r = finfo(double).resolution instead of
> ceil((stop-start)/step)  
> perhaps be useful?
> 
> Joris



-- Lou Pecora,   my views are my own.


  

Catch up on fall's hot new shows on Yahoo! TV. Watch previews, get listings, 
and more!
http://tv.yahoo.com/collections/3658 
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] arange and floating point arguments

[Joris De Ridder]

On 14 Sep 2007, at 15:54, Lou Pecora wrote:

> I thought this is what the linspace function was
> written for in numpy.  Why not use that?

AFAIK, linspace() is written to generate N evenly spaced numbers  
between start and stop inclusive. Similar but not quite the same as  
arange().


> It works just like you would want always including the final point.

The example I gave was actually meant to _avoid_ inclusion of the  
last point. E.g.

In [93]: arange(0.0, 0.4+0.2, 0.1)
Out[93]: array([ 0. ,  0.1,  0.2,  0.3,  0.4,  0.5,  0.6])

In [94]: myrange(0.0, 0.4+0.2, 0.1)
Out[94]: array([ 0. ,  0.1,  0.2,  0.3,  0.4,  0.5])

where myrange() is an ad hoc replacement for arange():

def myrange(start, stop, step):
 r = finfo(double).resolution
 N = min(ceil((stop-start)/step), ceil((stop-start)/step-r))
 return start + arange(N) * step

I'm not 100% sure that the above version of myrange() wouldn't  
generate surprising results in some cases. If it doesn't, why not  
include it in (the C-version of) arange()? I don't think users  
actually count on the inclusion of the end point in some cases, so it  
would not break code. It would, however, avoid some surprises from  
time to time.

 From the example of Lorenzo, it seems that Matlab is always  
including the endpoint. How exactly is their arange version defined?

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

Re: [Numpy-discussion] Requesting svn write access to numpy ?

[Travis E. Oliphant]

David Cournapeau wrote:
> Hi,
>
> I would like to know whether I could request svn write access to 
> numpy svn. There are several things I would like to work on which are 
> big enough so that just patch would be difficult, and branches more 
> appropriate, and my understanding is that svn branches requires write 
> access. The things I would like to work on are:
> - in the immediate futur: support for sunperf, and solaris compilers
> - some work on numpy FFT (using KISS FFT, which is a BSD, really 
> small library for FFT, see my other email)
> - some work on distutils for ctypes support (eg being able to build 
> extension to be used with ctypes).
>
>   

Yes, I'll try and set you up.  What username would you like?

-Travis


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

Re: [Numpy-discussion] arange and floating point arguments

[Robert Kern]

Ed Schofield wrote:
> Hi everyone,
> 
> This was reported yesterday as a bug in Debian's numpy package:
> 
 len(numpy.arange(0, 0.6, 0.1)) == len(numpy.arange(0, 0.4+0.2, 0.1))
> False
> 
> The cause is this:
> 
 ceil((0.4+0.2)/0.1)
> 7.0
> 
 ceil(0.6/0.1)
> 6.0
> 
> which holds for both numpy's and the standard library's ceil().

>>> 0.6 == (0.4+0.2)
False

Consequently, not a bug.

> Using arange in this way is a fundamentally unreliable thing to do,
> but is there anything we want to do about this?

Tell people to use linspace(). Yes, it does a slightly different thing; that's
why it works. Most uses of floating point arange() can be cast using linspace()
more reliably.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] arange and floating point arguments

[Anne Archibald]

On 14/09/2007, Robert Kern <[EMAIL PROTECTED]> wrote:
> Ed Schofield wrote:
> > Using arange in this way is a fundamentally unreliable thing to do,
> > but is there anything we want to do about this?
>
> Tell people to use linspace(). Yes, it does a slightly different thing; that's
> why it works. Most uses of floating point arange() can be cast using 
> linspace()
> more reliably.

I would like to point out in particular that numpy's linspace can
leave out the last point (something I often want to do):

Definition: linspace(start, stop, num=50, endpoint=True, retstep=False)
Docstring:
Return evenly spaced numbers.

Return num evenly spaced samples from start to stop.  If
endpoint is True, the last sample is stop. If retstep is
True then return the step value used.

This is one of those cases where "from pylab import *" is going to
bite you, though, because its linspace doesn't. You can always fake it
with linspace(a,b,N+1)[:-1].

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

Re: [Numpy-discussion] Requesting svn write access to numpy ?

[Jarrod Millman]

Hey Travis (and David),

Since you (Travis) approved, I went ahead and gave David (cdavid) svn
commit access to numpy.  If you (David) have any difficulties, feel
free to email me directly and I will take care of it.

Cheers,

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] arange and floating point arguments

[Charles R Harris]

On 9/14/07, Ed Schofield <[EMAIL PROTECTED]> wrote:
>
> Hi everyone,
>
> This was reported yesterday as a bug in Debian's numpy package:
>
> >>> len(numpy.arange(0, 0.6, 0.1)) == len(numpy.arange(0, 0.4+0.2, 0.1))
> False
>
> The cause is this:
>
> >>> ceil((0.4+0.2)/0.1)
> 7.0
>
> >>> ceil(0.6/0.1)
> 6.0
>
> which holds for both numpy's and the standard library's ceil().


Since none of the numbers are  exactly represented in IEEE floating point,
this sort of oddity is expected.  If you look at the exact values, (.4 +
.2)/.1 > 6 and .6/.1 < 6 . That said, I would expect something like
ceil(interval/delta - relatively_really_small_number) would generally return
the expected result. Matlab probably plays these sort of games. The downside
is encouraging bad programming habits. In this case, the programmer should
be using linspace..

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

Re: [Numpy-discussion] arange and floating point arguments

[Anne Archibald]

On 14/09/2007, Charles R Harris <[EMAIL PROTECTED]> wrote:

> Since none of the numbers are  exactly represented in IEEE floating point,
> this sort of oddity is expected.  If you look at the exact values, (.4 +
> .2)/.1 > 6 and .6/.1 < 6 . That said, I would expect something like
> ceil(interval/delta - relatively_really_small_number) would generally return
> the expected result. Matlab probably plays these sort of games. The downside
> is encouraging bad programming habits. In this case, the programmer should
> be using linspace..

There is actually a context in which floating-point arange makes
sense: when you want evenly-spaced points and don't much care how many
there are. No reason to play games in this context of course; the
question is how to reduce user astonishment.

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

Re: [Numpy-discussion] arange and floating point arguments

[Sebastian Haase]

On 9/14/07, Charles R Harris <[EMAIL PROTECTED]> wrote:
>
> Since none of the numbers are  exactly represented in IEEE floating point,
> this sort of oddity is expected.  If you look at the exact values, (.4 +
> .2)/.1 > 6 and .6/.1 < 6 .

Just for my own benefit (and the past time) here are the actual
numbers I get in my PyShell:
>>> 0.6 == (0.4+0.2)
False
>>> `.6`
'0.59998'
>>> `.4`
'0.40002'
>>> `.2`
'0.20001'
>>> `.2+.4`
'0.60009'

To my naive eye this is just "fantastic" ... ;-)

-Sebastian Haase

PS:you might even notice that "1+2 = 9" ;-)
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] arange and floating point arguments

[Eike Welk]

On Friday 14 September 2007 20:12, Charles R Harris wrote:

> Since none of the numbers are  exactly represented in IEEE floating
> point, this sort of oddity is expected.  If you look at the exact
> values, (.4 + .2)/.1 > 6 and .6/.1 < 6 . That said, I would expect

You hit send too fast! The fractions that can be represented exactly 
in binary are: 1/2, 1/4, 1/8, ... and not 2/10, 4/10, 8/10  

See here:

In [1]:0.5 == .25+.25
Out[1]:True

In [2]:.5
Out[2]:0.5

In [3]:.25
Out[3]:0.25

In [4]:.125
Out[4]:0.125

In [8]:.375 == .25 + .125
Out[8]:True


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

[Numpy-discussion] binomial, multinomial coefficients

[Charles R Harris]

Does anyone know if there are routines in scipy to compute these numbers? If
not, I could code some up if there is any interest. As a related question,
are there routines for returning the probabilities (as opposed to random
number generators) for the various distributions?

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

Re: [Numpy-discussion] binomial, multinomial coefficients

[Robert Kern]

Charles R Harris wrote:
> Does anyone know if there are routines in scipy to compute these
> numbers?

scipy.misc.comb() will handle the binomial coefficients. A ufunc or an
implementation that would broadcast would be welcome, though. I don't think we
have one for multinomial coefficients.

> If not, I could code some up if there is any interest. As a
> related question, are there routines for returning the probabilities (as
> opposed to random number generators) for the various distributions?

scipy.stats should have all of the 1D pdfs though not the multinomial.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] arange and floating point arguments

[Joris De Ridder]

> the question is how to reduce user astonishment.

IMHO this is exactly the point. There seems to be two questions here:  
1) do we want to reduce user astonishment, and 2) if yes, how could  
we do this? Not everyone seems to be convinced of the first question,  
replying that in many cases linspace() could well replace arange().  
In many cases, yes, but not all. For some cases arange() has its  
legitimate use, even for floating point, and in these cases you may  
get bitten by the inexact number representation. If Matlab seems to  
be able to avoid surprises, why not numpy?

Joris



Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

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

[Numpy-discussion] NotImplementedType

[Tom Denniston]

Sometimes numpy operationrs result in NotImplementedType.  It makes it
a little hard to debug because the problem then crops up later when
you try to do an operation with the NotImplementedType.  Does anyone
know of a way to get numpy to raise instead of returning not
implemented type?

(Pydb) other.value
NotImplemented
(Pydb) print other.value
NotImplemented
(Pydb) type(other.value)



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

Re: [Numpy-discussion] arange and floating point arguments

[Timothy Hochberg]

On 9/14/07, Joris De Ridder <[EMAIL PROTECTED]> wrote:
>
>
>
> > the question is how to reduce user astonishment.
>
> IMHO this is exactly the point. There seems to be two questions here:
> 1) do we want to reduce user astonishment, and 2) if yes, how could
> we do this? Not everyone seems to be convinced of the first question,
> replying that in many cases linspace() could well replace arange().
> In many cases, yes, but not all. For some cases arange() has its
> legitimate use, even for floating point, and in these cases you may
> get bitten by the inexact number representation. If Matlab seems to
> be able to avoid surprises, why not numpy?


Perhaps because it's a bad idea? This case may be different, but in general
in cases where you try to sweep the surprising nature of floating point
under the rug, you are never entirely successful. The end result is that,
although surprises crop up with less regularity, they are much, much harder
to diagnose and understand when they do crop up.

If arange can be "fixed" in a way that's easy to understand, then great.
However, if the algorithm for deciding the points is anything but dirt
simple, leave it alone. Or, perhaps, deprecate floating point values as
arguments. I'm not very convinced by the arguments advanced thus far that
arange with floating point has legitimate uses. I've certainly used it this
way myself, but I believe that all of my uses could easily be replaced with
either linspace or arange with integer arguments.  I suspect that cases
where the exact properties of arange are required are far between and it's
easy enough to simulate the current behaviour if needed. An advantage to
that is that the potential pitfalls become obvious when you roll your own
version.



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

Re: [Numpy-discussion] NotImplementedType

[Travis E. Oliphant]

Tom Denniston wrote:
> Sometimes numpy operationrs result in NotImplementedType.  It makes it
> a little hard to debug because the problem then crops up later when
> you try to do an operation with the NotImplementedType.  Does anyone
> know of a way to get numpy to raise instead of returning not
> implemented type?
>   
Part of the issue is that this is what Python expects when it does it's 
mixed-type operations.  So, which operators are you referring to exactly?

-Travis

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

Re: [Numpy-discussion] NotImplementedType

[Tom Denniston]

The hitch is the error is in the bowels of the Scientific Python so I
was trying to get it to throw an exception to see what was going on.
It's while Scientific Python is trying to take a derivate.  It's
further aggrevated by the fact that due to some bug in pdb or pydb,
i'm unable to get up the stack in the debuger and look at the data
that caused the NotImplemntedType result.

I can always put breakpoints in the Scientific Python code I just
thought it would be easier if I could easily cause it to throw and
exception when the error occurs.  If that's hard i'll just set
breakpoints and dig.

--Tom


On 9/14/07, Travis E. Oliphant <[EMAIL PROTECTED]> wrote:
> Tom Denniston wrote:
> > Sometimes numpy operationrs result in NotImplementedType.  It makes it
> > a little hard to debug because the problem then crops up later when
> > you try to do an operation with the NotImplementedType.  Does anyone
> > know of a way to get numpy to raise instead of returning not
> > implemented type?
> >
> Part of the issue is that this is what Python expects when it does it's
> mixed-type operations.  So, which operators are you referring to exactly?
>
> -Travis
>
> ___
> 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] arange and floating point arguments

[Charles R Harris]

On 9/14/07, Timothy Hochberg <[EMAIL PROTECTED]> wrote:
>
>
>
> On 9/14/07, Joris De Ridder <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > > the question is how to reduce user astonishment.
> >
> > IMHO this is exactly the point. There seems to be two questions here:
> > 1) do we want to reduce user astonishment, and 2) if yes, how could
> > we do this? Not everyone seems to be convinced of the first question,
> > replying that in many cases linspace() could well replace arange().
> > In many cases, yes, but not all. For some cases arange() has its
> > legitimate use, even for floating point, and in these cases you may
> > get bitten by the inexact number representation. If Matlab seems to
> > be able to avoid surprises, why not numpy?
>
>
> Perhaps because it's a bad idea? This case may be different, but in
> general in cases where you try to sweep the surprising nature of floating
> point under the rug, you are never entirely successful. The end result is
> that, although surprises crop up with less regularity, they are much, much
> harder to diagnose and understand when they do crop up.
>

Exactly. The problem becomes even more dependent on particular circumstance.
For instance, if (.2 + .2 + .1) is used instead  of (.2 + .4).

If arange can be "fixed" in a way that's easy to understand, then great.
> However, if the algorithm for deciding the points is anything but dirt
> simple, leave it alone. Or, perhaps, deprecate floating point values as
> arguments. I'm not very convinced by the arguments advanced thus far that
> arange with floating point has legitimate uses. I've certainly used it this
> way myself, but I believe that all of my uses could easily be replaced with
> either linspace or arange with integer arguments.  I suspect that cases
> where the exact properties of arange are required are far between and it's
> easy enough to simulate the current behaviour if needed. An advantage to
> that is that the potential pitfalls become obvious when you roll your own
> version.
>

In the case of arange it should be possible to determine when the result is
potentially ambiguous and issue a warning. For instance, if the argument of
the ceil function is close to its rounded value.

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

Re: [Numpy-discussion] arange and floating point arguments

[Robert Kern]

Joris De Ridder wrote:
> 
>> the question is how to reduce user astonishment.
> 
> IMHO this is exactly the point. There seems to be two questions here:  
> 1) do we want to reduce user astonishment, and 2) if yes, how could  
> we do this? Not everyone seems to be convinced of the first question,  
> replying that in many cases linspace() could well replace arange().  
> In many cases, yes, but not all. For some cases arange() has its  
> legitimate use, even for floating point, and in these cases you may  
> get bitten by the inexact number representation. If Matlab seems to  
> be able to avoid surprises, why not numpy?

Here's the thing: binary floating point is intrinsically surprising to people
who are only accustomed to decimal. The way to not be surprised is to not use
binary floating point. You can hide some of the surprises, but not all of them.
When you do try to hide them, all you are doing is creating complicated, ad hoc
behavior that is also difficult to predict; for those who have become accustomed
to binary floating point's behavior, it's not clear what the "unastonishing"
behavior is supposed to be, but binary floating point's is well-defined.

Binary floating point is a useful tool for many things. I'm not interested in
making numpy something that hides that tool's behavior in order to force it into
a use it is not appropriate for.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] arange and floating point arguments

[Robert Kern]

Charles R Harris wrote:

> In the case of arange it should be possible to determine when the result
> is potentially ambiguous and issue a warning. For instance, if the
> argument of the ceil function is close to its rounded value.

What's "close"? The appropriate tolerance depends on the operations that would
cause error. For literal inputs, where the only source of error is
representation error, 1 eps would suffice, but then so would linspace(). For
results of other computations, you might need more than 1 eps. But if you're
doing computations, then it oughtn't to matter whether you get the endpoint or
not (since you don't know what the values are anyway).

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] arange and floating point arguments

[Charles R Harris]

On 9/14/07, Robert Kern <[EMAIL PROTECTED]> wrote:
>
> Charles R Harris wrote:
>
> > In the case of arange it should be possible to determine when the result
> > is potentially ambiguous and issue a warning. For instance, if the
> > argument of the ceil function is close to its rounded value.
>
> What's "close"? The appropriate tolerance depends on the operations that
> would
> cause error. For literal inputs, where the only source of error is
> representation error, 1 eps would suffice, but then so would linspace().
> For
> results of other computations, you might need more than 1 eps. But if
> you're
> doing computations, then it oughtn't to matter whether you get the
> endpoint or
> not (since you don't know what the values are anyway).


I would make 'close' very rough, maybe a relative 100*eps. The point would
be to warn of *potential* problems and suggest linspace or some other
approach, not to warn on only real problems. My guess is that most uses of
arange are either well defined or such that a less ambiguous approach should
be used. In a way, the warning would be a guess at programmer intent and a
gentler solution than making arange integer only.

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

[Numpy-discussion] Buildbot errors

[Charles R Harris]

I got another buildbot notification and as far as I can tell it has nothing
to do with my last commit. The stdio output is at

http://buildbot.scipy.org/MacOSX%20x86/builds/49/step-shell/0

And the errors seem to be of this sort:

_configtest.c: In function 'main':
_configtest.c:4: error: 'isnan' undeclared (first use in this function)
_configtest.c:4: error: (Each undeclared identifier is reported only once
_configtest.c:4: error: for each function it appears in.)
_configtest.c: In function 'main':
_configtest.c:4: error: 'isnan' undeclared (first use in this function)
_configtest.c:4: error: (Each undeclared identifier is reported only once
_configtest.c:4: error: for each function it appears in.)


_configtest.c: In function 'main':
_configtest.c:4: error: 'isinf' undeclared (first use in this function)
_configtest.c:4: error: (Each undeclared identifier is reported only once
_configtest.c:4: error: for each function it appears in.)
_configtest.c: In function 'main':
_configtest.c:4: error: 'isinf' undeclared (first use in this function)
_configtest.c:4: error: (Each undeclared identifier is reported only once
_configtest.c:4: error: for each function it appears in.)

I haven't had any problems compiling on my own machine.

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

Re: [Numpy-discussion] Buildbot errors

[Robert Kern]

Charles R Harris wrote:
> I got another buildbot notification and as far as I can tell it has
> nothing to do with my last commit. The stdio output is at
> 
> http://buildbot.scipy.org/MacOSX%20x86/builds/49/step-shell/0
> 

That's not the output of the thing that failed. The build succeeded, but the
following step, trying to run the unit tests, failed.

  http://buildbot.scipy.org/MacOSX%20x86/builds/49/step-shell_2/0

It appears to me that there is some confusion about which Python is being
executed. The tests seem to expect Python 2.5:

  sys.path=["numpy-install/lib/python2.5/site-packages"]

whereas the install is picking up Python 2.3:

  byte-compiling ../numpy-install/lib/python2.3/site-packages/numpy/dual.py to
dual.pyc

Barry, can you check this and make sure that the correct Python gets picked up
during the build? Thanks.

> And the errors seem to be of this sort:
> 
> _configtest.c: In function 'main':
> _configtest.c:4: error: 'isnan' undeclared (first use in this function)
> _configtest.c:4: error: (Each undeclared identifier is reported only once
> 
> _configtest.c:4: error: for each function it appears in.)
> _configtest.c: In function 'main':
> _configtest.c:4: error: 'isnan' undeclared (first use in this function)
> _configtest.c:4: error: (Each undeclared identifier is reported only once
> 
> _configtest.c:4: error: for each function it appears in.)
> 
> 
> _configtest.c: In function 'main':
> _configtest.c:4: error: 'isinf' undeclared (first use in this function)
> 
> _configtest.c:4: error: (Each undeclared identifier is reported only once
> _configtest.c:4: error: for each function it appears in.)
> _configtest.c: In function 'main':
> _configtest.c:4: error: 'isinf' undeclared (first use in this function)
> 
> _configtest.c:4: error: (Each undeclared identifier is reported only once
> _configtest.c:4: error: for each function it appears in.)
> 
> I haven't had any problems compiling on my own machine.

Those aren't errors that would stop the build; they just tell the config command
that isnan() and isinf() aren't available on the platform.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] arange and floating point arguments

[Charles R Harris]

On 9/14/07, lorenzo bolla <[EMAIL PROTECTED]> wrote:
>
> this is really annoying.
> Matlab handles the "ceil" weirdness quite well, though.
>
> --
>
> >> ceil(0.6/0.1)
>
> ans =
>
>  6
>
> >> ceil((0.4+0.2)/0.1)
>
> ans =
>
>  7
>
> >> 0:0.1:0.6
>
> ans =
>
>  01.000e-001
> 2.000e-0013.000e-0014.000e-001
> 5.000e-0016.000e-001
>
> >> 0:0.1:(0.4+0.2)
>
> ans =
>
>  01.000e-001
> 2.000e-0013.000e-0014.001e-001
> 5.001e-0016.001e-001
>

Well, in Matlab the end point is specified and the result of the division is
probably rounded, so in order to have problems you might need to use
something like .55 as the endpoint. In Numpy's arange an upper bound is used
instead, so roundoff is a problem, but the 5.5 case would be handled easily.

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

Re: [Numpy-discussion] Buildbot errors

[Barry Wark]

Sorry about the hassle. It was working fine before a reboot. I'll try
to fix it this evening.

barry

On 9/14/07, Robert Kern <[EMAIL PROTECTED]> wrote:
> Charles R Harris wrote:
> > I got another buildbot notification and as far as I can tell it has
> > nothing to do with my last commit. The stdio output is at
> >
> > http://buildbot.scipy.org/MacOSX%20x86/builds/49/step-shell/0
> > 
>
> That's not the output of the thing that failed. The build succeeded, but the
> following step, trying to run the unit tests, failed.
>
>   http://buildbot.scipy.org/MacOSX%20x86/builds/49/step-shell_2/0
>
> It appears to me that there is some confusion about which Python is being
> executed. The tests seem to expect Python 2.5:
>
>   sys.path=["numpy-install/lib/python2.5/site-packages"]
>
> whereas the install is picking up Python 2.3:
>
>   byte-compiling ../numpy-install/lib/python2.3/site-packages/numpy/dual.py to
> dual.pyc
>
> Barry, can you check this and make sure that the correct Python gets picked up
> during the build? Thanks.
>
> > And the errors seem to be of this sort:
> >
> > _configtest.c: In function 'main':
> > _configtest.c:4: error: 'isnan' undeclared (first use in this function)
> > _configtest.c:4: error: (Each undeclared identifier is reported only once
> >
> > _configtest.c:4: error: for each function it appears in.)
> > _configtest.c: In function 'main':
> > _configtest.c:4: error: 'isnan' undeclared (first use in this function)
> > _configtest.c:4: error: (Each undeclared identifier is reported only once
> >
> > _configtest.c:4: error: for each function it appears in.)
> >
> >
> > _configtest.c: In function 'main':
> > _configtest.c:4: error: 'isinf' undeclared (first use in this function)
> >
> > _configtest.c:4: error: (Each undeclared identifier is reported only once
> > _configtest.c:4: error: for each function it appears in.)
> > _configtest.c: In function 'main':
> > _configtest.c:4: error: 'isinf' undeclared (first use in this function)
> >
> > _configtest.c:4: error: (Each undeclared identifier is reported only once
> > _configtest.c:4: error: for each function it appears in.)
> >
> > I haven't had any problems compiling on my own machine.
>
> Those aren't errors that would stop the build; they just tell the config 
> command
> that isnan() and isinf() aren't available on the platform.
>
> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless enigma
>  that is made terrible by our own mad attempt to interpret it as though it had
>  an underlying truth."
>   -- Umberto Eco
>
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] arange and floating point arguments

[Christopher Barker]

Robert Kern wrote:
> Here's the thing: binary floating point is intrinsically surprising to people
> who are only accustomed to decimal.

Very good point. Binary arithmetic is NOT less accurate that decimal 
arithmetic, it just has different values that it can't represent 
exactly. So one is surprised that 1.0/3.0 isn't represented exactly!

The confusion stems from th fact that we use decimal literals, even when 
using binary arithmetic, but you just need to learn to get used to it.

For what it's worth, the MATLAB mailing list has a constant trickle of 
notes from new users along the lines of "MATLAB is broken!" when they 
have encountered binary-decimal issues like these. It is inescapable.

Binary representation was one of the first things I learned in my first 
computer class , using Basic, over 25 years ago (am I really that old!). 
You really need to learn at least a tiny bit about binary if you're 
going to do math with computers.

Oh, and could someone post an actual example of a use for which FP 
arange is required (with fudges to try to accommodate decimal to binary 
conversion errors), and linspace won't do?

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] arange and floating point arguments

[Anne Archibald]

On 15/09/2007, Christopher Barker <[EMAIL PROTECTED]> wrote:

> Oh, and could someone post an actual example of a use for which FP
> arange is required (with fudges to try to accommodate decimal to binary
> conversion errors), and linspace won't do?

Well, here's one: evaluating a function we know to be bandlimited to N
harmonics and positive trying to bracket a maximum. We know it doesn't
change much faster than T/N, so I might use

xs = arange(0,T,1/float(4*N))

and then evaluate the function there.

Of course, I don't care how many points there are, so no fudges
please. But floating-point arange is certainly useful here; to use
linspace or integer arange I'd have to write it in a much clumsier
way. (Okay, a little clumsier.)

In fact, reluctant as I am to provide arguments in favour of godawful
floating-point fudges, if I have the harmonics I can use irfft to
evaluate my function. I'll then have to carefully calculate the
x-values where irfft evaluates, and an off-by-one problem is going to
cause my program to fail. I would use integer arange and scale as
appropriate, but there's something to be said for using floating-point
arange. linspace(...,endpoint=False) is fine, though.

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