numpy-discussion — Discussion list for all users of Numerical Python

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

[David G. <Dav...@no...>]

Greg Willden wrote:
> May I suggest the following change to generate_umath.py?
>
> <completely untested string change>
> 'sqrt' :
>     Ufunc(1, 1, None,
>           'square-root elementwise. For real x, the domain is 
> restricted to x>=0.\n\
>           For complex results for x<0 see numpy.scimath.sqrt',
>           TD(inexact, f='sqrt'),
>           TD(M, f='sqrt'),
>           ),
> '
>
> When sqrt throws a ValueError would it be possible/appropriate for the 
> error message to mention numpy.scimath.sqrt?
>
> I'm just trying to think of other ways to help make the transition as 
> smooth as possible for new users.
And helpful error messages are one of Python's best features - in 
general, numpy doesn't have enough of 'em, IMO.

DG
>
> Greg
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> ------------------------------------------------------------------------
>
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>   

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than?nan?

[Stefan v. d. W. <st...@su...>]

On Thu, Oct 12, 2006 at 10:53:12AM -0400, Alan G Isaac wrote:
> On Thu, 12 Oct 2006, Stefan van der Walt apparently wrote:=20
> > I tried to explain the argument at=20
> > http://www.scipy.org/NegativeSquareRoot=20
>=20
> Helpful.  But you start off by saying:
>         In mathematics, the above assumption is true -- that=20
>         the square root of -1 is 1j.
>=20
> Since square root is (here) a function, and part of the=20
> function definition is the domain and codomain, this=20
> statement is not correct.  If the codomain is real numbers,=20
> the domain must correspondingly be (a subset of) the=20
> nonnegative reals.  The nan output is the result of an=20
> **invalid** input.
>=20
> So the question is really: "Why is a negative real number an=20
> invalid input in this implementation", or "Why in this=20
> implementation is the type of the output restricted by the=20
> type of the input?" You get a good start on answering that.

You are more than welcome to change the wiki if you can think of a
simpler way to explain the problem... In fact, I would encourage that
-- I just put it there as a starting point.

Cheers
St=E9fan

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

[A. M. A. <per...@gm...>]

On 12/10/06, David Goldsmith <Dav...@no...> wrote:

