Re: [Numpy-discussion] Should numpy.sqrt(-1) return 1j rather than nan?
Hi, On Thursday 12 October 2006 10:49, Christopher Barker wrote: > As someone on this list (sorry to quick with the delete button) said: 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 - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Hello and my first patch
Travis Oliphant wrote: > Greg Willden wrote: > >> Hello All, >> I introduced myself on the Scipy list and I have a feeling that most >> of the subscribers here are also on Scipy-devel. Anyway I just >> submitted my first patch to numpy (ticket #316). I added the >> blackman-harris, Nuttall and Flat Top windowing functions and added >> "See also" sections to the docstrings for all the window functions. > > Great contribution. Thanks a bunch. I think this will probably go into > the scipy package, though. There is already a lot of windows available > in the scipy.signal.window function. > > The window functions that are in NumPy are there only for historical > purposes only (i.e. compatibility with old MLab). > > On the other hand, the other thought to consider is that since we have > window functions in NumPy already. Let's just move them all from > scipy.signal into NumPy. If scipy is going to be installable as separate sub-packages maybe all window functions can be moved to scipy ;-) In other words, if the ones in numpy are there only for "historical reasons" maybe they should be cleaned out before the 1.0 release. All arguments seem similar to ndimage (which was is numarray and is now in scipy) -Sebastian > > -Travis > > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ > Numpy-discussion mailing list > Numpy-discussion@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/numpy-discussion - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] OSX 10.4 vs 10.3 - long double dynlib problem
Hi, I just compiled CVS numpy on OSX 10.4 (tiger). Runs fine. I was surprised when I tried to run the same mode on 10.3 (panther?) and got a importError (dyld:...) related to missing acoshl (long double) functions: ImportError: Failure linking new module: : dyld: /Library/Frameworks/Python.framework/Versions/2.4/Resources/Python.app/Contents/MacOS/Python Undefined symbols: /Volumes/haase/PrMacNPPC/numpy/core/umath.so undefined reference to _acoshl$LDBL128 expected to be defined in /usr/lib/libmx.A.dylib /Volumes/haase/PrMacNPPC/numpy/core/umath.so undefined reference to _acosl$LDBL128 expected to be defined in /usr/lib/libmx.A.dylib /Volumes/haase/PrMacNPPC/numpy/core/umath.so undefined reference to _asinhl$LDBL128 expected to be After asking around in my lab I was told that "long double" might pose a problem when going backwards from 10.4 to 10.3. (I used gfortran gcc 4.x) Can I tell setup.py to skip "long double" support ? Thanks, Sebastian Haase - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Problems with Numexpr and disco ntiguous arrays
On Wednesday 04 October 2006 10:13, Tim Hochberg wrote:
> Sebastian Haase wrote:
> > Quick question hopefully somewhat related to this:
> > Does numexpr fully support float32 arrays ?
>
> I don't recall. At one point there was a tentative plan to support
> float32 by casting them a block at a time to float64, operating on them
> and them casting them back. That's to limit the number of bytecodes that
> we need to support and keep the switch statement at a manageable size.
> However, it doesn't look like that ever got implemented, so the answer
> is probably no.
>
> -tim
Does that mean its considered "impratical" to ever add native float32
support ? Is the switch-statement you mention written by hand or is that
automatically generated ?
-Sebastian
>
> > -Sebastian
> >
> > On Wednesday 04 October 2006 09:32, Tim Hochberg wrote:
> >> Ivan Vilata i Balaguer wrote:
> >>> It seemed that discontiguous arrays worked OK in Numexpr since r1977 or
> >>> so, but I have come across some alignment or striding problems which
> >>> can be seen with the following code::
> >>>
> >>> import numpy
> >>> import numexpr
> >>>
> >>> array_length = 10
> >>> array_descr = [('c1', numpy.int32), ('c2', numpy.uint16)]
> >>>
> >>> array = numpy.empty((array_length,), dtype=array_descr)
> >>> for i in xrange(array_length):
> >>> array['c1'][i] = i
> >>> array['c2'][i] = 0x
> >>>
> >>> print numexpr.evaluate('c1', {'c1': array['c1']})
> >>> print numexpr.evaluate('c1', {'c1': array['c1'].copy()})
> >>>
> >>> Im my computer, Pentium IV with NumPy 1.0rc1 and Numexpr r2239
> >>> (unmodified) this gives the following result::
> >>>
> >>> [ 0 109226 -1431699456 2 240298
> >>> -1431699456 4 371370 8 633514]
> >>> [0 1 2 3 4 5 6 7 8 9]
> >>>
> >>> The test works right when ``evaluate()`` is used with 'c2' instead of
> >>> 'c1', and also when 'c2' also measures 32 bits and fields are aligned.
> >>> Maybe the ``memsteps`` value is not getting used somewhere. Any ideas
> >>> on this?
> >>
> >> I suspect that there are some assumptions that the element separation
> >> is an integral multiple of the element size. I certainly didn't have
> >> record arrays in mind when I was working on the striding stuff, so it
> >> wouldn't surprise me. This should be fixed: preferably to do the right
> >> thing and at a minimum to cleanly raise an exception rather than
> >> spitting out garbage. I don't know that I'll have time to mess with it
> >> soon though.
> >>
> >> -tim
> >>
> >>
> >>
> >>- Take Surveys. Earn Cash. Influence the Future of IT
> >> Join SourceForge.net's Techsay panel and you'll get the chance to share
> >> your opinions on IT & business topics through brief surveys -- and earn
> >> cash
> >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
> >>V ___
> >> Numpy-discussion mailing list
> >> Numpy-discussion@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> >
> > -
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> > your opinions on IT & business topics through brief surveys -- and earn
> > cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > ___
> > Numpy-discussion mailing list
> > Numpy-discussion@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
> -
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your opinions on IT & business topics through brief surveys -- and earn
> cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> ___
> Numpy-discussion mailing list
> Numpy-discussion@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Problems with Numexpr and discontiguous arrays
Quick question hopefully somewhat related to this:
Does numexpr fully support float32 arrays ?
-Sebastian
On Wednesday 04 October 2006 09:32, Tim Hochberg wrote:
> Ivan Vilata i Balaguer wrote:
> > It seemed that discontiguous arrays worked OK in Numexpr since r1977 or
> > so, but I have come across some alignment or striding problems which can
> > be seen with the following code::
> >
> > import numpy
> > import numexpr
> >
> > array_length = 10
> > array_descr = [('c1', numpy.int32), ('c2', numpy.uint16)]
> >
> > array = numpy.empty((array_length,), dtype=array_descr)
> > for i in xrange(array_length):
> > array['c1'][i] = i
> > array['c2'][i] = 0x
> >
> > print numexpr.evaluate('c1', {'c1': array['c1']})
> > print numexpr.evaluate('c1', {'c1': array['c1'].copy()})
> >
> > Im my computer, Pentium IV with NumPy 1.0rc1 and Numexpr r2239
> > (unmodified) this gives the following result::
> >
> > [ 0 109226 -1431699456 2 240298 -1431699456
> >4 371370 8 633514]
> > [0 1 2 3 4 5 6 7 8 9]
> >
> > The test works right when ``evaluate()`` is used with 'c2' instead of
> > 'c1', and also when 'c2' also measures 32 bits and fields are aligned.
> > Maybe the ``memsteps`` value is not getting used somewhere. Any ideas
> > on this?
>
> I suspect that there are some assumptions that the element separation
> is an integral multiple of the element size. I certainly didn't have
> record arrays in mind when I was working on the striding stuff, so it
> wouldn't surprise me. This should be fixed: preferably to do the right
> thing and at a minimum to cleanly raise an exception rather than
> spitting out garbage. I don't know that I'll have time to mess with it
> soon though.
>
> -tim
>
>
> -
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your opinions on IT & business topics through brief surveys -- and earn
> cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> ___
> Numpy-discussion mailing list
> Numpy-discussion@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Fastest way of distinguish a numpy scalar of a python scalar?
Hi,
a noticed the underscore in "numpy.string_" ...
I thought the underscores were removed in favour of handling the
"from numpy import *" separately via the __all__ variable.
Is this done only for *some* members of numpy ?
(sorry for hijacking your thread ...)
-Sebastian Haase
On Tuesday 03 October 2006 09:55, Francesc Altet wrote:
> Hi,
>
> I thought that numpy.isscalar was a good way of distinguising a numpy
> scalar
>
> from a python scalar, but it seems not:
> >>> numpy.isscalar(numpy.string_('3'))
>
> True
>
> >>> numpy.isscalar('3')
>
> True
>
> Is there an easy (and fast, if possible) way to check whether an object is
> a numpy scalar or a python one?
>
> Thanks,
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] should I replace asarray with asanyarray in my code ?
Hi, This is a vaguely formulated question ... When I work with memmap'ed files/arrays I have a derived class that adds special attributes to the array class (referring to the MRC image file format used in medical / microscopy imaging) What are the pros and cons for asarray() vs. asanyarray() One obvious con for asanyarray is that its longer and asarray is what I have been using for the last few years ;-) Thanks, Sebastian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Rationale for atleast_3d
On Friday 22 September 2006 12:57, Travis Oliphant wrote: > Bill Baxter wrote: > >26 weeks, 4 days, 2 hours and 9 minutes ago, Zdeněk Hurák asked why > >atleast_3d acts the way it does: > >http://article.gmane.org/gmane.comp.python.numeric.general/4382/match=atle > >ast+3d > > > >He doesn't seem to have gotten any answers. And now I'm wondering the > >same thing. Anyone have any idea? > > This function came from scipy and was written by somebody at Enthought. > I was hoping they would respond. The behavior of atleast_3d does make > sense in the context of atleast_2d and thinking of 3-d arrays as > "stacks" of 2-d arrays where the stacks are in the last dimension. > > atleast_2d converts 1-d arrays to 1xN arrays > > atleast_3d converts 1-d arrays to 1xNx1 arrays so that they can be > "stacked" in the last dimension. I agree that this isn't consistent > with the general notion of "pre-pending" 1's to increase the > dimensionality of the array. > > However, array(a, copy=False, ndmin=3) will always produce arrays with > a 1 at the begining. So at_least3d is convenient if you like to think > of 3-d arrays of stacks of 2-d arrays where the last axis is the > "stacking" dimension. > I'm working with "stacks of 2d arrays" -- but I was always under the impression that -- since the last axis is the "fastest" -- "stacks of " should stack in the first dimension -- not the last --so that the members of the stack still remain contiguous is memory. Is there a general consensus on how one should look at this ? Or are there multiple incompatible view -- maybe coming from different fields -- ? -Sebastian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] please change mean to use dtype=float
is why he saw a much better result.
>
> Doh! And I fixed that same problem in the mean implementation earlier
> too. I was astounded by how good knuth was doing, but not astounded
> enough apparently.
>
> Does it seem weird to anyone else that in:
> numpy_scalar python_scalar
> the precision ends up being controlled by the python scalar? I would
> expect the numpy_scalar to control the resulting precision just like
> numpy arrays do in similar circumstances. Perhaps the egg on my face is
> just clouding my vision though.
>
> > The two-pass method using
> > Kahan summation (again, in single precision), is better by about 2 orders
> > of magnitude. There is practically no difference when using a
> > double-precision accumulator amongst the techniques: they're all about 9
> > orders of magnitude better than single-precision two-pass.
> >
> > In float64, Kahan summation is again better than the rest, by about 2
> > orders of magnitude.
> >
> > I've put my adaptation of Tim's code, and box-and-whisker plots of the
> > results, at http://arbutus.mcmaster.ca/dmc/numpy/variance/
> >
> > Conclusions:
> >
> > - If you're going to calculate everything in single precision, use Kahan
> > summation. Using it in double-precision also helps.
> > - If you can use a double-precision accumulator, it's much better than
> > any of the techniques in single-precision only.
> >
> > - for speed+precision in the variance, either use Kahan summation in
> > single precision with the two-pass method, or use double precision with
> > simple summation with the two-pass method. Knuth buys you nothing, except
> > slower code :-)
>
> The two pass methods are definitely more accurate. I won't be convinced
> on the speed front till I see comparable C implementations slug it out.
> That may well mean never in practice. However, I expect that somewhere
> around 10,000 items, the cache will overflow and memory bandwidth will
> become the bottleneck. At that point the extra operations of Knuth won't
> matter as much as making two passes through the array and Knuth will win
> on speed. Of course the accuracy is pretty bad at single precision, so
> the possible, theoretical speed advantage at large sizes probably
> doesn't matter.
>
> -tim
>
> > After 1.0 is out, we should look at doing one of the above.
>
> +1
>
Hi,
I don't understand much of these "fancy algorithms", but does the above mean
that
after 1.0 is released the float32 functions will catch up in terms of
precision precision ("to some extend") with using dtype=float64 ?
- Sebastian Haase
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Tests and code documentation
On Thursday 21 September 2006 09:05, Charles R Harris wrote: > Travis, > > A few questions. > > 1) I can't find any systematic code testing units, although there seem to > be tests for regressions and such. Is there a place we should be putting > such tests? > > 2) Any plans for code documentation? I documented some of my stuff with > doxygen markups and wonder if we should include a Doxyfile as part of the > package. Are able to use doxygen for Python code ? I thought it only worked for C (and alike) ? > > 3) Would you consider breaking out the Converters into a separate .c file > for inclusion? The code generator seems to take care of the ordering. > > Chuck - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] please change mean to use dtype=float
Robert Kern wrote: >> This was not supposed to be a scientific statement -- I'm (again) >> thinking of our students that not always appreciate the full >> complexity >> of computational numerics and data types and such. > > They need to appreciate the complexity of computational numerics if > they are going to do numerical computation. Double precision does not > make it any simpler. This is were we differ. > We haven't forgotten what newcomers will do; to the contrary, we are > quite aware > that new users need consistent behavior in order to learn how to use a > system. > Adding another special case in how dtypes implicitly convert to one > another will > impede new users being able to understand the whole system. All I'm proposing could be summarized in: mean(), sum(), var() ... produce output of dtype float64 (except for input float96 which produces float96) A comment on this is also that for these operations the input type/precision is almost not related to the resulting output precision -- the int case makes that already clear. (This is different for e.g. min() or max() ) The proposed alternative implementations seem to have one or more multiplication (or division) for each value -- this might be noticeably slower ... Regards, Sebastian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] please change mean to use dtype=float
Robert Kern wrote: > Sebastian Haase wrote: >> I know that having too much knowledge of the details often makes one >> forget what the "newcomers" will do and expect. > > Please be more careful with such accusations. Repeated frequently, they can > become quite insulting. > I did not mean to insult anyone - what I meant was, that I'm for numpy becoming an easy platform to use. I have spend and enjoyed part the last four years developing and evangelizing Python as an alternative to Matlab and C/Fortran based image analysis environment. I often find myself arguing for good support of the single precision data format. So I find it actually somewhat ironic to see myself arguing now for wanting float64 over float32 ;-) >> We are only talking >> about people that will a) work with single-precision data (e.g. large >> scale-image analysis) and who b) will tend to "just use the default" >> (dtype) --- How else can I say this: these people will just assume that >> arr.mean() *is* the mean of arr. > > I don't understand what you mean, here. arr.mean() is almost never *the* mean > of > arr. Double precision can't fix that. > This was not supposed to be a scientific statement -- I'm (again) thinking of our students that not always appreciate the full complexity of computational numerics and data types and such. The best I can hope for is a "sound" default for most (practical) cases... I still think that 80bit vs. 128bit vs 96bit is rather academic for most people ... most people seem to only use float64 and then there are some that use float32 (like us) ... Cheers, Sebastian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] please change mean to use dtype=float
Charles R Harris wrote: > > > On 9/19/06, *Sebastian Haase* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Travis Oliphant wrote: > > Sebastian Haase wrote: > >> I still would argue that getting a "good" (smaller rounding > errors) answer > >> should be the default -- if speed is wanted, then *that* could > be still > >> specified by explicitly using dtype=float32 (which would also > be a possible > >> choice for int32 input) . > >> > > So you are arguing for using long double then ;-) > > > >> In image processing we always want means to be calculated in > float64 even > >> though input data is always float32 (if not uint16). > >> > >> Also it is simpler to say "float64 is the default" (full stop.) > - instead > >> > >> "float64 is the default unless you have float32" > >> > > "the type you have is the default except for integers". Do you > really > > want float64 to be the default for float96? > > > > Unless we are going to use long double as the default, then I'm not > > convinced that we should special-case the "double" type. > > > I guess I'm not really aware of the float96 type ... > Is that a "machine type" on any system ? I always thought that -- e.g . > coming from C -- double is "as good as it gets"... > Who uses float96 ? I heard somewhere that (some) CPUs use 80bits > internally when calculating 64bit double-precision... > > Is this not going into some academic argument !? > For all I know, calculating mean()s (and sum()s, ...) is always done in > double precision -- never in single precision, even when the data is in > float32. > > Having float32 be the default for float32 data is just requiring more > typing, and more explaining ... it would compromise numpy usability as > a day-to-day replacement for other systems. > > Sorry, if I'm being ignorant ... > > > I'm going to side with Travis here. It is only a default and easily > overridden. And yes, there are precisions greater than double. I was > using quad precision back in the eighties on a VAX for some inherently > ill conditioned problems. And on my machine long double is 12 bytes. > > Chuck > I just did a web search for "long double" http://www.google.com/search?q=%22long+double%22 and it does not look like there is much agreement on what that is - see also http://en.wikipedia.org/wiki/Long_double I really think that float96 *is* a special case - but computing mean()s and var()s in float32 would be "bad science". I hope I'm not alone in seeing numpy a great "interactive platform" to do evaluate data... I know that having too much knowledge of the details often makes one forget what the "newcomers" will do and expect. We are only talking about people that will a) work with single-precision data (e.g. large scale-image analysis) and who b) will tend to "just use the default" (dtype) --- How else can I say this: these people will just assume that arr.mean() *is* the mean of arr. -Sebastian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] please change mean to use dtype=float
Travis Oliphant wrote: > Sebastian Haase wrote: >> I still would argue that getting a "good" (smaller rounding errors) answer >> should be the default -- if speed is wanted, then *that* could be still >> specified by explicitly using dtype=float32 (which would also be a possible >> choice for int32 input) . >> > So you are arguing for using long double then ;-) > >> In image processing we always want means to be calculated in float64 even >> though input data is always float32 (if not uint16). >> >> Also it is simpler to say "float64 is the default" (full stop.) - instead >> >> "float64 is the default unless you have float32" >> > "the type you have is the default except for integers". Do you really > want float64 to be the default for float96? > > Unless we are going to use long double as the default, then I'm not > convinced that we should special-case the "double" type. > I guess I'm not really aware of the float96 type ... Is that a "machine type" on any system ? I always thought that -- e.g. coming from C -- double is "as good as it gets"... Who uses float96 ? I heard somewhere that (some) CPUs use 80bits internally when calculating 64bit double-precision... Is this not going into some academic argument !? For all I know, calculating mean()s (and sum()s, ...) is always done in double precision -- never in single precision, even when the data is in float32. Having float32 be the default for float32 data is just requiring more typing, and more explaining ... it would compromise numpy usability as a day-to-day replacement for other systems. Sorry, if I'm being ignorant ... - Sebastian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] please change mean to use dtype=float
On Tuesday 19 September 2006 17:17, Travis Oliphant wrote: > Sebastian Haase wrote: > >On Tuesday 19 September 2006 15:48, Travis Oliphant wrote: > >>Sebastian Haase wrote: > > > > > > > >>>can we please change dtype to default to float64 !? > >> > >>The default is float64 now (as long as you are not using > >>numpy.oldnumeric). > >> > >>I suppose more appropriately, we could reduce over float for integer > >>data-types when calculating the mean as well (since a floating point is > >>returned anyway). > > > >Is now mean() always "reducing over" float64 ? > >The svn note """Log: > >Fix mean, std, and var methods so that they reduce over double data-type > > with integer inputs. > >""" > >makes it sound that a float32 input is stays float32 ? > > Yes, that is true. Only integer inputs are changed because you are > going to get a floating point output anyway. > > >For mean calculation this might introduce large errors - I usually would > >require double-precision for *any* input type ... > > Of course. The system is not fool-proof. I hesitate to arbitrarily > change this. The advantage of using single-precision calculation is > that it is faster. We do rely on the user who expressly requests these > things to be aware of the difficulties. I still would argue that getting a "good" (smaller rounding errors) answer should be the default -- if speed is wanted, then *that* could be still specified by explicitly using dtype=float32 (which would also be a possible choice for int32 input) . In image processing we always want means to be calculated in float64 even though input data is always float32 (if not uint16). Also it is simpler to say "float64 is the default" (full stop.) - instead "float64 is the default unless you have float32" Thanks, Sebastian Haase - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] please change mean to use dtype=float
On Tuesday 19 September 2006 15:48, Travis Oliphant wrote: > Sebastian Haase wrote: > >can we please change dtype to default to float64 !? > > The default is float64 now (as long as you are not using > numpy.oldnumeric). > > I suppose more appropriately, we could reduce over float for integer > data-types when calculating the mean as well (since a floating point is > returned anyway). > Is now mean() always "reducing over" float64 ? The svn note """Log: Fix mean, std, and var methods so that they reduce over double data-type with integer inputs. """ makes it sound that a float32 input is stays float32 ? For mean calculation this might introduce large errors - I usually would require double-precision for *any* input type ... (don't know how to say this for complex types !? Are here real and imag treated separately / independently ?) Thanks, Sebastian Haase - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] please change mean to use dtype=float
Hello all, I just had someone from my lab coming to my desk saying: "My god - SciPy is really stupid An array with only positive numbers claims to have a negative mean !! "? I was asking about this before ... the reason was of course that her array was of dtype int32 and had many large values to cause an overflow (wrap around) . Now that the default for axis is None (for all functions having an axis argument), can we please change dtype to default to float64 !? It is really a very confusing and shocking result to get a negative mean on all positive values. It has been stated here before that numpy should target the "scientist" rather than the programmers ... I would argue that mean() almost always requires the precision of "double" (float64) to produce usable results. Please consider this change before the 1.0 release ... Thanks, Sebastian Haase - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] arr.dtype.kind is 'i' for dtype=unit !?
OK - I'm really sorry !! I also get 'u' -- I had a typo there ... But what is the complete list of kind values ? -Sebastian On Tuesday 19 September 2006 11:54, Scott Ransom wrote: > > > Can anybody on a 64-bit system confirm? > > > > I'm on 64-bit Debian: > > > > In [11]: arr=N.arange(10,dtype=N.uint) > > > > In [12]: arr.dtype.kind > > Out[12]: 'u' > > > > In [13]: arr.dtype.itemsize > > Out[13]: 4 > > > > In [14]: arr=N.arange(10,dtype=N.long) > > > > In [15]: arr.dtype.kind > > Out[15]: 'i' > > > > In [16]: arr.dtype.itemsize > > Out[16]: 8 > > Ack! That was on the wrong machine (32-bit Debian). Here is the 64-bit > version: > > In [2]: arr=N.arange(10,dtype=N.uint) > > In [3]: arr.dtype.kind > Out[3]: 'u' > > In [4]: arr.dtype.itemsize > Out[4]: 8 > > In [5]: arr=N.arange(10,dtype=N.long) > > In [6]: arr.dtype.kind > Out[6]: 'i' > > In [7]: arr.dtype.itemsize > Out[7]: 8 > > Sorry about that, > > Scott - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] arr.dtype.kind is 'i' for dtype=unit !?
Hi, What are the possible values of arr.dtype.kind ? It seems that signed and unsigned are considered to be the same "kind" >>> arr=N.arange(10,dtype=N.uint) >>> arr.dtype.kind 'i' >>> arr.dtype.itemsize 8 (OK - this is just showing off our amd64 linux ;-) ) How can I distinguish signed from unsigned without having to list all possible cases explicitly ? Thanks, Sebastian Haase - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] how to get info about internals of an array object ?
On Friday 15 September 2006 12:49, Travis Oliphant wrote: > Sebastian Haase wrote: > >On Friday 15 September 2006 10:00, Travis Oliphant wrote: > >>Sebastian Haase wrote: > >>>Hi, > >>> > >>>what I'm asking is if numpy has an equivalent to numarray's info() > > > >function: > >>>>>>na.arange(10).info() > >> > >>numpy.numarray.info(numpy.arange(10)) > >> > >>(get recent SVN as there were some bugs just fixed. > >> > >>-Travis > > > >Thanks, > > > >should this maybe also be added somewhere in the numpy module itself !? > >I guess the question is, what the original intent was for numarray to put > > it in (only for debugging ?) -- then we could decide if this would also > > make sense for numpy. > > > >I have never used numpy.info(obj) - I don't know what is does (compared to > >__doc__) > > It prints the doc string of an object searching for it better than help > seems to do and without a "pager". > > Compare numpy.info(numpy.sin) versus help(numpy.sin) In PyShell I would miss the output of numpy.info(numpy.sin) since it goes to the (C) stdout and not to the (sometimes redirected ) python sys.stdout. So it seems it prints N.sin.__doc__ The output from help(...) goes to the (python) sys.stdout (or stderr !?) and is quite long (and mostly just generec info about ufuncs ...) > > I don't know what the info method was for other than debugging. > > What about having the __doc__ attribute of an ndarray return the info? > Maybe, but honestly I would *not* expect any kind of "live inspection" to be done by __doc__ I would expect more like "ndarray is an efficient way to handle large data sets in python - it is the bases for Numerical Python, see www.scipy.org " Maybe info() should just be an array attribute - just like it was it numarray. -Sebastian - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] how to get info about internals of an array object ?
On Friday 15 September 2006 10:00, Travis Oliphant wrote: > Sebastian Haase wrote: > > Hi, > > > > what I'm asking is if numpy has an equivalent to numarray's info() function: > >>>> na.arange(10).info() > > numpy.numarray.info(numpy.arange(10)) > > (get recent SVN as there were some bugs just fixed. > > -Travis Thanks, should this maybe also be added somewhere in the numpy module itself !? I guess the question is, what the original intent was for numarray to put it in (only for debugging ?) -- then we could decide if this would also make sense for numpy. I have never used numpy.info(obj) - I don't know what is does (compared to __doc__) but maybe it could be extended like if isinstance( obj , N.ndarray): print N.numarray.info( obj ) right now it prints nothings (and returns None) Thanks, Sebastian Haase - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] how to get info about internals of an array object ?
Hi, what I'm asking is if numpy has an equivalent to numarray's info() function: >>> na.arange(10).info() class: shape: (10,) strides: (4,) byteoffset: 0 bytestride: 4 itemsize: 4 aligned: 1 contiguous: 1 buffer: data pointer: 0x085b7ec8 (DEBUG ONLY) byteorder: 'little' byteswap: 0 type: Int32 This was always helpful to me when debugging C binding code. Especially I'm asking if there is any way to get the memory address of an array - for debugging purposes only - of course ;-) Thanks, Sebastian Haase - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] [Numpy-tickets] [NumPy] #235: r_, c_, hstack, vstack, column_stack should be made more consistent
Travis, what is the "new string directives as the first element of the item tuple" !? I always liked the idea of having a "shortest possible" way for creating (or concatenating) rows with "r_" *and* columns with "c_" ! Why did the "c_" have to be removed !? Thanks, Sebastan NumPy wrote: > #235: r_, c_, hstack, vstack, column_stack should be made more consistent > -+-- > Reporter: baxissimo|Owner: somebody > Type: enhancement | Status: closed > Priority: normal |Milestone: > Component: numpy.lib| Version: devel > Severity: normal | Resolution: fixed > Keywords: | > -+-- > Changes (by oliphant): > > * status: new => closed > * resolution: => fixed > > Comment: > > r_ is the only current quick-creator. You can now get the functionality > of all others using string directives as the first element of the item > tuple. > > Column stack was fixed. > - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend
Travis Oliphant wrote:
>> Ticket #188 dtype should have nicer str representation
>> Is this one now officially dead ?
>> ">but str() should rather return 'int32 (little endian)'
>>
> It's not necessarily dead, the problem is complexity of implementation
> and more clarity about how all dtypes are supposed to be printed, not
> just this particular example. A patch would be very helpful here. If
> desired it could be implemented in _internal.py and called from there in
> arrayobject.c
>
> But, to get you thinking... How should the following be printed
>
> dtype('c4')
>
> dtype('a4,i8,3f4')
>
> dtype('3f4')
>
>
> -Travis
I would argue that if the simple cases were addressed first those would
cover 90% (if not 99% for most people) of the cases occurring in
people's daily use.
For complex types (like 'a4,i8,3f4') I actually think the current text
is compact and good.
(Lateron one could think about
'c4' --> '4 chars'
'3f4' --> '3 float32s'
but already I don't know: is there any difference between 'c4' and
'4c1'? What is the difference between 'c4' and 'a4' !?
)
My main focus is on the fact that you might read 'http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] NumPy 1.0 release-candidate 1.0 this weekend
Hi! I would like to hear about three tickets I submitted some time ago: Ticket #230 a**2 not executed as a*a if a.dtype = int32 is this easy to fix ? Ticket #229 numpy.random.poisson(0) should return 0 I hope there is agreement that the edge-case of 0 should/could be handled without raising an exception. I submitted a patch (please test first!) any comments on this one. Ticket #188 dtype should have nicer str representation Is this one now officially dead ? "http://aspn.activestate.com/ASPN/Mail/Message/3207949 Thanks, Sebastian Haase On Wednesday 13 September 2006 13:18, Travis Oliphant wrote: > I'd like to make the first release-candidate of NumPy 1.0 this weekend. > > Any additions wanting to make the first official release candidate > should be checked in by then. > > -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 > Numpy-discussion@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/numpy-discussion - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] what is nan_to_num() for float32 ?
On Tuesday 12 September 2006 13:33, Sebastian Haase wrote: > Hi ! > I have a nice ndarray image viewer built on OpenGL - one annoyance though > is that is crashes if the array contains any NaN, or inf, ... > > So, I found N.nan_to_num - but OpenGL (read: video cards) supports only > single precision float (N.float32) > > So I get this: > >>> N.nan_to_num([N.inf]) > > [ 1.79769313e+308] > > >>> N.nan_to_num([N.inf]).astype(N.float32) > > [ inf] > > Could nan_to_num() get an optional dtype argument ? > > Thanks, > Sebastian Haase OK - sorry for the noise... this is how to do it: >>> N.nan_to_num( N.array([N.nan,N.inf,-N.inf],N.float32) ) [ 0.e+00 3.40282347e+38 -3.40282347e+38] In the meantime I noticed that there is a N.asarray_chkfinite() function but no equivalent for N.asanyarray() ! Should N.asanyarray_chkfinite() be added !? -Sebastian - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] what is nan_to_num() for float32 ?
Hi ! I have a nice ndarray image viewer built on OpenGL - one annoyance though is that is crashes if the array contains any NaN, or inf, ... So, I found N.nan_to_num - but OpenGL (read: video cards) supports only single precision float (N.float32) So I get this: >>> N.nan_to_num([N.inf]) [ 1.79769313e+308] >>> N.nan_to_num([N.inf]).astype(N.float32) [ inf] Could nan_to_num() get an optional dtype argument ? Thanks, Sebastian Haase - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] 2 GB limit for memmap'ed files
Hi Glen ! How is that quote really !? The new Python2.5 *is* implementing the needed changes - so go ahead install Python2.5 (rc1 is the latest I think) and report how it works. I would also be very intersted to hear ;-) -Sebastian Haase On Thursday 07 September 2006 12:34, Glen W. Mabey wrote: > A long time ago, Travis wrote: > > On a related, but orthogonal note: > > > > My understanding is that using memory-mapped files for *very* large > > files will require modification to the mmap module in Python --- > > something I think we should push. One part of that process would be > > to add the C-struct array interface to the mmap module and the buffer > > object -- perhaps this is how we get the array interface into Python > > quickly. Then, if we could make a base-type mmap that did not use > > the buffer interface or the sequence interface (similar to the > > bigndarray in scipy_core) and therefore by-passed the problems with > > Python in those areas, then the current mmap object could inherit from > > the base class and provide current functionality while still exposing > > the array interface for access to >2GB files on 64-bit systems. > > > > Who would like to take up the ball for modifying mmap in Python in > > this fashion? > > > > -Travis > > Did anyone ever "pick up the ball" on this issue? > > Glen > > > - > 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 > Numpy-discussion@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/numpy-discussion - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] bug in round with negative number of decimals
Paulo J. S. Silva wrote: > Once again, the information that singed zero is part of IEEE standard is > in the paper I cited in my last message. > > It is very important to be able to compute the sign of an overflowed > quantity in expressions like 1/x when x goes to zero. > > Best, > > Paulo Hi, This is all very interesting ( and confusing (to me, maybe others) at the same time ...) ... Question 0: Are you sure this is not a bug ? >>> N.array([66]).round(-1) [60] >>> N.array([66.2]).round(-1) [ 70.] Question 1: Was this way of round already in Numeric and /or in numarray ? Question 2: Does this need to be better documented (complete and corrected(!) docstrings - maybe a dedicated wiki page ) !? This is related to "How does Matlab or IDL or others do rounding ?" - This would at least determine how many people would be surprised by this. (I would say that *if* Matlab rounds the same way, we might need less documentation ...) Thanks, Sebastian Haase - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] bug in round with negative number of decimals
Charles R Harris wrote: > > > On 9/3/06, *Sebastian Haase* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Hi, > I just learn about the existence of round(). > Is the following exposing a bug? > >>> N.__version__ > '1.0b4' > >>> N.array([65.0]) > [ 65.] > >>> _.round(-1) > [ 60.] > >>> round(65, -1) > 70.0 > >>> N.array([65]) > [65] > >>> _.round(-1) > [60] > >>> N.array([66]) > [66] > >>> _.round(-1) > [60] > >>> N.array([66.2]) > [ 66.2] > >>> _.round(-1) > [ 70.] > > 65 should round *up* to 70. (when decimals is given as -1) > In numpy even 66 rounds down, but 66.2 rounds up ... > > > Numpy rounds to even. > > >>> around(arange(10)*.5) > array([ 0., 0., 1., 2., 2., 2., 3., 4., 4., 4.]) > > i.e., when at those x.5 boundaries, round to the nearest even number. > Always rounding in the same direction biases the numbers when you have > gazillions of them. This is most likely of import when the fpu is > rounding intermediate results to register length, but numpy does it too. > Floats can be weird anyway, .15, for instance, can't be represented > exactly as an ieee float. It does tend to throw folks for a loop when > they don't keep this in mind. > > - Sebastian Haase > > > Chuck Thanks for the reply - but read what the doc says: >>> N.around.__doc__ 'Round 'a' to the given number of decimal places. Rounding behaviour is equivalent to Python. Return 'a' if the array is not floating point. Round both the real and imaginary parts separately if the array is complex. ' it is *not* done this way in Python: >>> round(.5) 1.0 >>> round(1.5) 2.0 >>> round(2.5) 3.0 ( the round obj. method is missing this doc string ) I really think we should stick to what the doc string say - everybody expects x.5 to round up !! look even at this: >>> repr(2.05) '2.0498' >>> round(2.05, 1) 2.1 (don't ask me how Python does this, but it's "nice" ) Thanks, Sebastian - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] bug in round with negative number of decimals
Hi, I just learn about the existence of round(). Is the following exposing a bug? >>> N.__version__ '1.0b4' >>> N.array([65.0]) [ 65.] >>> _.round(-1) [ 60.] >>> round(65, -1) 70.0 >>> N.array([65]) [65] >>> _.round(-1) [60] >>> N.array([66]) [66] >>> _.round(-1) [60] >>> N.array([66.2]) [ 66.2] >>> _.round(-1) [ 70.] 65 should round *up* to 70. (when decimals is given as -1) In numpy even 66 rounds down, but 66.2 rounds up ... - Sebastian Haase - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Use of numarray from numpy package [# INC NO 24609]
Andrew Straw wrote:
> LANDRIU David SAp wrote:
>> Hello,
>>
>> I come back to my question : how to use numarray
>> with the numpy installation ?
>>
>> {ccali22}~(0)>setenv PYTHONPATH /usr/local/lib/python2.3/site-packages/numpy
>>
> Here's where you went wrong. You want:
>
> setenv PYTHONPATH /usr/local/lib/python2.3/site-packages
>
>> {ccali22}~(0)>python
>> Python 2.3.5 (#2, Oct 17 2005, 17:20:02)
>> [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-52)] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>>
>>>>> from numarray import *
>>>>>
>> Traceback (most recent call last):
>> File "", line 1, in ?
>> File "/usr/local/lib/python2.3/site-packages/numpy/numarray/__init__.py",
>> line 1, in ?
>> from util import *
>> File "/usr/local/lib/python2.3/site-packages/numpy/numarray/util.py", line
>> 2, in ?
>> from numpy import geterr
>> ImportError: No module named numpy
>>
>
> Note that you're actually importing a numarray within numpy's directory
> structure. That's because of your PYTHONPATH. numpy ships numpy.numarray
> to provide backwards compatibility. To use it, you must do "import
> numpy.numarray as numarray"
>
Just to explain -- there is only a numarray directory inside numpy
to provide some special treatment for people that do the transition from
numarray to numpy - meaning: they can do somthing like
from numpy import numarray
and get a "numpy(!) version" that behaves more like numarray than the
straight numpy ...
Similar for
"from numarray import oldnumaric as Numeric" (for people coming from
Numeric )
Yes - it is actually confusing, but that's the baggage when there are 2
(now 3) numerical python packages is human history.
The future will be much brighter - forget all of the above, and just use
import numpy
(I like "import numpy as N" for less typing - others prefer even
"from numpy import *"
)
Hope that helps,
- Sebastian Haase
-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] amd64 support
Keith Goodman wrote: > I plan to build an amd64 box and run debian etch. Are there any big, > 64-bit, show-stopping problems in numpy? Any minor annoyances? > I am not aware of any - we use fine on 32bit and 64bit with debian sarge and etch. -Sebastian Haase - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] ticket system does not like me ! - seems broken ...
Robert Kern wrote: > Sebastian Haase wrote: > >> (Could you add a web link from one system to the other ?) > > I'm afraid that I don't understand what you want. The numpy front page has a > link to the scipy front page. If you want a similar one in reverse, it's a > Wiki > and you can do it yourself. If you mean something else, what do you mean? > Sorry for being so unclear -- I just often find myself (by clicking on a ticket link) in one system (e.g. the scipy one) and then I realize that what I want is really more related to numpy ... I just found that the numpy page at http://projects.scipy.org/scipy/numpy contains the text """SciPy developer stuff goes on the sister site, http://projects.scipy.org/scipy/scipy/. """ Could you add similar text to http://projects.scipy.org/scipy/scipy/ like: """Stuff specific to the underlying numerical library (i.e. numpy) goes on the sister site, http://projects.scipy.org/scipy/numpy/ """ (I fear it's not really the most important request in the world ;-) ) - Sebastian - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] a**2 not executed as a*a if a.dtype = int32
Robert Kern wrote: > Sebastian Haase wrote: >> Hi, >> I submitted this as ticket #230 3weeks ago. >> I apparently assigned it to "somebody" - was that a mistake? > > No, that's just the default. When the tickets lists are reliable again, then > it's also preferred. No, your ticket might not get picked up by anyone > because > of lack of time, but assigning it to someone won't fix that. Let the dev team > work out the assignment of tickets. > Thanks for the info -- could this be added on the form ? Like: """ If you don't have any good reason just leave the fields 'empty' and the dev-team will assign proper values soon. Also don't forget to put yourself in the CC field if you want to track changes to the issue you just reported. """ I just think its not obvious for *most* of the choice-fields what to select ... Thanks -Sebastian - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] ticket system does not like me ! - seems broken ...
Robert Kern wrote: > Sebastian Haase wrote: >> Hi, >> I started submitting tickets over the numpy ticket system. >> >> But I never get email feedback when comments get added. >> Even though I put myself as CC. >> >> I then even subscribed to both scipy and numpy ticket mailing lists. >> >> I only got *some* numpy tickets emailed - very sporadically ! >> >> (I do get (lot's of) email from the svn mailing list.) >> >> Do others see similar problems ? > > Now that you mention it, the lists *are* missing tickets. I'll raise the > issue > internally. > > As for the former, have you entered your email address in your settings? > >http://projects.scipy.org/scipy/numpy/settings >http://projects.scipy.org/scipy/scipy/settings > yes. (Could you add a web link from one system to the other ?) Thanks for taking this on. -Sebastian - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] a**2 not executed as a*a if a.dtype = int32
Hi,
I submitted this as ticket #230 3weeks ago.
I apparently assigned it to "somebody" - was that a mistake?
Just for refernce, here is the short text again:
>>> a=N.random.poisson(N.arange(1e6)+1)
>>> U.timeIt('a**2')
0.59
>>> U.timeIt('a*a')
0.01
>>> a.dtype
int32
float64, float32 work OK - giving equal times for both cases. (I tested
this on Linux 32 bit, Debian sarge)
Am I right that numarray never did this kind of "smart speed up" !?
What are the cases that are speed up like this ? **2, **.5 , ... ??
Thanks,
- Sebastian Haase
-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] ticket system does not like me ! - seems broken ...
Hi, I started submitting tickets over the numpy ticket system. But I never get email feedback when comments get added. Even though I put myself as CC. I then even subscribed to both scipy and numpy ticket mailing lists. I only got *some* numpy tickets emailed - very sporadically ! (I do get (lot's of) email from the svn mailing list.) Do others see similar problems ? -Sebastian Haase - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Deleting a row from a matrix
On Friday 25 August 2006 16:16, Travis Oliphant wrote: > Sebastian Haase wrote: > > On Friday 25 August 2006 08:01, Travis Oliphant wrote: > >> Travis Oliphant wrote: > >>>> Now of course: I often needed to "insert" a column, row or section, > >>>> ... ? I made a quick and dirty implementation for that myself: > >>>> def insert(arr, i, entry, axis=0): > >>>> """returns new array with new element inserted at index i along > >>>> axis if arr.ndim>1 and if entry is scalar it gets filled in (ref. > >>>> broadcasting) > >>>> > >>>> note: (original) arr does not get affected > >>>> """ > >>>> if i > arr.shape[axis]: > >>>> raise IndexError, "index i larger than arr size" > >>>> shape = list(arr.shape) > >>>> shape[axis] += 1 > >>>> a= N.empty(dtype=arr.dtype, shape=shape) > >>>> aa=N.transpose(a, [axis]+range(axis)+range(axis+1,a.ndim)) > >>>> aarr=N.transpose(arr, [axis]+range(axis)+range(axis+1,arr.ndim)) > >>>> aa[:i] = aarr[:i] > >>>> aa[i+1:] = aarr[i:] > >>>> aa[i] = entry > >>>> return a > >>> > >>> Sure, it makes sense to parallel the delete function. > >> > >> Although there is already and insert function present in numpy > >> > >> -Travis > > > > Yeah - I saw that ... > > maybe one could introduce consistent namings like > > arr.copy_insert() > > arr.copy_delete() > > arr.copy_append() > > I've come up with adding the functions (not methods at this point) > > deletefrom > insertinto > > appendto (syntatic sugar for concatenate but with a separate argument > for the array and the extra stuff) --- is this needed? not for me. -S. - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Deleting a row from a matrix
On Friday 25 August 2006 08:01, Travis Oliphant wrote: > Travis Oliphant wrote: > >> Now of course: I often needed to "insert" a column, row or section, ... > >> ? I made a quick and dirty implementation for that myself: > >> def insert(arr, i, entry, axis=0): > >> """returns new array with new element inserted at index i along axis > >> if arr.ndim>1 and if entry is scalar it gets filled in (ref. > >> broadcasting) > >> > >> note: (original) arr does not get affected > >> """ > >> if i > arr.shape[axis]: > >> raise IndexError, "index i larger than arr size" > >> shape = list(arr.shape) > >> shape[axis] += 1 > >> a= N.empty(dtype=arr.dtype, shape=shape) > >> aa=N.transpose(a, [axis]+range(axis)+range(axis+1,a.ndim)) > >> aarr=N.transpose(arr, [axis]+range(axis)+range(axis+1,arr.ndim)) > >> aa[:i] = aarr[:i] > >> aa[i+1:] = aarr[i:] > >> aa[i] = entry > >> return a > > > > Sure, it makes sense to parallel the delete function. > > Although there is already and insert function present in numpy > > -Travis Yeah - I saw that ... maybe one could introduce consistent namings like arr.copy_insert() arr.copy_delete() arr.copy_append() for the new ones. This emphasis the fact that a copy is created ... (Append is also a function often asked for when people expect "list capabilities" - did I miss others ?) -Sebastian - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Deleting a row from a matrix
On Friday 25 August 2006 07:01, Travis Oliphant wrote: > Keith Goodman wrote: > > How do I delete a row (or list of rows) from a matrix object? > > > > To remove the n'th row in octave I use x(n,:) = []. Or n could be a > > vector of rows to remove. > > > > In numpy 0.9.9.2813 x[[1,2],:] = [] changes the values of all the > > elements of x without changing the size of x. > > > > In numpy do I have to turn it around and construct a list of the rows > > I want to keep? > > Basically, that is true for now. > > I think it would be worth implementing some kind of function for making > this easier. > > One might think of using: > > del a[obj] > > But, the problem with both of those approaches is that once you start > removing arbitrary rows (or n-1 dimensional sub-spaces) from an array > you very likely will no longer have a chunk of memory that can be > described using the n-dimensional array memory model. > > So, you would have to make memory copies. This could be done, of > course, and the data area of "a" altered appropriately. But, such > alteration of the memory would break any other objects that have a > "view" of the memory area of "a." Right now, there is no way to track > which objects have such "views", and therefore no good way to tell > (other than the very conservative reference count) if it is safe to > re-organize the memory of "a" in this way. > > So, "in-place" deletion of array objects would not be particularly > useful, because it would only work for arrays with no additional > reference counts (i.e. simple b=a assignment would increase the > reference count and make it impossible to say del a[obj]). > > However, a function call that returned a new array object with the > appropriate rows deleted (implemented by constructing a new array with > the remaining rows) would seem to be a good idea. > > I'll place a prototype (named delete) to that effect into SVN soon. > > -Travis > Now of course: I often needed to "insert" a column, row or section, ... ? I made a quick and dirty implementation for that myself: def insert(arr, i, entry, axis=0): """returns new array with new element inserted at index i along axis if arr.ndim>1 and if entry is scalar it gets filled in (ref. broadcasting) note: (original) arr does not get affected """ if i > arr.shape[axis]: raise IndexError, "index i larger than arr size" shape = list(arr.shape) shape[axis] += 1 a= N.empty(dtype=arr.dtype, shape=shape) aa=N.transpose(a, [axis]+range(axis)+range(axis+1,a.ndim)) aarr=N.transpose(arr, [axis]+range(axis)+range(axis+1,arr.ndim)) aa[:i] = aarr[:i] aa[i+1:] = aarr[i:] aa[i] = entry return a but maybe there is a way to put it it numpy directly. - Sebastian - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] coercion rules for float32 in numpy are different from numarray
On Friday 25 August 2006 12:19, Charles R Harris wrote: > Hi, > > On 8/25/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: > > Sebastian Haase wrote: > > >> This is now the behavior in SVN. Note that this is different from > > > > both > > > > >> Numeric (which gave an error) and numarray (which coerced to float32). > > >> > > >> But, it is consistent with how mixed-types are handled in calculations > > >> and is thus an easier rule to explain. > > >> > > >> Thanks for the testing. > > >> > > >> -Travis > > > > > > How hard would it be to change the rules back to the numarray behavior > > > ? > > > > It wouldn't be hard, but I'm not so sure that's a good idea. I do see > > the logic behind that approach and it is worthy of some discussion. > > I'll give my current opinion: > > > > The reason I changed the behavior is to get consistency so there is one > > set of rules on mixed-type interaction to explain. You can always do > > what you want by force-casting your int32 arrays to float32.There > > will always be some people who don't like whichever behavior is > > selected, but we are trying to move NumPy in a direction of consistency > > with fewer exceptions to explain (although this is a guideline and not > > an absolute requirement). > > > > Mixed-type interaction is always somewhat ambiguous. Now there is a > > consistent rule for both universal functions and other functions (move > > to a precision where both can be safely cast to --- unless one is a > > scalar and then its precision is ignored). > > I think this is a good thing. It makes it easy to remember what the > function will produce. The only oddity the user has to be aware of is that > int32 has more precision than float32. Probably not obvious to a newbie, > but a newbie will probably be using the double defaults anyway. Which is > another good reason for making double the default type. Not true - a numpy-(or numeric-programming) newbie working in medical imaging or astronomy would still get float32 data to work with. He/She would do some operations on the data and be surprised that memory (or disk space) blows up. > > If you don't want that to happen, then be clear about what data-type > > > should be used by casting yourself. In this case, we should probably > > not try and guess about what users really want in mixed data-type > > situations. > > I wonder if it would be reasonable to add the dtype keyword to hstack > itself? Hmmm, what are the conventions for coercions to lesser precision? > That could get messy indeed, maybe it is best to leave such things alone > and let the programmer deal with it by rethinking the program. In the float > case that would probably mean using a float32 array instead of an int32 > array. > > Chuck I think my main argument is that float32 is a very common type in (large) data processing to save memory. But I don't know about how many exceptions like an extra "float32 rule" we can handle ... I would like to hear how the numarray (STScI) folks think about this. Who else works with data of the order of GBs !? - Sebastian - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] users point of view and ufuncs
Sasha wrote: > On 8/25/06, Charles R Harris <[EMAIL PROTECTED]> wrote: >> Matrix rank has nothing to do with numpy rank. Numpy rank is simply the >> number of indices required to address an element of an ndarray. I always >> thought a better name for the Numpy rank would be dimensionality, but like >> everything else one gets used to the numpy jargon, it only needs to be >> defined someplace for what it is. > > That's my point exactly. The rank(2) definition was added by > Sebastian Haase who advocates the use of the term "ndims" instead of > "rank". I've discussed the use of "dimentionality' in the preamble. > Note that ndims stands for the number of dimensions, not > dimensionality. > > I don't want to remove rank(2) without hearing from Sebastian first > and I appreciate his effort to improve the glossary. Maybe we shold > add a "matrix rank" entry instead. My phasing is certainly suboptimal (I only remember the German wording - and even that only faintly - "linear independent" !?) But I put it in, remembering the discussion in "numpy" on *why* array.rank (numarray) was changed to array.ndim (numpy) I just thought this page might be a good place to 'discourage usage of badly-defined terms' or at least give the argument for "ndim". [ OK: it's not "badly" defined: but there are two separate camps on *what* it should mean --- ndim is clear.] BTW: Does the "matrix" class have m.rank attribute !? Cheers, Sebastian. - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] coercion rules for float32 in numpy are different from numarray
was: Re: [Numpy-discussion] hstack(arr_Int32, arr_float32) fails because of casting rules Travis Oliphant wrote: > Sebastian Haase wrote: >> On Thursday 24 August 2006 17:28, Travis Oliphant wrote: >> >>> Sebastian Haase wrote: >>> >>>> Hi, >>>> I get >>>> TypeError: array cannot be safely cast to required type >>>> >>>> when calling hstack() ( which calls concatenate() ) >>>> on two arrays being a int32 and a float32 respectively. >>>> >>>> I understand now that a int32 cannot be safely converted into a float32 >>>> but why does concatenate not automatically >>>> up(?) cast to float64 ?? >>>> >>> Basically, NumPy is following Numeric's behavior of raising an error in >>> this case of unsafe casting in concatenate. For functions that are not >>> universal-function objects, mixed-type behavior works basically just >>> like Numeric did (using the ordering of the types to determine which one >>> to choose as the output). >>> >>> It could be argued that the ufunc-rules should be followed instead. >>> >>> -Travis >>> >>> >> Are you saying the ufunc-rules would convert "int32-float32" to float64 >> and >> hence make my code "just work" !? >> > > This is now the behavior in SVN. Note that this is different from both > Numeric (which gave an error) and numarray (which coerced to float32). > > But, it is consistent with how mixed-types are handled in calculations > and is thus an easier rule to explain. > > Thanks for the testing. > > -Travis After sleeping over this, I am contemplating about the cases where one would use float32 in the first place. My case yesterday, where I only had a 1d line profile of my data, I was of course OK with coercion to float64. But if you are working with 3D image data (as in medicine) or large 2D images as in astronomy I would assume the reason use float32 is that computer memory is to tight to afford 64bits per pixel. This is probably why numarray tried to keep float32. Float32 can handle a few more digits of precision than int16, but not as much as int32. But I find that I most always have int32s only because its the default, whereas I have float32 as a clear choice to save memory. How hard would it be to change the rules back to the numarray behavior ? Who would be negatively affected ? And who positively ? Thanks for the great work. Sebastian - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] hstack(arr_Int32, arr_float32) fails because of casting rules
Travis Oliphant wrote: > Sebastian Haase wrote: >> On Thursday 24 August 2006 17:28, Travis Oliphant wrote: >> >> Are you saying the ufunc-rules would convert "int32-float32" to float64 >> and >> hence make my code "just work" !? >> > Yes. That's what I'm saying (but you would get float64 out --- but if > you didn't want that then you would have to be specific). > >> And why are there two sets of rules ? >> > Because there are two modules (multiarray and umath) where the > functionality is implemented. > >> Are the Numeric rules used at many places ? >> > Not that many. I did abstract the notion to a C-API: > PyArray_ConvertToCommonType and implemented the > scalars-don't-cause-upcasting part of the ufunc rules in that code. > But, I followed the old-style Numeric coercion rules for the rest of it > (because I was adapting Numeric). > > Right now, unless there are strong objections, I'm leaning to changing > that so that the same coercion rules are used whenever a common type is > needed. If you mean keeping the ufunc rules (which seem more liberal, fix my problem ;-) and might make using float32 in general more painless) - I would be all for it ... simplifying is always good in the long term ... Cheers, Sebastian > > It would not be that difficult of a change. - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] hstack(arr_Int32, arr_float32) fails because of casting rules
On Thursday 24 August 2006 17:28, Travis Oliphant wrote: > Sebastian Haase wrote: > >Hi, > >I get > >TypeError: array cannot be safely cast to required type > > > >when calling hstack() ( which calls concatenate() ) > >on two arrays being a int32 and a float32 respectively. > > > >I understand now that a int32 cannot be safely converted into a float32 > >but why does concatenate not automatically > >up(?) cast to float64 ?? > > Basically, NumPy is following Numeric's behavior of raising an error in > this case of unsafe casting in concatenate. For functions that are not > universal-function objects, mixed-type behavior works basically just > like Numeric did (using the ordering of the types to determine which one > to choose as the output). > > It could be argued that the ufunc-rules should be followed instead. > > -Travis > Are you saying the ufunc-rules would convert "int32-float32" to float64 and hence make my code "just work" !? And why are there two sets of rules ? Are the Numeric rules used at many places ? Thanks, Sebastian Haase - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] hstack(arr_Int32, arr_float32) fails because of casting rules
Hi, I get TypeError: array cannot be safely cast to required type when calling hstack() ( which calls concatenate() ) on two arrays being a int32 and a float32 respectively. I understand now that a int32 cannot be safely converted into a float32 but why does concatenate not automatically up(?) cast to float64 ?? Is this really required to be done *explicitly* every time ? ** In general it makes float32 cubersome to use. ** ( Background: my large image data is float32 (float64 would require too much memory) and the hstack call happens inside scipy plt module when I try to get a 1d line profile and the "y_data" is hstack'ed with the x-axis values (int32)) ) Thanks, Sebastian Haase - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] possible bug in C-API
Hi, I noticed in numpy/numarray/_capi.c: NA_NewAllFromBuffer() a) the original numarray function could create arrays of any (ndim) shape, while PyArray_FromBuffer() looks to me that the returned array is always 1D. b) in the code part npy_intp size = dtype->elsize; for ... size *= self->dimensions[i]; PyArray_FromBuffer(bufferObject, dtype, size, byteoffset); Is "size" here a muplitple of the itemsize !? I think I got a crashed (my code) that I fixed when I set size to (the equivalent of) N.prod(array.shape) Cheers, Sebastian Haase - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] should a flatiter object get a 'dtype' attribute ?
Hi, I suppose the answer is no . But converting more code to numpy I got this error AttributeError: 'numpy.flatiter' object has no attribute 'dtype' (I found that I did not need the .flat in the first place ) So I was just wondering if (or how much) a flatiter object should behave like an ndarray ? Also this is an opportunity to have some talk about the relative newcomer "flatiter generator objects" ... Thanks, - Sebastian Haase - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy-1.0b3 under windows
On Thursday 24 August 2006 09:50, [EMAIL PROTECTED] wrote:
> Sorry for my ignorance, but I have not ever heard of or used mingw32. I
> am also using python 2.3.
http://en.wikipedia.org/wiki/Mingw explains in detail.
>
> Is there any way someone could possibly send me a brief walk through of
> how to install 1.0b3 on windows32?
do you know about the ("awesome" wiki website at scipy.org)
try your luck at
http://www.scipy.org/Build_for_Windows
>
> Also I am not sure that I know how to manipulate the code that you guys
> said that you have to so that it will work so if that is needed could you
> post a walk through of that also?
>
To my knowledge there is no need to "manipulate code"
Maybe you should try getting per-build versions first.
Sebastian Haase
-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] request for new array method: arr.abs()
Travis Oliphant wrote:
> Sebastian Haase wrote:
>> On Wednesday 23 August 2006 18:37, Travis Oliphant wrote:
>>
>>> David M. Cooke wrote:
>>>
>>>> On Wed, 23 Aug 2006 16:22:52 -0700
>>>>
>>>> Sebastian Haase <[EMAIL PROTECTED]> wrote:
>>>>
>>>>> On Wednesday 23 August 2006 16:12, Bill Baxter wrote:
>>>>>
>>>>>> The thing that I find I keep forgetting is that abs() is a built-in,
>>>>>> but other simple functions are not. So it's abs(foo), but
>>>>>> numpy.floor(foo) and numpy.ceil(foo). And then there's round() which
>>>>>> is a built-in but can't be used with arrays, so numpy.round_(foo).
>>>>>> Seems like it would be more consistent to just add a numpy.abs() and
>>>>>> numpy.round().
>>>>>>
>>>>> Regarding the original subject:
>>>>> a) "absolute" is impractically too much typing and
>>>>> b) I just thought some (module-) functions might be "forgotten" to be
>>>>> put in as (object-) methods ... !?
>>>>>
>>>> Four-line change, so I added a.abs() (three lines for array, one
>>>> for MaskedArray).
>>>>
>>> While I appreciate it's proactive nature, I don't like this change
>>> because it adds another "ufunc" as a method. Right now, I think conj is
>>> the only other method like that.
>>>
>>> Instead, I like better the idea of adding abs, round, max, and min to
>>> the "non-import-*" namespace of numpy.
>>>
>>>
>> How does this compare with
>> mean, min, max, average
>> ?
>>
>
> I'm not sure what this question is asking, so I'll answer what I think
> it is asking.
>
> The mean, min, max, and average functions are *not* ufuncs. They are
> methods of particular ufuncs.
>
Yes - that's what wanted to hear ! I'm just trying to bring in the
"user's" point of view: Not thinking about how they are implemented
under the hood: mean,min,max,average have a very similar "feeling" to
them as "abs".
I'm hoping this ("seeing things from the user p.o.v.") can stay like
that for as long as possible !
Numpy should be focused on "scientist not programers".
(This is just why I posted this comment about "arr.abs()" - but if
there is a good reason to not have this for "simplicity reasons 'under
the hood'" I can see that perfectly fine !)
- Sebastian
-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] request for new array method: arr.abs()
On Wednesday 23 August 2006 18:37, Travis Oliphant wrote: > David M. Cooke wrote: > > On Wed, 23 Aug 2006 16:22:52 -0700 > > > > Sebastian Haase <[EMAIL PROTECTED]> wrote: > >> On Wednesday 23 August 2006 16:12, Bill Baxter wrote: > >>> The thing that I find I keep forgetting is that abs() is a built-in, > >>> but other simple functions are not. So it's abs(foo), but > >>> numpy.floor(foo) and numpy.ceil(foo). And then there's round() which > >>> is a built-in but can't be used with arrays, so numpy.round_(foo). > >>> Seems like it would be more consistent to just add a numpy.abs() and > >>> numpy.round(). > >> > >> Regarding the original subject: > >> a) "absolute" is impractically too much typing and > >> b) I just thought some (module-) functions might be "forgotten" to be > >> put in as (object-) methods ... !? > > > > Four-line change, so I added a.abs() (three lines for array, one > > for MaskedArray). > > While I appreciate it's proactive nature, I don't like this change > because it adds another "ufunc" as a method. Right now, I think conj is > the only other method like that. > > Instead, I like better the idea of adding abs, round, max, and min to > the "non-import-*" namespace of numpy. > How does this compare with mean, min, max, average ? BTW: I think me choice is now settled on the builtin call: abs(arr) -- short and sweet. (As long as it is really supposed to *always* work and is not *slow* in any way !?!?!?!?) Cheers, Sebastian - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] request for new array method: arr.abs()
On Wednesday 23 August 2006 16:12, Bill Baxter wrote: > The thing that I find I keep forgetting is that abs() is a built-in, but > other simple functions are not. So it's abs(foo), but numpy.floor(foo) and > numpy.ceil(foo). And then there's round() which is a built-in but can't be > used with arrays, so numpy.round_(foo).Seems like it would be more > consistent to just add a numpy.abs() and numpy.round(). > > But I guess there's nothing numpy can do about it... you can't name a > method the same as a built-in function, right? That's why we have > numpy.round_() instead of numpy.round(), no? > [...goes and checks] > Oh, you *can* name a module function the same as a built-in. Hmm... so > then why isn't numpy.round_() just numpy.round()? Is it just so "from > numpy import *" won't hide the built-in? > That is my theory... Even tough I try to advertise import numpy as N a) "N." is not *that* much extra typing b) it much clearer to read code and see what is special from numpy vs. what is builtin c) (most important for me): I use PyShell/PyCrust and when I type the '.' after 'N' I get a nice pop-up list reminding me of all the function in numy ;-) Regarding the original subject: a) "absolute" is impractically too much typing and b) I just thought some (module-) functions might be "forgotten" to be put in as (object-) methods ... !? Cheers, Sebastian > --bill > > On 8/24/06, David M. Cooke <[EMAIL PROTECTED]> wrote: > > On Wed, 23 Aug 2006 13:51:02 -0700 > > > > Sebastian Haase <[EMAIL PROTECTED]> wrote: > > > Hi! > > > numpy renamed the *function* abs to absolute. > > > Most functions like mean, min, max, average, ... > > > have an equivalent array *method*. > > > > > > Why is absolute left out ? > > > I think it should be added . > > > > We've got __abs__ :-) > > > > > Furthermore, looking at some line of code that have multiple calls to > > > absolute [ like f(absolute(a), absolute(b), absolute(c)) ] > > > I think "some people" might prefer less typing and less reading, > > > like f( a.abs(), b.abs(), c.abs() ). > > > > > > One could even consider not requiring the "function call" parenthesis > > > > '()' > > > > > at all - but I don't know about further implications that might have. > > > > eh, no. things that return new arrays should be functions. (As opposed to > > views of existing arrays, like a.T) > > > > > PS: is there any performace hit in using the built-in abs function ? > > > > Shouldn't be: abs(x) looks for the x.__abs__() method (which arrays > > have). - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] request for new array method: arr.abs()
Hi! numpy renamed the *function* abs to absolute. Most functions like mean, min, max, average, ... have an equivalent array *method*. Why is absolute left out ? I think it should be added . Furthermore, looking at some line of code that have multiple calls to absolute [ like f(absolute(a), absolute(b), absolute(c)) ] I think "some people" might prefer less typing and less reading, like f( a.abs(), b.abs(), c.abs() ). One could even consider not requiring the "function call" parenthesis '()' at all - but I don't know about further implications that might have. Thanks, Sebastian Haase PS: is there any performace hit in using the built-in abs function ? - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] why is int32 a NPY_LONG on 32bitLinux & NPY_INT on 64bitLinux
Thanks for the reply, see question below... On Tuesday 22 August 2006 12:30, Travis Oliphant wrote: > Sebastian Haase wrote: > > Hi, > > I just ran into more problems with my SWIG > > typemaps. > > In the C api the current enum for > > NPY_INT is 5 > > NPY_LONG is 7 > > > > to match overloaded function I need to check these type values. > > > > On 64bit all works fine: > > my 32bit int function matches NPY_INT - which is "int" in C/C++ > > my 64bit int function matches NPY_LONG - which is "long" in C/C++ > > > > but on 32bit Linux > > the 32bit int function matches NPY_LONG > > there is no NPY_INT on 32bit > > Yes there is. Both NPY_INT and NPY_LONG are always there. One matches > the int and one matches the long. > > Perhaps you are confused about what the special defines NPY_INT32 match to? > > The behavior is that the 'long' type gets "first-dibs" then the > 'longlong' type gets a crack. Finally, the 'int' type is chosen. The > first one that matches the bit-type is used. > This explains it - my specific function overloads only one of its two array arguments (i.e. allow many different types) - the second one must be a C "int".[(a 32bit int) - but SWIG matches the "C signature" ] But what is the type number of " > that is: if I have a non overloaded C/C++ function that expects a C "int" > > - i.e. a 32bit int - I have write different function matching rules !!! > > What you need to do is stop trying to match bit-widths and instead match > c-types. That's why NPY_INT and NPY_LONG are both there. If you are referring to use of the sizeof() operator - I'm not doing that. Thanks as always for your quick and careful replies. - Sebastian - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] why is int32 a NPY_LONG on 32bitLinux & NPY_INT on 64bitLinux
Hi, I just ran into more problems with my SWIG typemaps. In the C api the current enum for NPY_INT is 5 NPY_LONG is 7 to match overloaded function I need to check these type values. On 64bit all works fine: my 32bit int function matches NPY_INT - which is "int" in C/C++ my 64bit int function matches NPY_LONG - which is "long" in C/C++ but on 32bit Linux the 32bit int function matches NPY_LONG there is no NPY_INT on 32bit that is: if I have a non overloaded C/C++ function that expects a C "int" - i.e. a 32bit int - I have write different function matching rules !!! REQUEST: Can a 32bit int array get the typenumber code NPY_INT on 32bit Linux !? Then it would work for both 32bit Linux and 64bit Linux the same ! (I don't know about 64bit windows - I have heard that both C int and C long are 64bit - so that is screwed in any case ) Thanks, Sebastian Haase - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] bug is arr.real for byteswapped array
Hi, probably related to this is that arr[2].real is read-only ... I noticed that you cannot assign to arr[2].real : >>> a[2].real =6 Traceback (most recent call last): File "", line 1, in ? TypeError: attribute 'real' of 'genericscalar' objects is not writable >>> a.real[2] =6 >>> >>> a[2].real.flags CONTIGUOUS : True FORTRAN : True OWNDATA : True WRITEABLE : False ALIGNED : True UPDATEIFCOPY : False >>> a.real[2].flags WRITEABLE : False >>> >>> a.real.flags CONTIGUOUS : False FORTRAN : False OWNDATA : False WRITEABLE : True >>> a[2].flags CONTIGUOUS : True FORTRAN : True OWNDATA : True WRITEABLE : False ALIGNED : True UPDATEIFCOPY : False Is the "not writable" restriction necessary ? Thanks, Sebastian Haase On Tuesday 22 August 2006 01:46, Albert Strasheim wrote: > Hello all > > > > > > > >>> a = N.arange(4, dtype='>c8') > > >>> a.imag.max() > > > > 4.60060298822e-41 > > Confirmed on Windows 32-bit with 1.0b4.dev3050. > > I created a ticket here: > > http://projects.scipy.org/scipy/numpy/ticket/265 > > Regards, > > Albert > > > - > 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 > Numpy-discussion@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/numpy-discussion - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] bug is arr.real for byteswapped array
Hi, We just spend some time debugging some numpy image analysis code where we finally noticed that our file was byte-swapped ;-). Even though we got much crazier numbers, the test below already shows one bug in the a.real.max() line. My numpy.__version__ is '1.0b3.dev3015' and this is run on pentium (little endian) Linux (both 64bit and 32bit version give same results): >>> a = N.arange(4, dtype='>c8') >>> a [ 0. +0.e+00j 0. +1.e+00j 0. +2.e+00j 0. +3.e+00j] >>> a.max() (3+0j) >>> a.real.max() 0.0 >>> a.imag.max() 4.60060298822e-41 >>> >>> a = N.arange(4, dtype='>> a.max() (3+0j) >>> a.real.max() 3.0 >>> a.imag.max() 0.0 >>> Can someone test this on a newer SVN version ? Thanks, Sebastian Haase - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] attributes of scalar types - e .g. numpy.int32.itemsize
On Friday 18 August 2006 16:51, Travis Oliphant wrote: > Sebastian Haase wrote: > > On Friday 18 August 2006 15:25, Travis Oliphant wrote: > >> Sebastian Haase wrote: > >>> On Friday 18 August 2006 11:38, Travis Oliphant wrote: > >>>> Sebastian Haase wrote: > >>>>> Hi, > >>>>> array dtype descriptors have an attribute itemsize that gives the > >>>>> total number of bytes required for an item of that dtype. > >>>>> > >>>>> Scalar types, like numy.int32, also have that attribute, > >>>>> but it returns "something else" - don't know what: > >>>>> > >>>>> > >>>>> Furthermore there are *lot's* of more attributes to a scalar dtype, > >>>>> e.g. > >>>> > >>>> The scalar types are actual Python types (classes) whereas the dtype > >>>> objects are instances. > >>>> > >>>> The attributes you are seeing of the typeobject are very useful when > >>>> you have an instance of that type. > >>>> > >>>> With numpy.int32.itemsize you are doing the equivalent of > >>>> numpy.dtype.itemsize > >>> > >>> but why then do I not get the result 4 ? > >> > >> Because it's not a "class" attribute, it's an instance attribute. > >> > >> What does numpy.dtype.itemsize give you? > > > > I'm really sorry for being so dumb - but HOW can I get then the number of > > bytes needed by a given scalar type ? > > Ah, the real question. Sorry for not catching it earlier. I've been in > "make sure this isn't a bug mode" for a long time. > > If you have a scalar type you could create one and then check the itemsize: > > int32(0).itemsize > > Or you could look at the name and parse out how big it is. > > There is also a stored dictionary-like object that returns the number of > bytes for any data-type recognized: > > numpy.nbytes[int32] Thanks, that seems to be a handy "dictionary-like object" Just for the record - in the meantime I found this: >>> N.dtype(N.int32).itemsize 4 Cheers, Sebastian - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] attributes of scalar types - e.g. numpy.int32.itemsize
On Friday 18 August 2006 15:25, Travis Oliphant wrote: > Sebastian Haase wrote: > > On Friday 18 August 2006 11:38, Travis Oliphant wrote: > >> Sebastian Haase wrote: > >>> Hi, > >>> array dtype descriptors have an attribute itemsize that gives the > >>> total number of bytes required for an item of that dtype. > >>> > >>> Scalar types, like numy.int32, also have that attribute, > >>> but it returns "something else" - don't know what: > >>> > >>> > >>> Furthermore there are *lot's* of more attributes to a scalar dtype, > >>> e.g. > >> > >> The scalar types are actual Python types (classes) whereas the dtype > >> objects are instances. > >> > >> The attributes you are seeing of the typeobject are very useful when you > >> have an instance of that type. > >> > >> With numpy.int32.itemsize you are doing the equivalent of > >> numpy.dtype.itemsize > > > > but why then do I not get the result 4 ? > > Because it's not a "class" attribute, it's an instance attribute. > > What does numpy.dtype.itemsize give you? > I'm really sorry for being so dumb - but HOW can I get then the number of bytes needed by a given scalar type ? -S. - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] attributes of scalar types - e .g. numpy.int32.itemsize
On Friday 18 August 2006 11:38, Travis Oliphant wrote: > Sebastian Haase wrote: > > Hi, > > array dtype descriptors have an attribute itemsize that gives the total > > number of bytes required for an item of that dtype. > > > > Scalar types, like numy.int32, also have that attribute, > > but it returns "something else" - don't know what: > > > > > > Furthermore there are *lot's* of more attributes to a scalar dtype, e.g. > > The scalar types are actual Python types (classes) whereas the dtype > objects are instances. > > The attributes you are seeing of the typeobject are very useful when you > have an instance of that type. > > With numpy.int32.itemsize you are doing the equivalent of > numpy.dtype.itemsize but why then do I not get the result 4 ? -Sebastian - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] attributes of scalar types - e.g. numpy.int32.itemsize
Hi, array dtype descriptors have an attribute itemsize that gives the total number of bytes required for an item of that dtype. Scalar types, like numy.int32, also have that attribute, but it returns "something else" - don't know what: >>> a.dtype.itemsize 4 >>> a.dtype.name 'float32' >>> N.int32.itemsize Furthermore there are *lot's* of more attributes to a scalar dtype, e.g. >>> N.int32.data >>> N.int32.argmax() Traceback (most recent call last): File "", line 1, in ? TypeError: descriptor 'argmax' of 'genericscalar' object needs an argument Are those useful ? Thanks, Sebastian Haase - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] request for new array method: arr.abs()
Hi! numpy renamed the *function* abs to absolute. Most functions like mean, min, max, average, ... have an equivalent array *method*. Why is absolute left out ? I think it should be added . Furthermore, looking at some line of code that have multiple calls to absolute [ like f(absolute(a), absolute(b), absolute(c)) ] I think "some people" might prefer less typing and less reading, like f( a.abs(), b.abs(), c.abs() ). One could even consider not requiring the "function call" parenthesis '()' at all - but I don't know about further implications that might have. Thanks, Sebastian Haase PS: is there any performace hit in using the built-in abs function ? - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] please comment on scalar types
Travis Oliphant wrote: > Sebastian Haase wrote: >> Hi! >> I have a record array with a field 'mode' >> Mode is a small integer that I use to choose a "PixelType" >> So I did: >> >>>>> print PixelTypes[ mode ] >>>>> >> TypeError: tuple indices must be integers >> >>>>> pdb.pm() >>>>> >>> /home/haase/PrLinN64/Priithon/Mrc.py(813)MrcMode2numType() >>> >> -> return PixelTypes[ mode ] >> (Pdb) p mode >> 1 >> (Pdb) p type(mode) >> >> (Pdb) p isinstance(mode, int) >> False >> >> Since numpy introduced special scalar types a simple statement like this >> doesn't work anymore ! Would it work if int32scalar was derived from int ? >> I >> actually thought it was ... >> > It does sub-class from int unless you are on a system where a c-long is > 64-bit then int64scalar inherits from int. > > On my 32-bit system: > > isinstance(array([1,2,3])[0],int) is true. > > > > -Travis I see - yes I forgot - that test was indeed run on 64bit Linux. And that automatically implies that there a 32bit-int cannot be used in place of a "normal python integer" !? I could see wanting to use int16 or event uint8 as a tuple index. Logically a small type would be save to use in place of a bigger one ... - Sebastian - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] please comment on scalar types
Hi! I have a record array with a field 'mode' Mode is a small integer that I use to choose a "PixelType" So I did: >>> print PixelTypes[ mode ] TypeError: tuple indices must be integers >>> pdb.pm() > /home/haase/PrLinN64/Priithon/Mrc.py(813)MrcMode2numType() -> return PixelTypes[ mode ] (Pdb) p mode 1 (Pdb) p type(mode) (Pdb) p isinstance(mode, int) False Since numpy introduced special scalar types a simple statement like this doesn't work anymore ! Would it work if int32scalar was derived from int ? I actually thought it was ... Comments ? - Sebastian Haase - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] How to share memory when bArr is smaller-sized than aArr
Hi, in numarray I could do this >>> import numarray as na >>> a = na.arange(10) >>> b = na.array(a._data, type=na.int32, shape=8) b would use the beginning part of a. This is actually important for inplace FFT (where in real-to-complex-fft the input has 2 "columns" more memory than the output) I found that in numpy there is no shape argument in array() at all anymore ! How can this be done with numpy ? Thanks, Sebastian Haase - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] trivial question: how to compare dtype - but ignoring byteorder ?
On Monday 24 July 2006 12:36, Travis Oliphant wrote: > Sebastian Haase wrote: > > Hi, > > if I have a numpy array 'a' > > and say: > > a.dtype == numpy.float32 > > > > Is the result independent of a's byteorder ? > > (That's what I would expect ! Just checking !) > > I think I misread the question and saw "==" as "=" > > But, the answer I gave should still help: the byteorder is a property > of the data-type. There is no such thing as "a's" byteorder. Thus, > numpy.float32 (which is actually an array-scalar and not a true > data-type) is interepreted as a machine-byte-order IEEE floating-point > data-type with 32 bits. Thus, the result will depend on whether or not > a.dtype is machine-order or not. > > -Travis Hi, I just realized that this question did actually not get sorted out. Now I'm just about to convert my code to compare arr.dtype.type to the (default scalar!) dtype numpy.uint8 like this: if self.img.dtype.type == N.uint8: self.hist_min, self.hist_max = 0, 1<<8 elif self.img.dtype.type == N.uint16: self.hist_min, self.hist_max = 0, 1<<16 ... This seems to work independent of byteorder - (but looks ugly(er)) ... Is this the best way of doing this ? - Sebastian Haase - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] concersion warning: numarray to numpy - now array defaults to not copy
SORRY FOR THE CONFUSION !! I must have been on drugs ! Maybe I did not get enough sleep. asarray() is the function that does not create a copy - both in numpy and in numarray. Sorry, Sebastian Travis Oliphant wrote: > Sebastian Haase wrote: >> Hi, >> I just wanted to point out that the default of the copy argument changed >> from numpy to numarray. >> Don't forget about that in the conversion script ... >> > > Hmm.. I don't see what you are talking about. The default for the copy > argument in the array function is still copy=True. If there is > something else then it is a bug. > > -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 > Numpy-discussion@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/numpy-discussion - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] concersion warning: numarray to numpy - now array defaults to not copy
Hi, I just wanted to point out that the default of the copy argument changed from numpy to numarray. Don't forget about that in the conversion script ... Cheers, Sebastian Haase - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] Does a C-API mismatch require a fatal(!) program termination !? (crash on import !)
Hi,
I was just wondering if it might be possible to raise an ImportError
instead of terminating python;
look what I get:
[EMAIL PROTECTED]:~: python
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> import sys
>>> sys.path.append("PrCyg")
>>> from Priithon import seb
RuntimeError: module compiled against version 100 of C-API but this
version
of numpy is 102
Fatal Python error: numpy.core.multiarray failed to import... exiting.
This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
[EMAIL PROTECTED]:~:
Assume that you are running an interactive session, analysing some
important[;-)] data. Then you think: "Oh, I should try this one (maybe
little old) module on this" ... so you try to import ... and ...
suddenly the entire python application crashes.
When your shell application runs without a terminal you don't even get
to read the error message !
- Sebastian Haase
-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] is cygwin patch from from ticket #114 still working !?
Sebastian Haase wrote: > This is what I get ? > > [EMAIL PROTECTED]:~/myCVS/numpy: patch.exe -b -p0 < ~/winbuilding3.diff > patching file numpy/distutils/misc_util.py > Reversed (or previously applied) patch detected! Assume -R? [n] > > Thanks, > Sebastian OK - I think I can answer myself. No, but it's not needed anymore ! It looks like it compiled fine without applying it - Sebastian - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] is cygwin patch from from ticket #114 still working !?
This is what I get ? [EMAIL PROTECTED]:~/myCVS/numpy: patch.exe -b -p0 < ~/winbuilding3.diff patching file numpy/distutils/misc_util.py Reversed (or previously applied) patch detected! Assume -R? [n] Thanks, Sebastian - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] bug ! arr.mean() outside arr.min() .. arr.max() range
Travis Oliphant wrote:
> Sebastian Haase wrote:
>> Hi!
>> b is a non-native byteorder array of type int16
>> but see further down: same after converting to native ...
>>
>>>>> repr(b.dtype)
>>>>>
>> 'dtype('>i2')'
>>
>
> The problem is no-doubt related to "wrapping" for integers. Your total is
> getting too large to fit into the reducing data-type.
>
> What does
>
> d.sum() give you?
I can't check that particular array until Monday...
>
> You can add d.mean(dtype='d') to force reduction over doubles.
This almost sound like what I reported is something like a feature !?
Is there a sensible / generic way to avoid those "accident" ? Maybe it
must be the default to reduce int8, uint8, int16, uint16 into doubles !?
- Sebastian
-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] bug ! arr.mean() outside arr.min() .. arr.max() range
Hi!
b is a non-native byteorder array of type int16
but see further down: same after converting to native ...
>>> repr(b.dtype)
'dtype('>i2')'
>>> b.dtype.isnative
False
>>> b.shape
(38, 512, 512)
>>> b.max()
1279
>>> b.min()
0
>>> b.mean()
-65.279878014
>>> U.mmms(b) # my "useful" function for min,max,mean,stddev
(0, 1279, 365.878016723, 123.112379036)
>>> c = b.copy()
>>> c.max()
1279
>>> c.min()
0
>>> c.mean()
-65.279878014
>>> d = N.asarray(b, b.dtype.newbyteorder('='))
>>> d.dtype.isnative
True
>>>
>>> >>> d.max()
1279
>>> d.min()
0
>>> d.mean()
-65.279878014
>>> N.__version__
'1.0b2.dev2996'
>>>
Sorry that I don't have a simple example - what could be wrong !?
- Sebastian Haase
-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.ascontiguousarray on byteswapped data !?
On Thursday 10 August 2006 21:32, Sebastian Haase wrote:
> Travis Oliphant wrote:
> > Sebastian Haase wrote:
> >> Hi,
> >> Does numpy.ascontiguousarray(arr) "fix" the byteorder when arr is
> >> non-native byteorder ?
> >>
> >> If not, what functions does ?
> >
> > It can if you pass in a data-type with the right byteorder (or use a
> > native built-in data-type).
> >
> > In NumPy, it's the data-type that carries the "byte-order"
> > information.So, there are lot's of ways to "fix" the byte-order.
>
> So then the question is: what is the easiest way to say:
> give me the equivalent type of dtype, but with byteorder '<' (or '=') !?
> I would be cumbersome (and ugly ;-) ) if one would have to "manually
> assemble" such a construct every time ...
I just found this in myCVS/numpy/numpy/core/tests/test_numerictypes.py
def normalize_descr(descr):
"Normalize a description adding the platform byteorder."
out = []
for item in descr:
dtype = item[1]
if isinstance(dtype, str):
if dtype[0] not in ['|','<','>']:
onebyte = dtype[1:] == "1"
if onebyte or dtype[0] in ['S', 'V', 'b']:
dtype = "|" + dtype
else:
dtype = byteorder + dtype
if len(item) > 2 and item[2] > 1:
nitem = (item[0], dtype, item[2])
else:
nitem = (item[0], dtype)
out.append(nitem)
elif isinstance(item[1], list):
l = []
for j in normalize_descr(item[1]):
l.append(j)
out.append((item[0], l))
else:
raise ValueError("Expected a str or list and got %s" % \
(type(item)))
return out
Is that what I was talking about !? It's quite a big animal.
Would this be needed "everytime" I want to get a "systembyte-ordered version"
of a given type !?
- Sebastian
>
> > Of course there is still the difference between "fixing" the byte-order
> > and simply "viewing" the memory in the correct byte-order. The former
> > physically flips bytes around, the latter just flips them on calculation
> > and presentation.
>
> I understand. I need something that I can feed into my C routines that
> are to dumb to handle non-contiguous or byte-swapped data .
>
> - Sebastian
-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.ascontiguousarray on byteswapped data !?
Travis Oliphant wrote: > Sebastian Haase wrote: >> Hi, >> Does numpy.ascontiguousarray(arr) "fix" the byteorder when arr is >> non-native byteorder ? >> >> If not, what functions does ? >> > > It can if you pass in a data-type with the right byteorder (or use a > native built-in data-type). > > In NumPy, it's the data-type that carries the "byte-order" > information.So, there are lot's of ways to "fix" the byte-order. > So then the question is: what is the easiest way to say: give me the equivalent type of dtype, but with byteorder '<' (or '=') !? I would be cumbersome (and ugly ;-) ) if one would have to "manually assemble" such a construct every time ... > Of course there is still the difference between "fixing" the byte-order > and simply "viewing" the memory in the correct byte-order. The former > physically flips bytes around, the latter just flips them on calculation > and presentation. I understand. I need something that I can feed into my C routines that are to dumb to handle non-contiguous or byte-swapped data . - Sebastian - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] format typestr for "String" ( 10 strings: '10a80' ) gives just 'None'
Travis Oliphant wrote: > Sebastian Haase wrote: >> This is what I get: It claims that the 'title' field (the last one) >> is 10 times 'S80' but trying to read that array from the first (and >> only) record (a.Mrc._hdrArray.title[0]) I just get None... >> > Hopefully that problem is resolved now. I should discuss a little bit > about how the 10-element sub-array field is handled by NumPy. > > Any sub-array present causes the shape of the returned array for a given > field to grow by the sub-array size. > > So, in your case you have a (10,)-shape subarray in the title field. > > Thus if g is a record-array of shape gshape g.title will be a chararray > of shape gshape + (10,) > > In this case of a 1-d array with 1-element we have gshape = (1,). > Therefore, g.title will be a (1,10) chararray and g[0].title will be a > (10,)-shaped chararray. > > -Travis > Thanks, for fixing everything so quickly - I'll test it tomorrow. BTW: are you intentionally sending the last few messages ONLY to me and NOT to the mailing list !? I actually think the mailing should be configured that a "normal reply" automatically defaults to go only (!) to the list. (I'm on some other lists that know how to do that). Who would be able to change that for the numpy and the scipy list !? Thanks again, Sebastian - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] numpy.ascontiguousarray on byteswapped data !?
Hi, Does numpy.ascontiguousarray(arr) "fix" the byteorder when arr is non-native byteorder ? If not, what functions does ? - Sebastian Haase - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] format typestr for "String" ( 10 strings: '10a80' ) gives just 'None'
On Thursday 10 August 2006 16:57, Travis Oliphant wrote:
> Sebastian Haase wrote:
> > Hi,
> > trying to convert my memmap - records - numarray code for reading a
> > image file format (Mrc).
> > There are 10 fields of strings (each 80 chars long) in the header:
> > in numarray I used the format string '10a80'
> > This results in a single value in numpy.
> > Same after changing it to '10S80'.
> >
> > Am I doing something wrong !?
>
> Not that I can see. But, it's possible that there is a
> misunderstanding of what '10a80' represents.
>
> What is giving you the value?
>
> For example, I can create a file with 10, 80-character strings and open it
> using memmap and a data-type of
>
> dt = numpy.dtype('10a80')
>
> and it seems to work fine.
>
> -Travis
This is what I get: It claims that the 'title' field (the last one) is 10
times 'S80' but trying to read that array from the first (and only) record
(a.Mrc._hdrArray.title[0]) I just get None...
>>> a=Mrc.bindFile('Heather2/GFPtublive-Vecta43')
TODO: byteorder
>>> repr(a.Mrc._hdrArray.dtype)
'dtype([('Num', '>> a.Mrc._hdrArray.NumTitles
[3]
>>> a.Mrc._hdrArray.NumTitles[0]
3
>>> type(a.Mrc._hdrArray.title[0])
>>> type(a.Mrc._hdrArray.title[1])
Traceback (most recent call last):
File "", line 1, in ?
File "/home/haase/qqq/lib/python/numpy/core/defchararray.py", line 45, in
__getitem__
val = ndarray.__getitem__(self, obj)
IndexError: index out of bounds
I get the same on byteswapped data and non-byteswapped data.
-Sebastian
-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] format typestr for "String" ( 10 strings: '10a80' ) gives just 'None'
Hi, trying to convert my memmap - records - numarray code for reading a image file format (Mrc). There are 10 fields of strings (each 80 chars long) in the header: in numarray I used the format string '10a80' This results in a single value in numpy. Same after changing it to '10S80'. Am I doing something wrong !? Thanks, Sebastian Haase - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] how to reference Numerical Python in a scientific publication
Hi, we are using numerical python as an integral part of a microscope development project over last few years. So far we have been using exclusively numarray but now I decided it's time to slowly but sure migrate to numpy. What is the proper way to reference these packages ? Thanks to everyone involved, Sebastian Haase UCSF - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] bug !? dtype type_descriptor does not accept zero length tuple
Travis Oliphant wrote:
> Sebastian Haase wrote:
>> On Wednesday 09 August 2006 15:45, you wrote:
>>
>>> Sebastian Haase wrote:
>>>
>>>> On Wednesday 09 August 2006 15:18, Travis Oliphant wrote:
>>>>
>>>>> If numarray supported it, then we should get NumPy to support it as
>>>>> well
>>>>> unless there is a compelling reason not to. I can't think of any
>>>>> except
>>>>> that it might be hard to make it work. What is '0i4' supposed to mean
>>>>> exactly? Do you get a zero-sized field or is the field not included?
>>>>> I think the former will be much easier than the latter. Would
>>>>> that be
>>>>> O.K.?
>>>>>
>>>> That's exactly what numarray did. The rest of my code is assuming that
>>>> all fields exist (even if they are empty). Otherwise I get a name
>>>> error which is worse than getting an empty array.
>>>>
>>> Do you have a simple code snippet that I could use as a test?
>>>
>>> -Travis
>>>
>>
>> I think this should do it:
>>
>> a = N.arange(10, dtype=N.float32)
>> a.shape = 5,2
>> type_descr = [("int", "<0i4"),("float", "<2f4")]
>> a.dtype = type_descr
>>
>>
>
> I'm not sure what a.shape = (5,2) is supposed to do. I left it in the
> unit-test out because assigning to the data-type you just defined
> already results in
>
> a['float'].shape being (5,2)
>
> If it is left in, then an extra dimension is pushed in and
>
> a['float'].shape is (5,1,2)
>
>
> This is due to the default behavior of assigning data-types when the new
> data-type has a larger but compatibile itemsize then the old itemsize.
I have to admit that I don't understand that statement. I thought - just
"visually" - that a.shape = 5,2 would make a "table" with 2 columns.
Then I could go on and give those columns names...
Or is the problem that the type "2f4" refers to (some sort of) a "single
column" with 2 floats grouped together !?
Thanks for implementing it so quickly,
Sebastian Haase
-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] bug !? dtype type_descriptor does not accept zero length tuple
On Wednesday 09 August 2006 15:18, Travis Oliphant wrote:
> Sebastian Haase wrote:
> > Hi!
> > I have a problem with record array type descriptor.
> > With numarray this used to work.
> > My records made of n integers and m floats. So I used to be able
> > specify formats="%di4,%df4"%(self.numInts,self.numFloats) in numarray
> > which would translate to
> > byteorder = self.isByteSwapped and '>' or '<'
> > type_descr = [("int", "%s%di4" %(byteorder,self.numInts)),
> > ("float", "%s%df4" %(byteorder,self.numFloats))]
> >
> > The problem occurs when numInts or numFloats is zero !?
> > Could it numpy be changed to silectly accept this case
> > Here is the complete traceback + some debug info:
>
> If numarray supported it, then we should get NumPy to support it as well
> unless there is a compelling reason not to. I can't think of any except
> that it might be hard to make it work. What is '0i4' supposed to mean
> exactly? Do you get a zero-sized field or is the field not included?
> I think the former will be much easier than the latter. Would that be
> O.K.?
That's exactly what numarray did. The rest of my code is assuming that all
fields exist (even if they are empty). Otherwise I get a name error which is
worse than getting an empty array.
Thanks,
Sebastian Haase
-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] bug !? dtype type_descriptor does not accept zero length tuple
Hi!
I have a problem with record array type descriptor.
With numarray this used to work.
My records made of n integers and m floats. So I used to be able specify
formats="%di4,%df4"%(self.numInts,self.numFloats) in numarray which would
translate to
byteorder = self.isByteSwapped and '>' or '<'
type_descr = [("int", "%s%di4" %(byteorder,self.numInts)),
("float", "%s%df4" %(byteorder,self.numFloats))]
The problem occurs when numInts or numFloats is zero !?
Could it numpy be changed to silectly accept this case
Here is the complete traceback + some debug info:
'>0i4'Traceback (most recent call last):
File "", line 1, in ?
File "/home/haase/PrLinN/Priithon/Mrc.py", line 56, in bindFile
a = Mrc(fn, mode)
File "/home/haase/PrLinN/Priithon/Mrc.py", line 204, in __init__
self.doExtHdrMap()
File "/home/haase/PrLinN/Priithon/Mrc.py", line 271, in doExtHdrMap
self.extHdrArray.dtype = type_descr
File "/home/haase/qqq/lib/python/numpy/core/records.py", line 194, in
__setattr__
return object.__setattr__(self, attr, val)
TypeError: invalid data-type for array
>>> U.debug()
> /home/haase/qqq/lib/python/numpy/core/records.py(196)__setattr__()
-> pass
(Pdb) l
191
192 def __setattr__(self, attr, val):
193 try:
194 return object.__setattr__(self, attr, val)
195 except AttributeError: # Must be a fieldname
196 -> pass
197 fielddict = sb.ndarray.__getattribute__(self,'dtype').fields
198 try:
199 res = fielddict[attr][:2]
200 except (TypeError,KeyError):
201 raise AttributeError, "record array has no attribute %s" %
attr
(Pdb) p val
[('int', '>0i4'), ('float', '>2f4')]
(Pdb) p attr
'dtype'
Thanks,
Sebastian Haase
-
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
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] how to reference Numerical Python in a scientific publication
Hi, we are using numerical python as an integral part of a microscope development project over last few years. So far we have been using exclusively numarray but now I decided it's time to slowly but sure migrate to numpy. What is the proper way to reference these packages ? Thanks to everyone involved, Sebastian Haase UCSF - 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 Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] a**2 60 times slower than a*a - ONLY for int32
Hi,
>>> a=N.random.poisson(N.arange(1e6)+1)
>>> U.timeIt('a**2')
0.59
>>> U.timeIt('a*a')
0.01
>>> a.dtype
int32
my U.timeIt function just returns the difference of time in seconds before and
after evaluation of the string.
For
>>> c=N.random.normal(1000, 100, 1e6)
>>> c.dtype
float64
i get .014 seconds for either c*c or c**2 (I averaged over 100 runs). After
converting this to float32 I get 0.008 secs for both.
Can the int32 case be speed up the same way !?
Thanks,
Sebastian Haase
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] bug tracker to cc email address by default
Hi, Is it possible to have 'cc'-ing the poster of a bug ticket be the default !? Or is/can this be set in a per user preference somehow ? Thanks, Sebastian Haase - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] link to numpy ticket tracker ontp the wiki
Hi! I would like to suggest to put a link to the bug/wishlist tracker web site on the scipy.org wiki site. http://projects.scipy.org/scipy/numpy/ticket I did not do it myself because I could not decide what the best place for it would - I think it should be rather exposed ... The only link I could find was somewhere inside an FAQ for the SciPy package and it was only for the scipy-bug tracker. Thanks, Sebastian Haase - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] help! type 'float64scalar' is not type 'float'
On Thursday 03 August 2006 13:19, Travis Oliphant wrote:
> Sebastian Haase wrote:
> >On Wednesday 02 August 2006 22:43, Travis Oliphant wrote:
> >>Sebastian Haase wrote:
> >>>Thanks,
> >>>I just found
> >>>numpy.isscalar() and numpy.issctype() ?
> >>>These sound like they would do what I need - what is the difference
> >>>between the two ?
> >>
> >>Oh, yeah.
> >>
> >>numpy.issctype works with type objects
> >>numpy.isscalar works with instances
> >>
> >>Neither of them distinguish between scalars and "numbers."
> >>
> >>If you get errors with isscalar it would be nice to know what they are.
> >
> >I'm still trying to reproduce the exception, but here is a first
> > comparison that - honestly - does not make much sense to me:
> >(type vs. instance seems to get mostly the same results and why is there
> > a difference with a string ('12') )
>
> These routines are a little buggy. I've cleaned them up in SVN to
> reflect what they should do.When the dtype object came into
> existence a lot of what the scalar types where being used for was no
> longer needed. Some of these functions weren't updated to deal with
> the dtype objects correctly either.
>
> This is what you get now:
> >>> import numpy as N
> >>> N.isscalar(12)
>
> True
>
> >>> N.issctype(12)
>
> False
>
> >>> N.isscalar('12')
>
> True
>
> >>> N.issctype('12')
>
> False
>
> >>> N.isscalar(N.array([1]))
>
> False
>
> >>> N.issctype(N.array([1]))
>
> False
>
> >>> N.isscalar(N.array([1]).dtype)
>
> False
>
> >>> N.issctype(N.array([1]).dtype)
>
> True
>
> >>> N.isscalar(N.array([1])[0].dtype)
>
> False
>
> >>> N.issctype(N.array([1])[0].dtype)
>
> True
>
> >>> N.isscalar(N.array([1])[0])
>
> True
>
> >>> N.issctype(N.array([1])[0])
>
> False
>
>
> -Travis
Great!
Just wanted to point out that '12' is a scalar -
I suppose that's what it is.
(To determine if something is a number it seems
best to implement a try: ... except: ... something like float(x) - as Chris
has suggested )
-S.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] help! type 'float64scalar' is not type 'float'
On Wednesday 02 August 2006 22:43, Travis Oliphant wrote:
> Sebastian Haase wrote:
> > Thanks,
> > I just found
> > numpy.isscalar() and numpy.issctype() ?
> > These sound like they would do what I need - what is the difference
> > between the two ?
>
> Oh, yeah.
>
> numpy.issctype works with type objects
> numpy.isscalar works with instances
>
> Neither of them distinguish between scalars and "numbers."
>
> If you get errors with isscalar it would be nice to know what they are.
I'm still trying to reproduce the exception, but here is a first comparison
that - honestly - does not make much sense to me:
(type vs. instance seems to get mostly the same results and why is there a
difference with a string ('12') )
>>> N.isscalar(12)
True
>>> N.issctype(12)
True
>>> N.isscalar('12')
True
>>> N.issctype('12')
False
>>> N.isscalar(N.array([1]))
False
>>> N.issctype(N.array([1]))
True
>>> N.isscalar(N.array([1]).dtype)
False
>>> N.issctype(N.array([1]).dtype)
False
# apparently new 'scalars' have a dtype attribute !
>>> N.isscalar(N.array([1])[0].dtype)
False
>>> N.issctype(N.array([1])[0].dtype)
False
>>> N.isscalar(N.array([1])[0])
True
>>> N.issctype(N.array([1])[0])
True
-Sebastian
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] help! type 'float64scalar' is not type 'float'
Travis Oliphant wrote: > Sebastian Haase wrote: >> Hi! >> I just finished maybe a total of 5 hours tracking down a nasty bug. >> >> Finally I traced the problem down to a utility function: >> "is_number" - it is simply implemented as >> def is_number(val): >> return (type(val) in [type(0.0),type(0)]) >> >> As I said - now I finally saw that I always got >> False since the type of my number (0.025) is >> >> and that's neither nor >> >> OK - how should this have been done right ? >> >> > > Code that depends on specific types like this is going to be hard to > maintain in Python because many types could reasonably act like a > number. I do see code like this pop up from time to time and it will > bite you more with NumPy (which has a whole slew of scalar types). > > The scalar-types are in a hierarchy and so you could replace the code with > > def is_number(val): > return isinstance(val, (int, float, numpy.number)) > > But, this will break with other "scalar-types" that it really should > work with. It's best to look at what is calling is_number and think > about what it wants to do with the object and just try it and catch the > exception. > > -Travis > Thanks, I just found numpy.isscalar() and numpy.issctype() ? These sound like they would do what I need - what is the difference between the two ? (I found that issctype worked OK while isscalar gave some exception in some cases !? ) - Sebastian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] Handling of backward compatibility
Travis Oliphant wrote: > Torgil Svensson wrote: > >>> They are supposed to have different defaults because the functional >>> forms are largely for backward compatibility where axis=0 was the default. >>> >>> -Travis >>> >>> >> Isn't backwards compatibility what "oldnumeric" is for? >> >> >> > > As this discussion indicates there has been a switch from numpy 0.9.8 to > numpy 1.0b of how to handle backward compatibility. Instead of > importing old names a new sub-package numpy.oldnumeric was created. > This mechanism is incomplete in the sense that there are still some > backward-compatible items in numpy such as defaults on the axis keyword > for functions versus methods and you still have to make the changes that > convertcode.py makes to the code to get it to work. > > I'm wondering about whether or not some additional effort should be > placed in numpy.oldnumeric so that replacing Numeric with > numpy.oldnumeric actually gives no compatibility issues (i.e. the only > thing you have to change is replace imports with new names). In > other words a simple array sub-class could be created that mimics the > old Numeric array and the old functions could be created as well with > the same arguments. > > The very same thing could be done with numarray. This would make > conversion almost trivial. > > Then, the convertcode script could be improved to make all the changes > that would take a oldnumeric-based module to a more modern numpy-based > module. A similar numarray script could be developed as well. > > What do people think? Is it worth it? This could be a coding-sprint > effort at SciPy. > > > -Travis Hi, Just as thought of cautiousness: If people actually get "too much" encouraged to just always say " from numpy.oldnumeric import * " or as suggested maybe soon also something like " from numpy.oldnumarray import * " - could this not soon lead to a great state of confusion when later people on this mailing list ask questions and nobody really knows which of the submodules they are referring to !? Recently someone (Torgil Svensson) here suggested to unify the default argument between a method and a function - I think the discussion was about numpy.var and it's "axis" argument. I would be a clear +1 on unifying these and have a clean design of numpy. Consequently the old way of different defaults should be absorbed by the oldnumeric sub module. All I'm saying then is that this could cause confusion later on - and therefore the whole idea of "easy backwards compatibility" should be qualified by encouraging people to adopt the most problematic changes (like new default values) rather sooner than later. I'm hoping that numpy will find soon an increasingly broader acceptance in the whole Python community (and the entire scientific community for that matter ;-) ). Thanks for all your work, Sebastian Haase - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] help! type 'float64scalar' is not type 'float'
Hi! I just finished maybe a total of 5 hours tracking down a nasty bug. So I thought I would share this: I'm keeping a version of (old) SciPy's 'plt' module around. (I know about matplotlib - anyway - ...) I changed the code some time ago from Numeric to numarray - no problem. Now I switched to numpy ... and suddenly the zooming does not work anymore: it always zooms to "full view". Finally I traced the problem down to a utility function: "is_number" - it is simply implemented as def is_number(val): return (type(val) in [type(0.0),type(0)]) As I said - now I finally saw that I always got False since the type of my number (0.025) is and that's neither nor OK - how should this have been done right ? Anyway, I'm excited about the new numpy and am looking forward to it's progress Thanks, Sebastian Haase - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] how to get an array with "varying" poisson distribution
On Tuesday 25 July 2006 15:09, Travis Oliphant wrote: > Sebastian Haase wrote: > >Hi, > >Essentially I'm looking for the equivalent of what was in numarray: > >from numarray import random_array > >random_array.poisson(arr) > > I've just updated the mtrand library to allow this. It will be in 1.0b2 > > So, if you have latest SVN you can do > > from numpy import random > random.poisson(arr) > > to do what you want. > > > > -Travis Great - thanks - you are awesome !! -Seb. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] numpy scalar types
Hi, I just ran a simple test which I think would be of general interest. It's about types and what there names are in the numpy module (and how many different names there are for a given type !!) Cheers, Sebastian Haase (maybe there is a good place in the wiki for this !?) >>> N.csingle >>> N.cdouble >>> N.cfloat and all together !! >>> for tt in N.ScalarType: ... l=[k for k,v in N.__dict__.iteritems() if v == tt] ... print len(l), tt, l ... 0 [] 0 [] 0 [] 0 [] 0 [] 0 [] 0 [] 0 [] 2 ['longlong', 'int64'] 2 ['int16', 'short'] 2 ['int32', 'int_'] 2 ['uint', 'uint32'] 2 ['unicode_', 'unicode0'] 2 ['complex64', 'csingle'] 3 ['intp', 'intc', 'int0'] 4 ['cfloat', 'complex_', 'cdouble', 'complex128'] 3 ['string', 'str_', 'string0'] 3 ['float96', 'longfloat', 'longdouble'] 2 ['ushort', 'uint16'] 2 ['object0', 'object_'] 3 ['double', 'float64', 'float_'] 2 ['byte', 'int8'] 2 ['uint8', 'ubyte'] 2 ['bool8', 'bool_'] 2 ['float32', 'single'] 3 ['complex192', 'clongdouble', 'clongfloat'] 3 ['uintc', 'uint0', 'uintp'] 2 ['uint64', 'ulonglong'] 2 ['void', 'void0'] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] trivial question: how to compare dtype - but ignoring byteorder ?
On Monday 24 July 2006 16:42, Bill Baxter wrote:
> > > And I think byteorder matters when comparing dtypes:
> > > >>> numpy.dtype('>f4') == numpy.dtype(' > >
> > > False
>
> Oh -- that '<' part is indicating *byte order* ?!
> I thought it was odd that numpy could only tell me the type was "less
> than f4", which I assumed must be shorthand for "less than or equal to
> f4". Makes much more sense now!
>
> --bb
Which is why I was trying to change the str() representation of a type to
something more intuitive.
If nothing else one could even leave
repr(a.dtype) --> ' 'int32 (little endian)'
I do now understand that (as opposed to numarray and numeric) the byteorder is
now part of the data-type - but I would really encourage keeping the string
for such an important (and often used !) thing more readable than
"http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Numpy-discussion mailing list
Numpy-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] weave - was:Re: how to get an array with "varying" poisson distribution
On Monday 24 July 2006 14:20, Robert Kern wrote: > Sebastian Haase wrote: > > Hi, > > Essentially I'm looking for the equivalent of what was in numarray: > > from numarray import random_array > > random_array.poisson(arr) > > > > That is: if for example arr is a 256x256 array of positive integers, then > > this returns a new array of random numbers than are drawn according to > > the poisson statistics where arr's value at coordinate y,x determines > > the mean of the poisson distribution used to generate a new value for > > y,x. > > I'm afraid that at this point in time, the distributions only accept scalar > values for the parameters. I've thought about reimplementing the > distribution functions as ufuncs, but that's a hefty chunk of work that > won't happen for 1.0. > > I'm afraid that, for now, you're stuck with iterating over the values. Thanks for the reply - maybe this my time to get into weave ;-) Question about distributing and/or making "python-only-changes". How can one distribute modules using weave to other people who might NOT have a C compiler installed ? And further: when I change parts of that module that should not require a recompiling of the C part - is weave smart enough to recognise this ? Thanks, Sebastian (Oops, I just realized that this would be a question maybe for the SciPy list ... I'll assume that it's OK) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
Re: [Numpy-discussion] how add new attribute to a numpy array object ?
On Monday 24 July 2006 12:23, Travis Oliphant wrote: > Sebastian Haase wrote: > > Hi, > > I have a (medical) image file. > > I wrote a nice interface based on memmap using numarray. > > The class design I used was essentially to return a numarray array > > object with a new "custom" attribute giving access to special > > information about the base file. > > > > Now with numpy I noticed that a numpy object does not allow adding new > > attributes !! (How is this ? Why ?) > > > > Travis already suggested (replying to one of my last postings) to create > > a new sub class of numpy.ndarray. > > > > But how do I initialize an object of my new class to be "basically > > identically to" an existing ndarray object ? > > Normally I could do > > class B(N.ndarray): > > pass > > a=N.arange(10) > > a.__class__ = B > > > > BUT I get this error: > > #>>> a.__class__ = B > > Traceback (most recent call last): > >File "", line 1, in ? > > TypeError: __class__ assignment: only for heap types > > > > What is a "heap type" ? Why ? How can I do what I want ? > > A heap type is one created in Python (i.e. not builtin with C). > > You should be able to do > > a = a.view(B) > > -Travis Thanks - (I'm just replying because I assume your helpful answer was mistakenly sent to me only and did not make it to the list) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] how to get an array with "varying" poisson distribution
Hi, Essentially I'm looking for the equivalent of what was in numarray: from numarray import random_array random_array.poisson(arr) That is: if for example arr is a 256x256 array of positive integers, then this returns a new array of random numbers than are drawn according to the poisson statistics where arr's value at coordinate y,x determines the mean of the poisson distribution used to generate a new value for y,x. [[This is needed e.g. to simulate quantum noise in CCD images. Each pixel has different amount of noise depending of what it's (noise-free) "input" value was.]] Thanks, Sebastian Haase - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
[Numpy-discussion] numpy.prod() vs. numpy.product()
Hi, Are numpy.product() and numpy.prod() doing the exact same thing ? If yes, why are they pointing to two different functions ? >>> N.prod >>> N.product Thanks, Sebastian Haase - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
