Menu
▾
▴
numpy-discussion
|
From: David G. <Dav...@no...> - 2006-10-12 06:38:08
|
Stefan van der Walt wrote: >> This is one reason that NumPy by itself is not a MATLAB >> replacement.=20 >> =20 > Intuitive usage is hopefully not a MATLAB-only feature. > =20 Here, here! (Or is it Hear, hear! I don't think I've ever seen it wr= itten out before. :-) ) > I'll shut up now :) But why? To my mind, you're making a lot more sense than Travis. DG > Cheers > St=E9fan > > -------------------------------------------------------------------= ------ > Using Tomcat but need to do more? Need to support web services, sec= urity? > 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 G= eronimo > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057= &dat=3D121642 > _______________________________________________ > Numpy-discussion mailing list > Num...@li... > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > =20 |
|
From: David G. <Dav...@no...> - 2006-10-12 07:13:23
|
Travis Oliphant wrote: > David Goldsmith wrote: > >> Travis Oliphant wrote: >> >> >>> pe...@ce... wrote: >>> >>> >>> >>> >>>> Could sqrt(-1) made to return 1j again? >>>> >>>> >>>> >>>> >>> Not in NumPy. But, in scipy it could. >>> >>> >>> >>> >> Ohmigod!!! You are definitely going to scare away many, many potential >> users - if I wasn't obliged to use open source at work, you'd be scaring >> me away. >> > Why in the world does it scare you away. This makes no sense to me. > If you don't like the scipy version don't use it. NumPy and SciPy are > not the same thing. > 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. DG |
|
From: Travis O. <oli...@ie...> - 2006-10-12 07:40:30
|
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. -Travis |
|
From: A. M. A. <per...@gm...> - 2006-10-12 16:07:14
|
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 |
|
From: David G. <Dav...@no...> - 2006-10-12 07:19:34
|
Travis Oliphant wrote: > David Goldsmith wrote: > >> Travis Oliphant wrote: >> >> >>> What could be simpler? ;-) >>> >>> >> Having sqrt(-1) return 1j (without having to remember that in order to >> get this, you have to write sqrt(-1+0j) instead). >> >> >> > That's exactly what scipy.sqrt(-1) does. That was my point. > But I don't want to have to use scipy (which so far I haven't needed for any other reason) just to get this one behavior. But my personal preferences aside, I say again: if numpy doesn't behave this way, you *will* be "scaring" away many potential users. If you can live with that, so be it. DG 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 > |
|
From: David G. <Dav...@no...> - 2006-10-12 07:23:52
|
(Very) well said, Fernando. Thanks!
DG
Fernando Perez wrote:
> On 10/12/06, Travis Oliphant <oli...@ie...> wrote:
>
>
>> Why in the world does it scare you away. This makes no sense to me.
>> If you don't like the scipy version don't use it. NumPy and SciPy are
>> not the same thing.
>>
>
> I'd like to pitch in (again) on this issue, but I'll try to make sure
> that it's clear that I'm NOT arguing about sqrt() in particular, one
> way or another.
>
> It's perfectly clear that numpy != scipy to all of us. And yet, I
> think it is equally clear that the two are /very/ tightly related.
> Scipy builds on top of numpy and it directly exposes a LOT of the
> numpy API as scipy functions:
>
> In [21]: import numpy as n, scipy as s
>
> In [22]: common_names = set(dir(n)) & set(dir(s))
>
> In [23]: [getattr(n,x) is getattr(s,x) for x in common_names ].count(True)
> Out[23]: 450
>
> In [24]: len(common_names)
> Out[24]: 462
>
> That's 450 objects from numpy which are directly exposed in Scipy,
> while only 12 names are in both top-level namespaces and yet are
> different objects. Put another way, scipy is a direct wrap of 97% of
> the numpy top-level namespace. While /we/ know they are distinct
> entities, to the casual user a 97% match looks pretty close to being
> the same, especially when the non-identical things are all
> non-numerical:
>
> In [27]: [x for x in common_names if getattr(n,x) is not getattr(s,x)]
> Out[27]:
> ['pkgload',
> 'version',
> '__config__',
> '__file__',
> '__all__',
> '__doc__',
> 'show_config',
> '__version__',
> '__path__',
> '__name__',
> 'info',
> 'test']
>
> In [32]: n.__version__,s.__version__
> Out[32]: ('1.0.dev3306', '0.5.2.dev2252')
>
> Basically, at least for these versions, the top-level API of scipy is
> a strict superset of the numpy one for all practical purposes.
>
> I think it's fair to say that if we start sprinkling special cases
> where certain objects happen to have the same name but produce
> different results for the same inputs, confusion will arise.
>
> Please note that I see a valid reason for scipy.foo != numpy.foo when
> the scipy version uses code with extra features, is faster, has
> additional options, etc. But as I said in a previous message, I think
> that /for the same input/, we should really try to satisfy that
>
> numpy.foo(x) == scipy.foo(x) (which is NOT the same as 'numpy.foo is scipy.foo')
>
> within reason. Obviously the scipy version may succeed where the
> numpy one fails due to better algorithms, or be faster, etc. I'm
> talking about a general principle here.
>
> I doubt I'll be able to state my point with any more clarity, so I'll
> stop now. But I really believe that this particular aspect of
> consistency between numpy and scipy is a /very/ important one for its
> adoption in wider communities.
>
> Best,
>
> f
>
> -------------------------------------------------------------------------
> 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
>
|
|
From: Stefan v. d. W. <st...@su...> - 2006-10-12 09:32:16
|
I've summarised this thread at http://www.scipy.org/NegativeSquareRoot Feel free to make adjustments, in case I missed something. Regards Stefan |
|
From: Alan G I. <ai...@am...> - 2006-10-12 14:12:21
|
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) |
|
From: Greg W. <gre...@gm...> - 2006-10-12 14:54:25
|
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 > |
|
From: Greg W. <gre...@gm...> - 2006-10-12 15:19:13
|
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
|
|
From: David G. <Dav...@no...> - 2006-10-12 16:25:27
|
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 > |
|
From: Christopher B. <Chr...@no...> - 2006-10-12 17:49:33
|
As someone on this list (sorry to quick with the delete button) said:
"numpy is closer to the metal than MATLAB"
MATLAB aside, numpy is somewhat "close to the metal". I think this is
clearly part of its design philosophy, and also something I personally
like about out.
Getting back to MATLAB (at least version 4, the last one I used
regularly) -- everything in MATLAB is a matrix of double precision
Floating points. (or complex - that does get weird!). This makes things
simpler for a lot of use, but restricts the power and flexibility
substantially.
Everything in numpy is an array of arbitrary shape and many possible
data types -- this is more to think about, but give you a lot of power
and flexibility. In any case, that is what numpy is. Period.
Given that, arrays of different types behave differently -- that's
something you'd darn well better understand pretty soon in your numpy
career:
>>> a = N.array((1,2,3), dtype=N.uint8)
>>> a *= 200
>>> a
array([200, 144, 88], dtype=uint8)
Oh my gosh! 2 * 200 isn't 144! what happened?
This isn't any different than sqrt(-1) resulting in NaN or an error. In
fact, there are all sorts of places where upcasting is not happening
automagically -- in fact, I think that's become more consistent in the
new numpy. So, in numpy you need to choose the datatype appropriate for
your problem at hand. I know I always know whether I want to work in the
complex plane or not.
Another change recently made is to make doubles the default in more
places -- I like that change.
So, given the entire philosophy and current status of how numpy works,
the ONLY question that is legitimate here is:
Should the "default" datatype be complex or double? I vote double.
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.
> sqrt(a, dtype=complex).
I like this OK, and isn't is similar to the dtype argument in the
accumulating methods? (sum, etc.). However, it's probably not worth the
C-api change -- is it that different than calling:
sqrt(a.astype(complex)) ?
As for scipy, I heartily agree that scipy should be a superset of numpy,
and NOT change the behavior of numpy functions and methods. We're taking
the opportunity at this point for numpy to break backward compatibility
with Numeric/numarray -- this is probably the best time to do the same
for scipy.
couldn't we at least introduce new names?
numpy.scimath.csqrt()
for instance?
-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
Chr...@no...
|
|
From: Sebastian H. <ha...@ms...> - 2006-10-12 18:46:01
|
Hi, On Thursday 12 October 2006 10:49, Christopher Barker wrote: > As someone on this list (sorry to quick with the delete button) said: <snip> I think I might agree with everything (!) you that - very well written . > 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. > > > > sqrt(a, dtype=complex). > > I like this OK, and isn't is similar to the dtype argument in the > accumulating methods? (sum, etc.). However, it's probably not worth the > C-api change -- is it that different than calling: > > sqrt(a.astype(complex)) ? > It is very late in the game - obvious ! (one week before the announced final release). But I think adding the dtype argument to ufuncs would be a very useful addition !! It is very nice to look at ! And it saves (temporary) memory and should be noticeably faster than "sqrt(a.astype(complex))". This dtype addition might address many of the issues I have raised before on this list. Travis, be courageous and change the C-API one last time before putting it in stone for 1.0 final !!! > As for scipy, I heartily agree that scipy should be a superset of numpy, > and NOT change the behavior of numpy functions and methods. We're taking > the opportunity at this point for numpy to break backward compatibility > with Numeric/numarray -- this is probably the best time to do the same > for scipy. > > couldn't we at least introduce new names? > > numpy.scimath.csqrt() > > for instance? > > -Chris It has to be very well documented what the 12 functions (the last 3%) are were scipy and numpy differ. --- if at all possible I would prefer a name change like csqrt (or better sqrtc - I always like seen things together when sorted alphabetically ;-) ) [by the way: I like sqrt(-1) == nan just fine] Thanks for the great work. - Sebastian |
|
From: Paul D. <pfd...@gm...> - 2006-10-12 18:50:16
|
Historical note. When Cleve Moler first created 'matlab' as a tool for teaching at the University of New Mexico, all numbers were complex. And, in fact, there was a limit of 10,000 numbers. There was a fixed array where these 10,000 numbers were stored. I got pretty excited about his project and wanted to use it to get eigenvalues etc. for matrices of interest from our codes. But I had a Cray 1 with an entire megaword of memory and my matrices wouldn't fit. So I set out to hack the code to add a memory manager so that we could use the entire memory. This was a big success. Then I decided it was sad that I had to write the matrices out of the code onto a disk and then read them into matlab, so I got the idea of making something similar as the front end of the code, only with data types (because I hated only being able to use half my Cray since my data was real, and our codes were often memory bound) and a full programming language like Fortran with array syntax for speed. This idea resulted in Basis (basis.llnl.gov). My interest in Python (and hence numpy) evolved from that as OOP arrived. |
|
From: David G. <Dav...@no...> - 2006-10-13 01:34:44
|
I find that acceptable for my purposes, but is there some way we can minimize the "surprise(s)" for newbies? (I know some suggestions have been put forward in this thread, but I don't know enough to cast a vote one way or another for any of those, just a vote for "please do it".) And, in closing, I too would like to: thank you very much for all your work - despite my "emotional outburst," I am generally very happy using numpy and regard it as an excellent product. DG Travis Oliphant wrote: > David Goldsmith wrote: > > >> 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? >> >> >> > > Right. The last import will be used for any common-names (variables get > re-bound to the new functions...) > > -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 > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X