> I don't use scipy (and don't want to because of the overhead) but it
> sounds like I should because if I'm taking the square root of a variable
> whose value at run time happens to be real but less than zero, I *want*
> the language I'm using to return an imaginary; in other words, it's not
> the scipy behavior which "scares" me, its the numpy (which I do/have
> been using) behavior.  To which you might say, "Well, if that's what you
> want, and you have Matlab (as you've said you do), then just use that."
> But that's precisely the point: people who don't want to be bothered
> with having to be "a bit more care[ful]" (as Chuck put it) - and who can
> afford it - are going to be inclined to choose Matlab over numpy.
> Perhaps one doesn't care - in the grand scheme of things, it certainly
> doesn't matter - but I think that you all should be aware that this
> numpy "feature" will be seen by many as more than just a nuisance.

Scipy doesn't do what you want. What you want is to use complex
numbers throughout; then numpy and scipy will do exactly what you
request.

A. M. Archibald

[Numpy-discussion] PATCH build numpy-1.0rc2

[Neal B. <ndb...@gm...>]

I have not been able to build any of the numpy-1.0 series.  Finally I bit
the bullet and fixed it.  Here is the patch:
diff -u numpy-1.0rc2/numpy/numarray/setup.py{~,}
--- numpy-1.0rc2/numpy/numarray/setup.py~       2006-07-26
16:04:32.000000000 -0400
+++ numpy-1.0rc2/numpy/numarray/setup.py        2006-10-12 11:58:23.000000000 -0400
@@ -5,7 +5,8 @@
     from numpy.distutils.misc_util import Configuration
     config = Configuration('numarray',parent_package,top_path)
 
-    config.add_data_files('numpy/')
+#    config.add_data_files('numpy/')
+    config.add_data_dir('numpy/')
     
     # Configure fftpack_lite
     config.add_extension('_capi',

Re: [Numpy-discussion] Things to address for Py3K

[Rob H. <he...@ta...>]

On Oct 11, 2006, at 1:41 PM, Travis Oliphant wrote:

>    a) an extra multiplication operator to distinguish between
> element-by-element and dot

One of the things I like about numpy is that element-by-element  
multiplication is default.  Really, most of what I do is element by  
element, punctuated by a few matrix multiplications (or whatever  
other matrix operations) at the end.  If I had a penny for every '.'  
I put in front of an operator in MATLAB, I would buy us all new  
computers -- expensive ones even.

I hope that, if there is another multiplication operator like .*,  
that this will be shorthand for dot(A, B), and not for elem-by-elem  
multiplication.

-Rob

----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

[Andrew J. <a.h...@gm...>]

Tim Hochberg wrote:
> Travis Oliphant wrote:
>> Tim Hochberg wrote:
>>
>>   
>>> With python 2.5 out now, perhaps it's time to come up with a with 
>>> statement context manager. Something like:
>>>
>>>    a = numpy.arange(10)
>>>    a/a # ignores divide by zero
>>>    with errstate(divide='raise'):
>>>        a/a # raise exception on divide by zer
>>>    # Would ignore divide by zero again if we got here.
>>>
>>> -tim
>>>
>> This looks great.  I think most people aren't aware of the with 
>> statement and what it can do (I'm only aware because of your posts, for 
>> example). 
>>
>> So, what needs to be added to your example in order to just add it to 
>> numpy?
>>   
> As far as I know, just testing  and documentation -- however testing was 
> so minimal that I may find some other stuff. I'll try to clean it up 
> tomorrow so that I'm a little more confident that it works correctly and 
> I'll send another note out then.

For this particular application, why not a context manager which just 
substitutes in the appropriately-optimized version of sqrt? That is, 
don't change the error state, but actually change the value of the 
object pointed at by the name sqrt?

Andrew

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

[Greg W. <gre...@gm...>]

May I suggest the following change to generate_umath.py?

<completely untested string change>
'sqrt' :
    Ufunc(1, 1, None,
          'square-root elementwise. For real x, the domain is restricted to
x>=0.\n\
          For complex results for x<0 see numpy.scimath.sqrt',
          TD(inexact, f='sqrt'),
          TD(M, f='sqrt'),
          ),
'

When sqrt throws a ValueError would it be possible/appropriate for the error
message to mention numpy.scimath.sqrt?

I'm just trying to think of other ways to help make the transition as smooth
as possible for new users.

Greg

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

[Greg W. <gre...@gm...>]

I'll try to quit being a pain and just work around it.

Those wiki pages are really good to capture this information.  I need to
read all of them to know what other gotchas are out there.
Thanks and Sorry,
Greg

On 10/12/06, Alan G Isaac <ai...@am...> wrote:
>
> That's fine, but be sure to treat the explanations you are
> receiving with the same seriousness that you treat your
> doubts.
>
> For example, in the speed vs. correctness discussion, be
> sure to understand the problems with the word "correct".
> Which have been explained.
>
> correct != expected
> when expectations lack context
>

Re: [Numpy-discussion] =?iso-8859-1?q?Should_numpy=2Esqrt=28-1=29_ret?= =?iso-8859-1?q?urn_1j_rather_than=09nan=3F?=

[Alan G I. <ai...@am...>]

On Thu, 12 Oct 2006, Stefan van der Walt apparently wrote:=20
> I tried to explain the argument at=20
> http://www.scipy.org/NegativeSquareRoot=20

Helpful.  But you start off by saying:
        In mathematics, the above assumption is true -- that=20
        the square root of -1 is 1j.

Since square root is (here) a function, and part of the=20
function definition is the domain and codomain, this=20
statement is not correct.  If the codomain is real numbers,=20
the domain must correspondingly be (a subset of) the=20
nonnegative reals.  The nan output is the result of an=20
**invalid** input.

So the question is really: "Why is a negative real number an=20
invalid input in this implementation", or "Why in this=20
implementation is the type of the output restricted by the=20
type of the input?" You get a good start on answering that.

Cheers,
Alan Isaac

Re: [Numpy-discussion] Please test the SVN branch

[Tim H. <tim...@ie...>]

Travis Oliphant wrote:
> I made some fixes to the "asbuffer" code which let me feel better about 
> exposing it in NumPy (where it is now named int_asbuffer).
>
> This code takes a Python integer and a size and returns a buffer object 
> that points to that memory.  A little test is performed by trying to 
> read (and possibly write if a writeable buffer is requested) to the 
> first and last elements of the buffer.  Any segfault is trapped and used 
> to raise a Python error indicating you can't use that area of memory. 
>
> It doesn't guarantee you won't shoot yourself, but it does make it more 
> difficult to segfault Python.  Previously a simple int_asbuffer(3423423, 
> 5) would have segfaulted (unless by chance you the memory area 3423423 
> happens to be owned by Python).
>
> I have not tested the code on other platforms to make sure it works as 
> expected, so please try and compiled it.
>   
FWIW, it compiles fine and passes all tests under Visual Studio and 
Python 2.4.3. I haven't tried to use it though.

-tim


> -Travis
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
>
>   

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

[Tim H. <tim...@ie...>]

Travis Oliphant wrote:
>>     Personally I think that the default error mode should be tightened
>>     up.
>>     Then people would only see these sort of things if they really care
>>     about them. Using Python 2.5 and the errstate class I posted earlier:
>>
>>         # This is what I like for the default error state
>>         numpy.seterr (invalid='raise', divide='raise', over='raise',
>>         under='ignore')
>>
>>
>> I like these choices too. Overflow, division by zero, and sqrt(-x) are 
>> usually errors, indicating bad data or programming bugs. Underflowed 
>> floats, OTOH, are just really, really small numbers and can be treated 
>> as zero. An exception might be if the result is used in division and 
>> no error is raised, resulting in a loss of accuracy.
>>
>>     
>
> I'm fine with this.  I've hesitated because error checking is by default 
> slower.  But, I can agree that it is "less surprising" to new-comers.  
> People that don't mind no-checking can simply set their defaults back to 
> 'ignore'
>
>   
Great.

One thing we may want to do (numarray had this), was add a pseudo 
argument 'all', that allows you to set all of the values at once. Then 
if you want the full-bore, ignore-all-errors computation (and your using 
2.5 and "from __future__ import with_statement") you can just do:

with errstate(all='ignore'):
    # computation here
# back to being picky

-tim

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

[Stefan v. d. W. <st...@su...>]

On Thu, Oct 12, 2006 at 08:58:21AM -0500, Greg Willden wrote:
> On 10/11/06, Bill Baxter <wb...@gm...> wrote:
>=20
>     On 10/12/06, Greg Willden <gre...@gm...> wrote:
>     > Speed should not take precedence over correctness.
>=20
>     Unless your goal is speed.  Then speed should take precedence over
>     correctness.
>=20
>=20
> Huh?
> Person 1:  "Hey you should use function X."
> Person 2:  "No, it doesn't give me the correct answer."
> Person 1: "Who cares?  It's fast!"
>=20
> What kind of logic is that?

I tried to explain the argument at

http://www.scipy.org/NegativeSquareRoot

Cheers
St=E9fan

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

[Tim H. <tim...@ie...>]

Travis Oliphant wrote:
> Travis Oliphant wrote:
>   
>> Now, it would be possible to give ufuncs a dtype keyword argument that 
>> allowed you to specify which underlying loop was to be used for the 
>> calculation.  That way you wouldn't have to convert inputs to complex 
>> numbers before calling the ufunc, but could let the ufunc do it in 
>> chunks during the loop.   That is certainly a reasonable enhancement: 
>>
>> sqrt(a, dtype=complex). 
>>
>> This no-doubt has a "library-ish"-feeling, but that is what NumPy is.   
>> If such a change is desireable, I don't think it would be much to 
>> implement it.
>>
>>   
>>     
> This could be implemented, but only with a version number increase in 
> the C-API (we would have to change the c-signature of the ufunc tp_call. 
>
> This would mean that the next release of NumPy would be binary 
> incompatible with packages built to previous NumPy releases.  
>
> I've really been trying to avoid doing that.  So, unless there are 
> strong requests for this feature that outweigh the negatives of 
> re-building dependent packages, then this feature will have to wait. 
>
> OTOH:   I suppose it could be implemented in a different way (using 
> indexing or a method call):
>
> sqrt[complex](a)   --- I remember Tim suggesting some use for indexing 
> on ufuncs earlier though.
>   
It wouldn't surprise me if I did -- it sounds like the kind of thing I'd 
propose -- but I certainly can't remember what I was proposing.

-tim

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

[Tim H. <tim...@ie...>]

Mark Bakker wrote:
> My vote is for consistency in numpy.
> But it is unclear what consistency is.
>
> What is truly confusing for newbie Python users (and a source for 
> error even after 5 years of Python programming) is that
>
> >>> 2/3
> 0
I recommend that you slap "from __future__ import division" into site.py 
or the top of your program:

    from __future__ import division

    import numpy
    print 3/2
    a = numpy.arange(3)
    print a / (a+5)
    print a // a+5

     >>>>

    1.5
    [ 0.          0.16666667  0.28571429]
    [5 6 6]


>
> In that respect, I would think
>
> >>> numpy.sqrt(2)
>
> should give 1, but it gives 1.4142135623730951
Is there any practical reason to return 1? If not, isn't this argument 
sort of silly?

> So numpy does typechecking anyway (it gets an integer and makes it a 
> float).
>
> If that is the consistent behavior, then by all means
>
> >>> sqrt(-1)
>
> should return 1j.
Well, it could also return: -1j or as someone mentioned one of six (I 
think) different quaternion values. It all depends on what the 
domain/range of the problem is.

> Wouldn't that be the consistent thing to do????

No, there's a difference. In order to do the former, all that is 
required is that sqrt switches on the *type* of it argument. sqrt return 
a float for integer and floating point args and a complex for complex 
args. In order to the latter, sqrt needs to switch on the *value* of its 
argument, which is an entirely different beast both in theory and in 
practice. In particular:

    sqrt(some_big_array)

would have to scan all the values in the array to determine if any were 
negative to decide whether to return a float or an imaginary number. It 
also means that the memory usage is unpredictable -- the returned array 
is double in size if any values are negative.

In addition to the significant slowdown this introduces, the former 
approach (keeping the input and output domains the same) is somewhat 
more robust against error, particularly if one tightens up the error 
mode. I would guess that people are working the complex plane at most 
half the time, in the former case a negative square root signals a 
problem and promoting to complex is at best a nuisance and may result in 
a painful to track down error. In the latter case, it's easy enough for 
me to toss in a astype in situations where I'm mixing domains and need 
complex outputs.

Ideally numpy and scipy would have chosen different names for forgiving 
and strict powers and square roots, square_root and power versus sqrt 
and pow for example, but it's probably too late to do anything about 
that now.

Since it sounds like Travis is going to tighten up the default error 
mode, I think that this is a non issue. No ones going to run into NANs 
unexpectedly and the error when doing sqrt([1,2,3,-1]) should be 
confusing and most once.

-tim

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

[James G. <jg...@ca...>]

Greg Willden wrote:
> On 10/11/06, *Bill Baxter* <wb...@gm... 
> <mailto:wb...@gm...>> wrote:
> 
>     On 10/12/06, Greg Willden <gre...@gm...
>     <mailto:gre...@gm...>> wrote:
>      > Speed should not take precedence over correctness.
> 
>     Unless your goal is speed.  Then speed should take precedence over
>     correctness. 
> 
> 
> Huh?
> Person 1:  "Hey you should use function X."
> Person 2:  "No, it doesn't give me the correct answer."
> Person 1: "Who cares?  It's fast!"
> 
> What kind of logic is that?
> 
> I'm having serious doubts about my conversion to Numpy.

It's more like
Person 1: Function x is designed to be fast, have predictable memory usage and 
so be suitable for a wide variety of applications. Alternatively there is 
function y which is slower but handles a larger numerical domain. y Might be 
more sutiable for your needs; you should use it.
Person 2: Numpy is broken! Function x should just do what I want!

Really, given that both options are available, I don't see a big issue here. 
Claims that returning j for sqrt(-1) is "more correct" seem highly dubious as a) 
NumPy is a numerical library, not an algebraic one, hence the fact that it 
behaves in a type-dependent way is not so surprising, and b) no one complains 
that functions like sqrt return only positive floats, despite the fact that, 
mathematically, this function is multivalued.

-- 
"Eternity's a terrible thought. I mean, where's it all going to end?"
  -- Tom Stoppard, Rosencrantz and Guildenstern are Dead

Re: [Numpy-discussion] =?iso-8859-1?q?Should_numpy=2Esqrt=28-1=29_ret?= =?iso-8859-1?q?urn_1j_rather_than=09nan=3F?=

[Alan G I. <ai...@am...>]

On Thu, 12 Oct 2006, Greg Willden apparently wrote:=20
> I'm having serious doubts about my conversion to Numpy.=20

That's fine, but be sure to treat the explanations you are=20
receiving with the same seriousness that you treat your=20
doubts.

For example, in the speed vs. correctness discussion, be=20
sure to understand the problems with the word "correct".
Which have been explained.

correct !=3D expected
when expectations lack context

Cheers,
Alan Isaac
(just a happy user)

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

[Greg W. <gre...@gm...>]

On 10/11/06, Bill Baxter <wb...@gm...> wrote:
>
> On 10/12/06, Greg Willden <gre...@gm...> wrote:
> > Speed should not take precedence over correctness.
>
> Unless your goal is speed.  Then speed should take precedence over
> correctness.


Huh?
Person 1:  "Hey you should use function X."
Person 2:  "No, it doesn't give me the correct answer."
Person 1: "Who cares?  It's fast!"

What kind of logic is that?

I'm having serious doubts about my conversion to Numpy.
Greg

[Numpy-discussion] Compiling Numpy with py2exe

[Charles H. <c....@se...>]

Hello,

=20

I've a program using Numpy and I would like to compile it with Py2exe
but I've some problems. When I try to compile my program, some modules
generated by numpy are not loaded. I've already asked to the py2exe
community if they have a solution for that and the answer was that it
was possible to compile numpy modules with py2exe but I should ask to
the Numpy community :-)

=20

So my question is, is there something special to do in order to compile
a program using numpy module?

=20

This is the setup.py file that I use

=20

=20

from distutils.core import setup

import py2exe, sys

=20

sys.path.append("tools")

sys.path.append("report")

sys.path.append("spirent")

sys.path.append("numpydir")

=20

setup(

             console =3D ['checkfile.py'],

             )

=20

=20

If I use this setup.py, lots of numpy file cannot be loaded. I get the
following message

=20

=20

copying c:\python24\lib\site-packages\py2exe\run.exe ->
Y:\svn\copy\dist\checkfile.exe

The following modules appear to be missing

['DateTime', 'FFT', 'Ft.Lib', 'Ft.Lib.DumpBgTuple', 'Ft.__init__',
'LinearAlgebra', 'MA', 'MLab', 'Matrix', 'Numeric', 'Pyrex',
'Pyrex.Compiler', 'XPathParserc'

, '_curses', 'backends.draw_if_interactive',
'backends.new_figure_manager', 'backends.pylab_setup', 'backends.show',
'core.abs', 'core.max', 'core.min', 'core.r

ound', 'ctypes', 'ext.IsDOMString', 'ext.SplitQName',
'fcompiler.FCompiler', 'fcompiler.show_fcompilers', 'lib.add_newdoc',
'mlab.amax', 'mlab.amin', 'numarray'

, 'numarray.convolve', 'numarray.fft', 'numarray.ieeespecial',
'numarray.linear_algebra', 'numarray.linear_algebra.mlab',
'numarray.ma', 'numarray.numeric', 'nu

merix.ArrayType', 'numerix.Complex', 'numerix.Complex32',
'numerix.Complex64', 'numerix.Float', 'numerix.Float32',
'numerix.Float64', 'numerix.Int', 'numerix.In

t16', 'numerix.Int32', 'numerix.Int8', 'numerix.NewAxis',
'numerix.UInt16', 'numerix.UInt32', 'numerix.UInt8', 'numerix.absolute',
'numerix.add', 'numerix.all',

 'numerix.allclose', 'numerix.alltrue', 'numerix.any', 'numerix.arange',
'numerix.arccos', 'numerix.arccosh', 'numerix.arcsin',
'numerix.arcsinh', 'numerix.arct

an', 'numerix.arctan2', 'numerix.arctanh', 'numerix.argmax',
'numerix.argmin', 'numerix.argsort', 'numerix.around', 'numerix.array',
'numerix.arrayrange', 'nume

rix.asarray', 'numerix.asum', 'numerix.bitwise_and',
'numerix.bitwise_or', 'numerix.bitwise_xor', 'numerix.ceil',
'numerix.choose', 'numerix.clip', 'numerix.com

press', 'numerix.concatenate', 'numerix.conjugate', 'numerix.convolve',
'numerix.cos', 'numerix.cosh', 'numerix.cross_correlate',
'numerix.cumproduct', 'numerix

=2Ecumsum', 'numerix.diagonal', 'numerix.divide', 'numerix.dot',
'numerix.equal', 'numerix.exp', 'numerix.fabs', 'numerix.fft.fft',
'numerix.fft.inverse_fft', 'nu

merix.floor', 'numerix.fmod', 'numerix.fromfunction',
'numerix.fromstring', 'numerix.greater', 'numerix.greater_equal',
'numerix.hypot', 'numerix.identity', 'nu

merix.indices', 'numerix.innerproduct', 'numerix.iscontiguous',
'numerix.isnan', 'numerix.less', 'numerix.less_equal', 'numerix.log',
'numerix.log10', 'numerix.

logical_and', 'numerix.logical_not', 'numerix.logical_or',
'numerix.logical_xor', 'numerix.matrixmultiply', 'numerix.maximum',
'numerix.minimum', 'numerix.mlab.

amax', 'numerix.mlab.amin', 'numerix.mlab.cov', 'numerix.mlab.diff',
'numerix.mlab.hanning', 'numerix.mlab.rand', 'numerix.mlab.std',
'numerix.mlab.svd', 'numer

ix.multiply', 'numerix.negative', 'numerix.newaxis', 'numerix.nonzero',
'numerix.not_equal', 'numerix.nx', 'numerix.ones',
'numerix.outerproduct', 'numerix.pi',

            'numerix.power', 'numerix.product', 'numerix.put',
'numerix.putmask', 'numerix.rank', 'numerix.ravel', 'numerix.repeat',
'numerix.reshape', 'numerix.resize', '

numerix.searchsorted', 'numerix.shape', 'numerix.sin', 'numerix.sinh',
'numerix.size', 'numerix.sometrue', 'numerix.sort', 'numerix.sqrt',
'numerix.subtract', '

numerix.swapaxes', 'numerix.take', 'numerix.tan', 'numerix.tanh',
'numerix.trace', 'numerix.transpose', 'numerix.typecode',
'numerix.typecodes', 'numerix.where'

, 'numerix.which', 'numerix.zeros', 'pre', 'serial', 'setuptools',
'setuptools.command', 'setuptools.command.egg_info',
'setuptools.command.install', 'testing.S

cipyTest', 'win32api', 'win32con', 'win32pdh', 'xml.xslt',
'xml.xslt.ParsedPattern', 'numpy.Complex', 'numpy.Complex32',
'numpy.Complex64', 'numpy.Float', 'nump

y.Float32', 'numpy.Float64', 'numpy.Int', 'numpy.Int16', 'numpy.Int32',
'numpy.Int8', 'numpy.UInt16', 'numpy.UInt32', 'numpy.UInt8',
'numpy.arccos', 'numpy.arcc

osh', 'numpy.arcsin', 'numpy.arcsinh', 'numpy.arctan', 'numpy.arctanh',
'numpy.bitwise_and', 'numpy.bitwise_or', 'numpy.bitwise_xor',
'numpy.ceil', 'numpy.conju

gate', 'numpy.core.add', 'numpy.core.bitwise_and',
'numpy.core.bitwise_or', 'numpy.core.bitwise_xor', 'numpy.core.cdouble',
'numpy.core.complexfloating', 'numpy

=2Ecore.conjugate', 'numpy.core.csingle', 'numpy.core.divide',
'numpy.core.double', 'numpy.core.equal', 'numpy.core.float64',
'numpy.core.greater', 'numpy.core.gr

eater_equal', 'numpy.core.inexact', 'numpy.core.intc',
'numpy.core.invert', 'numpy.core.left_shift', 'numpy.core.less',
'numpy.core.less_equal', 'numpy.core.max

imum', 'numpy.core.not_equal', 'numpy.core.power',
'numpy.core.remainder', 'numpy.core.right_shift', 'numpy.core.sin',
'numpy.core.single', 'numpy.core.sqrt', '

numpy.core.subtract', 'numpy.cosh', 'numpy.dft.old', 'numpy.divide',
'numpy.e', 'numpy.fabs', 'numpy.floor', 'numpy.floor_divide',
'numpy.fmod', 'numpy.greater'

, 'numpy.hypot', 'numpy.invert', 'numpy.left_shift', 'numpy.less',
'numpy.log', 'numpy.log10', 'numpy.logical_and', 'numpy.logical_not',
'numpy.logical_or', 'nu

mpy.logical_xor', 'numpy.maximum', 'numpy.minimum', 'numpy.negative',
'numpy.not_equal', 'numpy.power', 'numpy.random.rand',
'numpy.random.randn', 'numpy.remain

der', 'numpy.right_shift', 'numpy.sinh', 'numpy.tan', 'numpy.tanh',
'numpy.true_divide']

=20

Do you know what to do to solve this problem?

=20

Thank you very much for your answers.

=20

=20



This e-mail communication contains information that is confidential and m=
ay also be privileged. It is intended for the exclusive use of the addres=
sees. If you are not the person or organization to whom it is addressed, =
you must not copy, distribute or take any action in reliance upon it. If =
you received this communication in error, please notify Septentrio nv imm=
ediately [ telephone +32 [0] 16 300800 ]. Septentrio nv will not accept l=
iability for contractual commitments made by individuals employed by this=
 company outside the scope of our business.

[Numpy-discussion] arraysetops update

[Robert C. <cim...@nt...>]

I have just added 'See also' to all docstrings in arraysetops functions,
 replaced old numpy idioms with new ones (aka modernizing) and
improved speed of numpy.unique1d, which now reflects numpy.unique.

hoping no bugs were introduced, regards,
r.

Re: [Numpy-discussion] Please test the SVN branch

[Stefan v. d. W. <st...@su...>]

On Thu, Oct 12, 2006 at 12:38:51AM -0600, Travis Oliphant wrote:
>=20
> I made some fixes to the "asbuffer" code which let me feel better about=
=20
> exposing it in NumPy (where it is now named int_asbuffer).
>=20
> This code takes a Python integer and a size and returns a buffer object=
=20
> that points to that memory.  A little test is performed by trying to=20
> read (and possibly write if a writeable buffer is requested) to the=20
> first and last elements of the buffer.  Any segfault is trapped and use=
d=20
> to raise a Python error indicating you can't use that area of memory.=20
>=20
> It doesn't guarantee you won't shoot yourself, but it does make it more=
=20
> difficult to segfault Python.  Previously a simple int_asbuffer(3423423=
,=20
> 5) would have segfaulted (unless by chance you the memory area 3423423=20
> happens to be owned by Python).

Some argument checking and a docstring would be helpful.  I guessed
wrong the first time:

In [1]: x =3D N.array([1,2,3])

In [4]: y =3D N.int_asbuffer(x.size,x.__array_interface__['data'][0])

In [5]: y[0]

Segmentation fault

Out of curiosity, why does the following outputs differ:

In [39]: y =3D N.int_asbuffer(0L,x.size)
-------------------------------------------------------------------------=
--
exceptions.SystemError                               Traceback (most rece=
nt call last)

/home/stefan/<ipython console>=20

SystemError: error return without exception set

In [40]: y =3D N.int_asbuffer(1L,x.size)
-------------------------------------------------------------------------=
--
exceptions.ValueError                                Traceback (most rece=
nt call last)

/home/stefan/<ipython console>=20

ValueError: cannot use memory location as a buffer.

Thanks for your work on this.

Cheers
St=E9fan

[Numpy-discussion] =?iso-8859-1?q?PhDjobs=2Ecom_-_October_Newslet?= =?iso-8859-1?q?ter?=

[<ma...@ph...>]

PEhUTUw+PEhFQUQ+DQo8TUVUQSBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250ZW50PSJ0ZXh0
L2h0bWw7IGNoYXJzZXQ9dW5pY29kZSI+DQo8TUVUQSBjb250ZW50PSJFbWFpbCBNYXJrZXRlciBN
ZXNzYWdlIEVkaXRvciIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElWIGNsYXNz
PU91dGxvb2tNZXNzYWdlSGVhZGVyIGxhbmc9ZW4tdXMgZGlyPWx0ciBhbGlnbj1sZWZ0PjwvRElW
Pg0KPERJVj48L0RJVj4NCjxNRVRBIGNvbnRlbnQ9IkhvdExpemFyZCBMdGQiIG5hbWU9YXV0aG9y
Pg0KPFRBQkxFIGNlbGxTcGFjaW5nPTAgY2VsbFBhZGRpbmc9MCB3aWR0aD02MDAgYWxpZ249Y2Vu
dGVyIGJvcmRlcj0wPg0KPFRCT0RZPg0KPFRSPg0KPFREPiZuYnNwOyA8L1REPjwvVFI+DQo8VFI+
DQo8VEQgaGVpZ2h0PTE2Nz4NCjxUQUJMRSBjZWxsU3BhY2luZz0wIGNlbGxQYWRkaW5nPTAgd2lk
dGg9NjAwIGFsaWduPWNlbnRlciBib3JkZXI9MD4NCjxUQk9EWT4NCjxUUj4NCjxURCB2QWxpZ249
Ym90dG9tPjxBIGhyZWY9Imh0dHA6Ly93d3cucGhkam9icy5jb20iPjxJTUcgaGVpZ2h0PTE1NiBz
cmM9Imh0dHA6Ly93d3cucGhkam9icy5jb20vbWVkaWEvdG9wYmFyX2xvZ28uanBnIiB3aWR0aD02
MTQgYm9yZGVyPTA+PC9BPjwvVEQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+PC9URD48L1RSPg0KPFRS
Pg0KPFREPg0KPFRBQkxFIGNlbGxTcGFjaW5nPTAgY2VsbFBhZGRpbmc9MCB3aWR0aD02MDAgYWxp
Z249Y2VudGVyIGJvcmRlcj0wPg0KPFRCT0RZPg0KPFRSPg0KPFREIGhlaWdodD0zMj4NCjxUQUJM
RSBjZWxsU3BhY2luZz0wIGNlbGxQYWRkaW5nPTAgd2lkdGg9MTgwIGFsaWduPWNlbnRlciBib3Jk
ZXI9MD4NCjxUQk9EWT4NCjxUUj4NCjxURD48SU1HIGhlaWdodD0xIGFsdD0iIiBzcmM9Imh0dHA6
Ly9ob3RzaG90LmhvdGxpemFyZC5uZXQvaW1hZ2VzL3N0YW5kYXJkdGVtcGxhdGVzL2hvdGxpemFy
ZDIwMDUvc3BhY2VyLmdpZiIgd2lkdGg9MSBib3JkZXI9MCBOT1NFTkQ9IjEiPjwvVEQ+PC9UUj4N
CjxUUj4NCjxURD4mbmJzcDs8L1REPjwvVFI+PC9UQk9EWT48L1RBQkxFPjwvVEQ+DQo8VEQgd2lk
dGg9MSByb3dTcGFuPTI+PElNRyBoZWlnaHQ9MSBhbHQ9IiIgc3JjPSJodHRwOi8vaG90c2hvdC5o
b3RsaXphcmQubmV0L2ltYWdlcy9zdGFuZGFyZHRlbXBsYXRlcy9ob3RsaXphcmQyMDA1L3NwYWNl
ci5naWYiIHdpZHRoPTEgYm9yZGVyPTAgTk9TRU5EPSIxIj48L1REPg0KPFREIHdpZHRoPTMwIGJn
Q29sb3I9IzhjYzYzZj4NCjxESVYgYWxpZ249bGVmdD48SU1HIGhlaWdodD0xIGFsdD0iIiBzcmM9
Imh0dHA6Ly9ob3RzaG90LmhvdGxpemFyZC5uZXQvY2dpLWJpbi9pbWFnZXMvc3BhY2VyLmdpZiIg
d2lkdGg9MSBib3JkZXI9MCBOT1NFTkQ9IjEiPjxGT05UIGZhY2U9dmVyZGFuYSBjb2xvcj0jMzc1
ZTZmIHNpemU9Mj48SU1HIGhlaWdodD0yMCBzcmM9Imh0dHA6Ly93d3cucGhkam9icy5jb20vbWVk
aWEvYXJyb3ctZ3JlZW4uZ2lmIiB3aWR0aD0yMT48L0ZPTlQ+PC9ESVY+PC9URD4NCjxURCB3aWR0
aD0zODkgYmdDb2xvcj0jOGNjNjNmPg0KPFAgYWxpZ249bGVmdD48Rk9OVCBmYWNlPVZlcmRhbmEg
Y29sb3I9I2ZmZmZmZiBzaXplPTI+PEI+VW5saW1pdGVkIEZyZWUgSm9iIFBvc3RpbmdzISA8L0I+
PC9GT05UPjwvUD48L1REPjwvVFI+DQo8VFI+DQo8VEQgdkFsaWduPXRvcCB3aWR0aD0yMDEgYmdD
b2xvcj0jZjRmMmVjIGhlaWdodD05MDU+DQo8VEFCTEUgY2VsbFNwYWNpbmc9NSB3aWR0aD0yMDAg
Ym9yZGVyPTA+DQo8VEJPRFk+DQo8VFI+DQo8VEQ+DQo8VEFCTEUgY2VsbFNwYWNpbmc9NiBjZWxs
UGFkZGluZz0wIHdpZHRoPTE4MCBib3JkZXI9MD4NCjxUQk9EWT4NCjxUUj4NCjxURD48U1BBTiBj
bGFzcz1zdHlsZTc+Jm5ic3A7PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMzNzVlNmYgc2l6ZT0y
PjxJTUcgaGVpZ2h0PTIwIHNyYz0iaHR0cDovL3d3dy5waGRqb2JzLmNvbS9tZWRpYS9hcnJvdy1n
cmVlbi5naWYiIHdpZHRoPTIxPiA8QSBocmVmPSJodHRwOi8vd3d3LnBoZGpvYnMuY29tL3NpZ25p
bi9lbXBsb3llcnMuYXNwIj5SZWNydWl0ZXJzPC9BPjwvRk9OVD48L1NQQU4+PC9URD48L1RSPg0K
PFRSPg0KPFREIGFsaWduPW1pZGRsZT48SU1HIGhlaWdodD0xIGFsdD0iIiBzcmM9Imh0dHA6Ly9o
b3RzaG90LmhvdGxpemFyZC5uZXQvaW1hZ2VzL3N0YW5kYXJkdGVtcGxhdGVzL2hvdGxpemFyZDIw
MDUvbG5hdl9kaXZpZGVyLmdpZiIgd2lkdGg9MTY3IGJvcmRlcj0wIE5PU0VORD0iMSI+PC9URD48
L1RSPg0KPFRSPg0KPFREPjxTUEFOIGNsYXNzPXN0eWxlNz4mbmJzcDs8SU1HIGhlaWdodD0yMCBz
cmM9Imh0dHA6Ly93d3cucGhkam9icy5jb20vbWVkaWEvYXJyb3ctb3JhbmdlLmdpZiIgd2lkdGg9
MjE+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMzNzVlNmYgc2l6ZT0yPiA8QSBocmVmPSJodHRw
Oi8vd3d3LnBoZGpvYnMuY29tL3NpZ25pbi9jYW5kaWRhdGVzLmFzcCI+Q2FuZGlkYXRlczwvQT48
L0ZPTlQ+PC9TUEFOPjwvVEQ+PC9UUj4NCjxUUj4NCjxURCBhbGlnbj1taWRkbGU+PElNRyBoZWln
aHQ9MSBhbHQ9IiIgc3JjPSJodHRwOi8vaG90c2hvdC5ob3RsaXphcmQubmV0L2ltYWdlcy9zdGFu
ZGFyZHRlbXBsYXRlcy9ob3RsaXphcmQyMDA1L2xuYXZfZGl2aWRlci5naWYiIHdpZHRoPTE2NyBi
b3JkZXI9MCBOT1NFTkQ9IjEiPjwvVEQ+PC9UUj4NCjxUUj4NCjxURD48U1BBTiBjbGFzcz1zdHls
ZTc+Jm5ic3A7PElNRyBoZWlnaHQ9MjAgc3JjPSJodHRwOi8vd3d3LnBoZGpvYnMuY29tL21lZGlh
L2Fycm93LWdyZXkuZ2lmIiB3aWR0aD0yMD48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9IzM3NWU2
ZiBzaXplPTI+IDxBIGhyZWY9Imh0dHA6Ly93d3cucGhkam9icy5jb20vc2VhcmNoLyI+Sm9iIFNl
YXJjaDwvQT4gPC9GT05UPjwvU1BBTj48L1REPjwvVFI+DQo8VFI+DQo8VEQgYWxpZ249bWlkZGxl
PjxJTUcgaGVpZ2h0PTEgYWx0PSIiIHNyYz0iaHR0cDovL2hvdHNob3QuaG90bGl6YXJkLm5ldC9p
bWFnZXMvc3RhbmRhcmR0ZW1wbGF0ZXMvaG90bGl6YXJkMjAwNS9sbmF2X2RpdmlkZXIuZ2lmIiB3
aWR0aD0xNjcgYm9yZGVyPTAgTk9TRU5EPSIxIj48L1REPjwvVFI+DQo8VFI+DQo8VEQgYWxpZ249
bWlkZGxlPjxJTUcgaGVpZ2h0PTEgYWx0PSIiIHNyYz0iaHR0cDovL2hvdHNob3QuaG90bGl6YXJk
Lm5ldC9pbWFnZXMvc3RhbmRhcmR0ZW1wbGF0ZXMvaG90bGl6YXJkMjAwNS9sbmF2X2RpdmlkZXIu
Z2lmIiB3aWR0aD0xNjcgYm9yZGVyPTAgTk9TRU5EPSIxIj48L1REPjwvVFI+PC9UQk9EWT48L1RB
QkxFPjwvVEQ+PC9UUj4NCjxUUj4NCjxURCB2QWxpZ249Y2VudGVyIGJnQ29sb3I9IzhjYzYzZj48
SU1HIGhlaWdodD0xIGFsdD0iIiBzcmM9Imh0dHA6Ly9ob3RzaG90LmhvdGxpemFyZC5uZXQvY2dp
LWJpbi9pbWFnZXMvc3BhY2VyLmdpZiIgd2lkdGg9MSBib3JkZXI9MCBOT1NFTkQ9IjEiPjxGT05U
IGZhY2U9dmVyZGFuYSBjb2xvcj0jMzc1ZTZmIHNpemU9Mj48SU1HIGhlaWdodD0yMCBzcmM9Imh0
dHA6Ly93d3cucGhkam9icy5jb20vbWVkaWEvYXJyb3ctZ3JlZW4uZ2lmIiB3aWR0aD0yMT48L0ZP
TlQ+IDxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jZmZmZmZmIHNpemU9Mj48Qj5SZWNpcHJvY2Fs
IExpbmsgPC9CPjwvRk9OVD48L1REPjwvVFI+DQo8VFI+DQo8VEQ+DQo8UD48Rk9OVCBmYWNlPXZl
cmRhbmEgY29sb3I9IzUzNTM1MyBzaXplPTE+UGhESm9icy5jb20gYXJlIGxvb2tpbmcgZm9yIHJl
Y2lwcm9jYWwgbGluayBwYXJ0bmVyc2hpcHMgd2l0aCBvdGhlciByZWxldmFudCBzaXRlcyB3aXRo
aW4gdGhlIFBoRCBjb21tdW5pdHkuIDxCUj48QlI+U2luY2UgMTk5NywgUGhEam9icy5jb20gaGFz
IGJlZW4gYXR0cmFjdGluZyBQaEQgdGFsZW50IHRvIG91ciBkZWRpY2F0ZWQgam9iIGJvYXJkLCB3
aXRoIG91ciBkYXRhYmFzZSBib2FzdGluZyAxMzAsMDAwKyBjYW5kaWRhdGVzIGFuZCBvdmVyIDYw
LDAwMCB1bmlxdWUgdmlzaXRvcnMgZWFjaCBtb250aCBmcm9tIGFyb3VuZCB0aGUgd29ybGQgPC9G
T05UPjwvUD4NCjxQPjxGT05UIGZhY2U9dmVyZGFuYSBjb2xvcj0jNTM1MzUzIHNpemU9MT5Zb3Vy
IGxpbmsgd2lsbCBiZSBkaXNwbGF5ZWQgb24gdGhlIGZvbGxvd2luZyBwYWdlIDxBIGhyZWY9Imh0
dHA6Ly93d3cucGhkam9icy5jb20vbGlua3MvIj5odHRwOi8vd3d3LnBoZGpvYnMuY29tL2xpbmtz
LzwvQT4sIHlvdXIgbGluayB3aWxsIGJlIGluY2x1ZGVkIHVuZGVyIHRoZSByZWxldmFudCBjYXRl
Z29yeSBmb3IgeW91ciBzaXRlLCBmb2xsb3dpbmcgd2VibWFzdGVyIGFwcHJvdmFsLjwvRk9OVD48
L1A+DQo8UD48Rk9OVCBmYWNlPXZlcmRhbmEgY29sb3I9IzUzNTM1MyBzaXplPTE+VG8gUGFydGlj
aXBhdGUgaW4gb3VyIHByb2dyYW0sIHBsZWFzZSBjb250YWN0IHVzIGF0IDxBIGhyZWY9Im1haWx0
bzppbmZvQHBoZGpvYnMuY29tP3N1YmplY3Q9UmVjaXByb2NhbCUyMExpbmslMjAiPmluZm9AcGhk
am9icy5jb20uPC9BPjwvRk9OVD48L1A+PC9URD48L1RSPg0KPFRSIGJnQ29sb3I9IzlmYTFhND4N
CjxURCBiZ0NvbG9yPSNmNGYyZWM+Jm5ic3A7PC9URD48L1RSPg0KPFRSIGJnQ29sb3I9IzlmYTFh
ND4NCjxURD48SU1HIGhlaWdodD0yMCBzcmM9Imh0dHA6Ly93d3cucGhkam9icy5jb20vbWVkaWEv
YXJyb3ctZ3JleS5naWYiIHdpZHRoPTIwPiA8Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9I2ZmZmZm
ZiBzaXplPTI+PEI+TGF0ZXN0IFN0YXRzIDwvQj48L0ZPTlQ+PC9URD48L1RSPg0KPFRSPg0KPFRE
Pg0KPFVMPg0KPExJPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jNTM1MzUzIHNpemU9MT5Kb2Ig
UG9zdGluZ3MgZ3JldyBieSAzNSUgaW4gU2VwdGVtYmVyPC9GT05UPiANCjxMST48Rk9OVCBmYWNl
PVZlcmRhbmEgY29sb3I9IzUzNTM1MyBzaXplPTE+VW5pcXVlIFZpc2l0b3JzIGZvciBTZXB0ZW1i
ZXIgdXAgMjAlIHRvIG92ZXIgNjAsMDAwIDwvRk9OVD4NCjxMST48Rk9OVCBmYWNlPVZlcmRhbmEg
Y29sb3I9IzUzNTM1MyBzaXplPTE+MTMwLDAwMCArIHJlZ2lzdGVyZWQgY2FuZGlkYXRlcyByZWNl
aXZlIG91ciBqb2IgYWxlcnRzPC9GT05UPjwvTEk+PC9VTD48L1REPjwvVFI+DQo8VFI+DQo8VEQg
dkFsaWduPWNlbnRlcj48SU1HIGhlaWdodD0xNDQgc3JjPSJodHRwOi8vd3d3LnBoZGpvYnMuY29t
L21lZGlhL2FkdmVydC5qcGciIHdpZHRoPTE4ND48L1REPjwvVFI+DQo8VFI+DQo8VEQ+Jm5ic3A7
PC9URD48L1RSPjwvVEJPRFk+PC9UQUJMRT4NCjxQPiZuYnNwOzwvUD48L1REPg0KPFREIHZBbGln
bj10b3AgY29sU3Bhbj0yPg0KPFRBQkxFIGNlbGxTcGFjaW5nPTYgY2VsbFBhZGRpbmc9MCB3aWR0
aD00MTkgYm9yZGVyPTA+DQo8VEJPRFk+DQo8VFI+DQo8VEQ+DQo8UD48Qj48Rk9OVCBmYWNlPVZl
cmRhbmEgY29sb3I9I2Y0N2EyMCBzaXplPTQ+UGhEam9icy5jb20gaGFzIFJlLWxhdW5jaGVkITwv
Rk9OVD48L0I+PC9QPg0KPFA+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSM1MzUzNTMgc2l6ZT0x
PldlIGFyZSBvZmZlcmluZyBhbiBleGNsdXNpdmUgYWR2ZXJ0aXNpbmcgcGFja2FnZSB0byBhbGwg
cmVjcnVpdGVycyBwbGFjaW5nIHZhY2FuY2llcyBvbiB0aGUgc2l0ZSBiZWZvcmUgMzB0aCBOb3Zl
bWJlciAyMDA2LjwvRk9OVD48L1A+DQo8UD48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9IzUzNTM1
MyBzaXplPTE+Tm8gQ2F0Y2gsIE5vIFBheW1lbnQsIEp1c3QgYSBzaW1wbGUgcmVnaXN0cmF0aW9u
IGdpdmluZyB5b3VyIGFkdmVydCBleHBvc3VyZSB0byBvdmVyIDEzMCwwMDAgUG9zdGdyYWR1YXRl
IGpvYiBzZWVrZXJzIDwvRk9OVD48L1A+DQo8UD48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9IzUz
NTM1MyBzaXplPTM+PEEgaHJlZj0iaHR0cDovL3d3dy5waGRqb2JzLmNvbS9zaWduaW4vZW1wbG95
ZXJzLmFzcCI+Q2xpY2sgSGVyZTwvQT4gVE9EQVkgdG8gdGFrZSBhZHZhbnRhZ2Ugb2YgdGhpcyBv
ZmZlciA8L0ZPTlQ+PC9QPg0KPFRBQkxFIGNlbGxTcGFjaW5nPTAgY2VsbFBhZGRpbmc9MCB3aWR0
aD00MDcgYmdDb2xvcj0jZjRmMmVjIGJvcmRlcj0wPg0KPFRCT0RZPg0KPFRSPg0KPFREIGJnQ29s
b3I9I2VlZWJlMz48SU1HIGhlaWdodD00IGFsdD0iIiBzcmM9Imh0dHA6Ly9ob3RzaG90LmhvdGxp
emFyZC5uZXQvY2dpLWJpbi9pbWFnZXMvc3BhY2VyLmdpZiIgd2lkdGg9MSBib3JkZXI9MCBOT1NF
TkQ9IjEiPjwvVEQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+DQo8VEFCTEUgY2VsbFNwYWNpbmc9MCBj
ZWxsUGFkZGluZz0wIHdpZHRoPTQwNyBiZ0NvbG9yPSNmNGYyZWMgYm9yZGVyPTA+DQo8VEJPRFk+
DQo8VFI+DQo8VEQgYWxpZ249cmlnaHQ+DQo8VEFCTEUgY2VsbFNwYWNpbmc9MCBjZWxsUGFkZGlu
Zz01IHdpZHRoPTQwNyBib3JkZXI9MD4NCjxUQk9EWT4NCjxUUj4NCjxURCB3aWR0aD0xIGJnQ29s
b3I9I2Y0N2EyMD4NCjxESVYgYWxpZ249bGVmdD48SU1HIGhlaWdodD0xIGFsdD0iIiBzcmM9Imh0
dHA6Ly9ob3RzaG90LmhvdGxpemFyZC5uZXQvY2dpLWJpbi9pbWFnZXMvc3BhY2VyLmdpZiIgd2lk
dGg9MSBib3JkZXI9MCBOT1NFTkQ9IjEiPjxJTUcgaGVpZ2h0PTIwIHNyYz0iaHR0cDovL3d3dy5w
aGRqb2JzLmNvbS9tZWRpYS9hcnJvdy1vcmFuZ2UuZ2lmIiB3aWR0aD0yMT48L0RJVj48L1REPg0K
PFREIGJnQ29sb3I9I2Y0N2EyMD4NCjxQIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT1WZXJkYW5hIGNv
bG9yPSNmZmZmZmYgc2l6ZT0yPjxCPkVsaXRlIENhcmVlcnMgRm9yIFBoRHMgLSA8QSBocmVmPSJo
dHRwOi8vd3d3LnBoZGpvYnMuY29tL3NpZ25pbi9jYW5kaWRhdGVzLmFzcCI+Q2xpY2sgSGVyZTwv
QT4gPC9CPjwvRk9OVD48L1A+PC9URD48L1RSPjwvVEJPRFk+PC9UQUJMRT48L1REPjwvVFI+DQo8
VFI+DQo8VEQgYmdDb2xvcj0jZmZmZmZmPjxJTUcgaGVpZ2h0PTEgYWx0PSIiIHNyYz0iaHR0cDov
L2hvdHNob3QuaG90bGl6YXJkLm5ldC9jZ2ktYmluL2ltYWdlcy9zcGFjZXIuZ2lmIiB3aWR0aD0x
IGJvcmRlcj0wIE5PU0VORD0iMSI+PC9URD48L1RSPg0KPFRSPg0KPFREPg0KPFRBQkxFIGNlbGxT
cGFjaW5nPTcgY2VsbFBhZGRpbmc9MCB3aWR0aD00MDcgYm9yZGVyPTA+DQo8VEJPRFk+DQo8VFI+
DQo8VEQ+PElNRyBoZWlnaHQ9MSBhbHQ9IiIgc3JjPSJodHRwOi8vaG90c2hvdC5ob3RsaXphcmQu
bmV0L2NnaS1iaW4vaW1hZ2VzL3NwYWNlci5naWYiIHdpZHRoPTEgYm9yZGVyPTAgTk9TRU5EPSIx
Ij48L1REPg0KPFREPg0KPFA+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSM1OTU5NTkgc2l6ZT0x
PjxCPkpvYiBUaXRsZTo8L0I+IDxBIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCIgaHJlZj0iaHR0
cDovL3d3dy5waGRqb2JzLmNvbS9zZWFyY2gvZGV0YWlscy5hc3A/Sm9iSUQ9NDQ0Ij5TZW5pb3Ig
UmVzZWFyY2hlciA/IE1hc3MgU3BlY3Ryb21ldHJ5PC9BPiA8QlI+PEI+Q29tcGFueTo8L0I+IFNj
aWVuY2UgUmVjcnVpdG1lbnQgR3JvdXAgTHRkPEJSPjxCPkxvY2F0aW9uOjwvQj4gQWxsIExvY2F0
aW9ucywgU291dGggV2VzdCBFbmdsYW5kLCBTb3V0aCBFYXN0IEVuZ2xhbmQsIExvbmRvbjwvRk9O
VD48L1A+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSM1OTU5NTkgc2l6ZT0xPg0KPFA+PEI+Sm9i
IFRpdGxlOjwvQj4gPEEgc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIiBocmVmPSJodHRwOi8vd3d3
LnBoZGpvYnMuY29tL3NlYXJjaC9kZXRhaWxzLmFzcD9Kb2JJRD00NDMiPlRlY2hub2xvZ3kgVHJh
bnNsYXRvcjwvQT4gPEJSPjxCPkNvbXBhbnk6PC9CPiBTbWl0aCBJbnN0aXR1dGU8QlI+PEI+TG9j
YXRpb246PC9CPiBBbGwgTG9jYXRpb25zIDwvUD4NCjxQPjxCPkpvYiBUaXRsZTo8L0I+IDxBIHN0
eWxlPSJGT05ULVdFSUdIVDogYm9sZCIgaHJlZj0iaHR0cDovL3d3dy5waGRqb2JzLmNvbS9zZWFy
Y2gvZGV0YWlscy5hc3A/Sm9iSUQ9NDQyIj5Qcm90ZWluIENoZW1pc3QvQmlvY2hlbWlzdDwvQT4g
PEJSPjxCPkNvbXBhbnk6PC9CPiBTY2llbmNlIFJlY3J1aXRtZW50IEdyb3VwIEx0ZDxCUj48Qj5M
b2NhdGlvbjo8L0I+IFNjb3RsYW5kIDwvUD4NCjxQPjxCPkpvYiBUaXRsZTo8L0I+IDxBIHN0eWxl
PSJGT05ULVdFSUdIVDogYm9sZCIgaHJlZj0iaHR0cDovL3d3dy5waGRqb2JzLmNvbS9zZWFyY2gv
ZGV0YWlscy5hc3A/Sm9iSUQ9NDM5Ij5TYWxlcyBEaXJlY3RvcjwvQT4gPEJSPjxCPkNvbXBhbnk6
PC9CPiBTQ0lFTlRFQyBDT05TVUxUSU5HIFBURSBMVEQ8QlI+PEI+TG9jYXRpb246PC9CPiBPdXRz
aWRlIEdyZWF0IEJyaXRhaW4gPC9QPg0KPFA+PEI+Sm9iIFRpdGxlOjwvQj4gPEEgc3R5bGU9IkZP
TlQtV0VJR0hUOiBib2xkIiBocmVmPSJodHRwOi8vd3d3LnBoZGpvYnMuY29tL3NlYXJjaC9kZXRh
aWxzLmFzcD9Kb2JJRD00MzgiPlB1Ymxpc2hpbmcgRGlyZWN0b3IgKEtvcmVhKTwvQT4gPEJSPjxC
PkNvbXBhbnk6PC9CPiBTQ0lFTlRFQyBDT05TVUxUSU5HIFBURSBMVEQ8QlI+PEI+TG9jYXRpb246
PC9CPiBPdXRzaWRlIEdyZWF0IEJyaXRhaW4gPC9QPjwvRk9OVD4NCjxQPjxGT05UIGZhY2U9VmVy
ZGFuYSBjb2xvcj0jNTk1OTU5IHNpemU9MT5Gb3IgYSBtb3JlIGVuaGFuY2VkIHNlYXJjaCBjbGlj
ayA8QSBocmVmPSJodHRwOi8vd3d3LnBoZGpvYnMuY29tL3NlYXJjaC8iPmhlcmUuPC9BPjxCUj48
L0ZPTlQ+PC9QPjxGT05UIGZhY2U9dmVyZGFuYSBjb2xvcj0jN2M5NmExIHNpemU9MT48L0ZPTlQ+
PC9URD48L1RSPjwvVEJPRFk+PC9UQUJMRT48L1REPjwvVFI+DQo8VFI+DQo8VEQgYmdDb2xvcj0j
ZWVlYmUzPjxJTUcgaGVpZ2h0PTQgYWx0PSIiIHNyYz0iaHR0cDovL2hvdHNob3QuaG90bGl6YXJk
Lm5ldC9jZ2ktYmluL2ltYWdlcy9zcGFjZXIuZ2lmIiB3aWR0aD0xIGJvcmRlcj0wIE5PU0VORD0i
MSI+PC9URD48L1RSPjwvVEJPRFk+PC9UQUJMRT4NCjxQPjwvUD4NCjxUQUJMRSBjZWxsU3BhY2lu
Zz0wIGNlbGxQYWRkaW5nPTAgd2lkdGg9NDA3IGJnQ29sb3I9I2Y0ZjJlYyBib3JkZXI9MD4NCjxU
Qk9EWT4NCjxUUj4NCjxURCBhbGlnbj1yaWdodD4NCjxUQUJMRSBjZWxsU3BhY2luZz0wIGNlbGxQ
YWRkaW5nPTUgd2lkdGg9NDA3IGJvcmRlcj0wPg0KPFRCT0RZPg0KPFRSIGJnQ29sb3I9IzlmYTFh
ND4NCjxURCB3aWR0aD0xPg0KPERJViBhbGlnbj1sZWZ0PjxJTUcgaGVpZ2h0PTIwIHNyYz0iaHR0
cDovL3d3dy5waGRqb2JzLmNvbS9tZWRpYS9hcnJvdy1ncmV5LmdpZiIgd2lkdGg9MjA+PC9ESVY+
PC9URD4NCjxURD4NCjxQIGNsYXNzPXN0eWxlNCBhbGlnbj1sZWZ0PjxGT05UIGZhY2U9VmVyZGFu
YSBjb2xvcj0jZmZmZmZmPlRlc3RpbW9uaWFsczwvRk9OVD48L1A+PC9URD48L1RSPjwvVEJPRFk+
PC9UQUJMRT48L1REPjwvVFI+DQo8VFI+DQo8VEQgYmdDb2xvcj0jZmZmZmZmPjxJTUcgaGVpZ2h0
PTEgYWx0PSIiIHNyYz0iaHR0cDovL2hvdHNob3QuaG90bGl6YXJkLm5ldC9jZ2ktYmluL2ltYWdl
cy9zcGFjZXIuZ2lmIiB3aWR0aD0xIGJvcmRlcj0wIE5PU0VORD0iMSI+PC9URD48L1RSPg0KPFRS
Pg0KPFREPg0KPFRBQkxFIGNlbGxTcGFjaW5nPTcgY2VsbFBhZGRpbmc9MCB3aWR0aD00MDcgYm9y
ZGVyPTA+DQo8VEJPRFk+DQo8VFI+DQo8VEQgd2lkdGg9MTQxPjxJTUcgaGVpZ2h0PTE0MSBzcmM9
Imh0dHA6Ly93d3cucGhkam9icy5jb20vbWVkaWEvc3VjY2Vzcy5qcGciIHdpZHRoPTE0MT48L1RE
Pg0KPFREPg0KPERJViBhbGlnbj1jZW50ZXI+DQo8UD48Qj48Rk9OVCBmYWNlPVZlcmRhbmEgY29s
b3I9IzU5NTk1OSBzaXplPTE+IkkgZm91bmQgaXQgYSBwbGVhc2FudCwgcGFpbmxlc3MgZXhwZXJp
ZW5jZS4mbmJzcDsgV2FzIGFsc28gaW1wcmVzc2VkIHdpdGggdGhlIHF1aWNrLCBlZmZpY2llbnQg
cmVzcG9uc2UgYW5kIHNlcnZpY2UuPEJSPk9mIGNvdXJzZSB0aGUgaWNpbmcgb24gdGhlIGNha2Ug
d2FzIHRoYXQgdGhlcmUgd2VyZSBubyBoaWRkZW4gY2hhcmdlcyEgQnJpbGxpYW50ISI8L0ZPTlQ+
PC9CPjwvUD4NCjxQPjxCPjxGT05UIGZhY2U9VmVyZGFuYSBjb2xvcj0jNTk1OTU5IHNpemU9MT48
QlI+IkkgcmVnaXN0ZXJlZCB3aXRoIFBoRGpvYnMuY29tIGFuZCBoYWQgbXkgam9iIG9mZmVyIHdp
dGhpbiB0aHJlZSB3ZWVrcy48L1NQQU4+PFNQQU4gY2xhc3M9c3R5bGUyPiI8L1NQQU4+PC9QPjwv
RElWPjwvRk9OVD48L0I+PC9URD48L1RSPg0KPFRSPg0KPFREIGNvbFNwYW49Mj4NCjxQPiZuYnNw
OzwvUD48L1REPjwvVFI+DQo8VFI+DQo8VEQgY29sU3Bhbj0yPg0KPFAgY2xhc3M9c3R5bGU1PjxG
T05UIGZhY2U9dmVyZGFuYSBjb2xvcj0jNTM1MzUzIHNpemU9MT4qPEEgaHJlZj0iaHR0cDovL3d3
dy5waGRqb2JzLmNvbS90ZXJtcy8iPlRlcm1zIGFuZCBjb25kaXRpb25zPC9BPiBhcHBseTxCUj5U
aGlzIGVtYWlsIHdhcyBzZW50IHRvIHlvdSBieSBQaGRqb2JzIEx0ZC4gPEJSPlByZXNzIGhlcmUg
dG8gPEEgaHJlZj0ibWFpbHRvOiUyMHVuc3Vic2NyaWJlQHBoZGpvYnMuY29tP3N1YmplY3Q9dW5z
dWJzY3JpYmUiPnVuc3Vic2NyaWJlPC9BPiA8QlI+UGhEam9icyBMaW1pdGVkPEJSPlRlbDogMDg0
NSAzMzEgNjAxNi8xODxCUj48QSBocmVmPSJtYWlsdG86aW5mb0BwaGRqb2JzLmNvbSI+aW5mb0Bw
aGRqb2JzLmNvbTwvQT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDs8QlI+PEEgaHJlZj0iaHR0cDovL3d3dy5waGRqb2JzLmNvbSI+aHR0
cDovL3d3dy5waGRqb2JzLmNvbTwvQT48L0ZPTlQ+IDwvUD4NCjxQPjwvUD48L1REPjwvVFI+PC9U
Qk9EWT48L1RBQkxFPjwvVEQ+PC9UUj4NCjxUUj4NCjxURCBiZ0NvbG9yPSNlZWViZTM+PElNRyBo
ZWlnaHQ9NCBhbHQ9IiIgc3JjPSJodHRwOi8vaG90c2hvdC5ob3RsaXphcmQubmV0L2NnaS1iaW4v
aW1hZ2VzL3NwYWNlci5naWYiIHdpZHRoPTEgYm9yZGVyPTAgTk9TRU5EPSIxIj48L1REPjwvVFI+
PC9UQk9EWT48L1RBQkxFPg0KPFA+PC9QPjwvVEQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+PC9URD48
L1RSPjwvVEJPRFk+PC9UQUJMRT48L1REPjwvVFI+DQo8VFI+DQo8VEQ+PElNRyBoZWlnaHQ9NCBh
bHQ9IiIgc3JjPSJodHRwOi8vaG90c2hvdC5ob3RsaXphcmQubmV0L2ltYWdlcy9zdGFuZGFyZHRl
bXBsYXRlcy9ob3RsaXphcmQyMDA1L3NwYWNlci5naWYiIHdpZHRoPTEgYm9yZGVyPTAgTk9TRU5E
PSIxIj48L1REPjwvVFI+DQo8VFI+DQo8VEQgYmFja2dyb3VuZD1odHRwOi8vaG90c2hvdC5ob3Rs
aXphcmQubmV0L2ltYWdlcy9zdGFuZGFyZHRlbXBsYXRlcy9ob3RsaXphcmQyMDA1L2JvdHRvbWJh
ci5naWY+PElNRyBoZWlnaHQ9OCBhbHQ9IiIgc3JjPSJodHRwOi8vaG90c2hvdC5ob3RsaXphcmQu
bmV0L2ltYWdlcy9zdGFuZGFyZHRlbXBsYXRlcy9ob3RsaXphcmQyMDA1L3NwYWNlci5naWYiIHdp
ZHRoPTEgYm9yZGVyPTAgTk9TRU5EPSIxIj48L1REPjwvVFI+DQo8VFI+DQo8VEQ+DQo8VEFCTEUg
Y2VsbFNwYWNpbmc9NCBjZWxsUGFkZGluZz0wIHdpZHRoPTYwMCBib3JkZXI9MD4NCjxUQk9EWT4N
CjxUUj4NCjxURD4mbmJzcDs8L1REPjwvVFI+PC9UQk9EWT48L1RBQkxFPjwvVEQ+PC9UUj4NCjxU
Uj4NCjxURD48SU1HIGhlaWdodD00IGFsdD0iIiBzcmM9Imh0dHA6Ly9ob3RzaG90LmhvdGxpemFy
ZC5uZXQvaW1hZ2VzL3N0YW5kYXJkdGVtcGxhdGVzL2hvdGxpemFyZDIwMDUvc3BhY2VyLmdpZiIg
d2lkdGg9MSBib3JkZXI9MCBOT1NFTkQ9IjEiPjwvVEQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+PC9C
T0RZPjwvSFRNTD4=

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

[Stefan v. d. W. <st...@su...>]

I've summarised this thread at

http://www.scipy.org/NegativeSquareRoot

Feel free to make adjustments, in case I missed something.

Regards
Stefan

[Numpy-discussion] Casting

[Cristian C. <cri...@gm...>]

Hello list,
  I got some old code that uses Scientific and Numeric. Recently, these two
packages were updated to the latest versions together with python and my
code started failing. The first major problem I have is when downcasting.
Code that used to work now fails because the array cannot be safely cast
anymore to the required type. If anyone could help me please and direct me
to some documentation about when this change happened (version), why it
happened, is there any other solution but using astype, can numpy help me in
anyway in this situation, because I got really lost ...

Thank you in advance,
Cristian

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

[Mark B. <ma...@gm...>]

My vote is for consistency in numpy.
But it is unclear what consistency is.

What is truly confusing for newbie Python users (and a source for error even
after 5 years of Python programming) is that

>>> 2/3
0

In that respect, I would think

>>> numpy.sqrt(2)

should give 1, but it gives 1.4142135623730951

So numpy does typechecking anyway (it gets an integer and makes it a float).

If that is the consistent behavior, then by all means

>>> sqrt(-1)

should return 1j.

Wouldn't that be the consistent thing to do????

Mark

Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?

[David G. <Dav...@no...>]

Travis Oliphant wrote:
> David Goldsmith wrote:
>   
>>>   
>>>     
>>>       
>> I don't use scipy (and don't want to because of the overhead) but it 
>> sounds like I should because if I'm taking the square root of a variable 
>> whose value at run time happens to be real but less than zero, I *want* 
>> the language I'm using to return an imaginary; in other words, it's not 
>> the scipy behavior which "scares" me, its the numpy (which I do/have 
>> been using) behavior. 
>>     
>
> O.K.  Well the functions you want are in numpy.lib.scimath.  I should 
> have directed you there.  You actually don't need scipy installed at 
> all.  Just import sqrt from numpy.lib.scimath.  I'm sorry I 
> misunderstood the issue.
>   
Got it.  And if I understand correctly, the import order you specify in 
the little mynumpy example you included in your latest response to 
Fernando will result in any "overlap" between numpy and 
numpy.lib.scimath to call the latter's version of things rather than the 
former's, yes?

DG
> -Travis
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Num...@li...
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>