You can subscribe to this list here.
2000 |
Jan
(8) |
Feb
(49) |
Mar
(48) |
Apr
(28) |
May
(37) |
Jun
(28) |
Jul
(16) |
Aug
(16) |
Sep
(44) |
Oct
(61) |
Nov
(31) |
Dec
(24) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(56) |
Feb
(54) |
Mar
(41) |
Apr
(71) |
May
(48) |
Jun
(32) |
Jul
(53) |
Aug
(91) |
Sep
(56) |
Oct
(33) |
Nov
(81) |
Dec
(54) |
2002 |
Jan
(72) |
Feb
(37) |
Mar
(126) |
Apr
(62) |
May
(34) |
Jun
(124) |
Jul
(36) |
Aug
(34) |
Sep
(60) |
Oct
(37) |
Nov
(23) |
Dec
(104) |
2003 |
Jan
(110) |
Feb
(73) |
Mar
(42) |
Apr
(8) |
May
(76) |
Jun
(14) |
Jul
(52) |
Aug
(26) |
Sep
(108) |
Oct
(82) |
Nov
(89) |
Dec
(94) |
2004 |
Jan
(117) |
Feb
(86) |
Mar
(75) |
Apr
(55) |
May
(75) |
Jun
(160) |
Jul
(152) |
Aug
(86) |
Sep
(75) |
Oct
(134) |
Nov
(62) |
Dec
(60) |
2005 |
Jan
(187) |
Feb
(318) |
Mar
(296) |
Apr
(205) |
May
(84) |
Jun
(63) |
Jul
(122) |
Aug
(59) |
Sep
(66) |
Oct
(148) |
Nov
(120) |
Dec
(70) |
2006 |
Jan
(460) |
Feb
(683) |
Mar
(589) |
Apr
(559) |
May
(445) |
Jun
(712) |
Jul
(815) |
Aug
(663) |
Sep
(559) |
Oct
(930) |
Nov
(373) |
Dec
|
From: Erin S. <eri...@gm...> - 2006-10-26 18:47:38
|
Hi all - I think I speak for many when I say that this is a huge step for those who have desired to switch to numerical python from other languages (IDL, MATLAB, etc) but have been waiting for that 1.0 release. Many thanks to everyone involved. Erin Sheldon On 10/26/06, Charles R Harris <cha...@gm...> wrote: > > > On 10/26/06, Travis E. Oliphant <oli...@ie...> wrote: > > > > We are very pleased to announce the release of NumPy 1.0 available for > > download at http://www.numpy.org > > Congratulations, Travis. Numpy was a needed unification and involved an > enormous amount of work, most of it your own. Thanks for taking this on. > > Chuck > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > _______________________________________________ > Numpy-discussion mailing list > Num...@li... > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > > > |
From: Colin J. W. <cj...@sy...> - 2006-10-26 18:35:14
|
Ivan Vilata i Balaguer wrote: > Hi all. The attached diff makes some changes to Numexpr support for > booleans. The changes and their rationale are below. > > 1. New ``True`` and ``False`` boolean constants. This is so that 1 and > 0 are always proper integer constants. It is also for completeness, > but I don't envision any usage for them that couldn't be expressed > without the constants. > I'm puzzled. Python already has constants True and False of the bool type. bool is a subclass of the int type. Any instance of the bool type can be converted to the int type. >>> a=1==0 >>> type(a) <type 'bool'> >>> int(a) 0 >>> a False >>> Colin W. > 2. The only comparisons supported with booleans are ``==`` and ``!=``, > so that you can compare boolean variables. Just as NumPy supports > complex order comparisons and Numexpr doesn't, so goes for bools. > Being relatively new, I think there is no need to keep > integer-boolean compatibility in Numexpr. What was the meaning of > ``True > False`` or ``2 > True`` anyway? > > 3. This is also why casting booleans to normal numbers is not allowed, > so ``prod()`` and ``sum()`` on booleans aren't either. What is the > meaning of boolean addition anyway? > > To make it short, this patch is kind of a strengthening of boolean > values. I expect some people to disagree with the changes, and that's > why I would really like to hear your opinions on it. > > Regards, > > :: > > Ivan Vilata i Balaguer >qo< http://www.carabos.com/ > Cárabos Coop. V. V V Enjoy Data > "" > > ------------------------------------------------------------------------ > > Index: interp_body.c > =================================================================== > --- interp_body.c (revisión: 2299) > +++ interp_body.c (copia de trabajo) > @@ -130,21 +130,22 @@ > ci_dest = c1i); > > case OP_INVERT_BB: VEC_ARG1(b_dest = !b1); > + case OP_AND_BBB: VEC_ARG2(b_dest = (b1 && b2)); > + case OP_OR_BBB: VEC_ARG2(b_dest = (b1 || b2)); > > - case OP_AND_BBB: VEC_ARG2(b_dest = b1 && b2); > - case OP_OR_BBB: VEC_ARG2(b_dest = b1 || b2); > + case OP_EQ_BBB: VEC_ARG2(b_dest = (b1 == b2)); > + case OP_NE_BBB: VEC_ARG2(b_dest = (b1 != b2)); > > - case OP_GT_BII: VEC_ARG2(b_dest = (i1 > i2) ? 1 : 0); > - case OP_GE_BII: VEC_ARG2(b_dest = (i1 >= i2) ? 1 : 0); > - case OP_EQ_BII: VEC_ARG2(b_dest = (i1 == i2) ? 1 : 0); > - case OP_NE_BII: VEC_ARG2(b_dest = (i1 != i2) ? 1 : 0); > + case OP_GT_BII: VEC_ARG2(b_dest = (i1 > i2)); > + case OP_GE_BII: VEC_ARG2(b_dest = (i1 >= i2)); > + case OP_EQ_BII: VEC_ARG2(b_dest = (i1 == i2)); > + case OP_NE_BII: VEC_ARG2(b_dest = (i1 != i2)); > > - case OP_GT_BFF: VEC_ARG2(b_dest = (f1 > f2) ? 1 : 0); > - case OP_GE_BFF: VEC_ARG2(b_dest = (f1 >= f2) ? 1 : 0); > - case OP_EQ_BFF: VEC_ARG2(b_dest = (f1 == f2) ? 1 : 0); > - case OP_NE_BFF: VEC_ARG2(b_dest = (f1 != f2) ? 1 : 0); > + case OP_GT_BFF: VEC_ARG2(b_dest = (f1 > f2)); > + case OP_GE_BFF: VEC_ARG2(b_dest = (f1 >= f2)); > + case OP_EQ_BFF: VEC_ARG2(b_dest = (f1 == f2)); > + case OP_NE_BFF: VEC_ARG2(b_dest = (f1 != f2)); > > - case OP_CAST_IB: VEC_ARG1(i_dest = (long)b1); > case OP_ONES_LIKE_II: VEC_ARG1(i_dest = 1); > case OP_NEG_II: VEC_ARG1(i_dest = -i1); > > @@ -157,7 +158,6 @@ > > case OP_WHERE_IFII: VEC_ARG3(i_dest = f1 ? i2 : i3); > > - case OP_CAST_FB: VEC_ARG1(f_dest = (long)b1); > case OP_CAST_FI: VEC_ARG1(f_dest = (double)(i1)); > case OP_ONES_LIKE_FF: VEC_ARG1(f_dest = 1.0); > case OP_NEG_FF: VEC_ARG1(f_dest = -f1); > @@ -180,8 +180,6 @@ > case OP_FUNC_FF: VEC_ARG1(f_dest = functions_f[arg2](f1)); > case OP_FUNC_FFF: VEC_ARG2(f_dest = functions_ff[arg3](f1, f2)); > > - case OP_CAST_CB: VEC_ARG1(cr_dest = (double)b1; > - ci_dest = 0); > case OP_CAST_CI: VEC_ARG1(cr_dest = (double)(i1); > ci_dest = 0); > case OP_CAST_CF: VEC_ARG1(cr_dest = f1; > @@ -203,8 +201,8 @@ > ci_dest = (c1i*c2r - c1r*c2i) / fa; > cr_dest = fb); > > - case OP_EQ_BCC: VEC_ARG2(b_dest = (c1r == c2r && c1i == c2i) ? 1 : 0); > - case OP_NE_BCC: VEC_ARG2(b_dest = (c1r != c2r || c1i != c2i) ? 1 : 0); > + case OP_EQ_BCC: VEC_ARG2(b_dest = (c1r == c2r && c1i == c2i)); > + case OP_NE_BCC: VEC_ARG2(b_dest = (c1r != c2r || c1i != c2i)); > > case OP_WHERE_CFCC: VEC_ARG3(cr_dest = f1 ? c2r : c3r; > ci_dest = f1 ? c2i : c3i); > Index: compiler.py > =================================================================== > --- compiler.py (revisión: 2299) > +++ compiler.py (copia de trabajo) > @@ -217,6 +217,10 @@ > for name in c.co_names: > if name == "None": > names[name] = None > + elif name == "True": > + names[name] = True > + elif name == "False": > + names[name] = False > else: > t = types.get(name, float) > names[name] = expr.VariableNode(name, type_to_kind[t]) > Index: tests/test_numexpr.py > =================================================================== > --- tests/test_numexpr.py (revisión: 2299) > +++ tests/test_numexpr.py (copia de trabajo) > @@ -67,10 +67,6 @@ > x = x + 5j > assert_equal(evaluate("sum(x**2+2,axis=0)"), sum(x**2+2,axis=0)) > assert_equal(evaluate("prod(x**2+2,axis=0)"), prod(x**2+2,axis=0)) > - # Check boolean (should cast to integer) > - x = (arange(10) % 2).astype(bool) > - assert_equal(evaluate("prod(x,axis=0)"), prod(x,axis=0)) > - assert_equal(evaluate("sum(x,axis=0)"), sum(x,axis=0)) > > def check_axis(self): > y = arange(9.0).reshape(3,3) > Index: interpreter.c > =================================================================== > --- interpreter.c (revisión: 2299) > +++ interpreter.c (copia de trabajo) > @@ -25,6 +25,9 @@ > OP_AND_BBB, > OP_OR_BBB, > > + OP_EQ_BBB, > + OP_NE_BBB, > + > OP_GT_BII, > OP_GE_BII, > OP_EQ_BII, > @@ -35,7 +38,6 @@ > OP_EQ_BFF, > OP_NE_BFF, > > - OP_CAST_IB, > OP_COPY_II, > OP_ONES_LIKE_II, > OP_NEG_II, > @@ -47,7 +49,6 @@ > OP_MOD_III, > OP_WHERE_IFII, > > - OP_CAST_FB, > OP_CAST_FI, > OP_COPY_FF, > OP_ONES_LIKE_FF, > @@ -70,7 +71,6 @@ > OP_EQ_BCC, > OP_NE_BCC, > > - OP_CAST_CB, > OP_CAST_CI, > OP_CAST_CF, > OP_ONES_LIKE_CC, > @@ -115,6 +115,8 @@ > break; > case OP_AND_BBB: > case OP_OR_BBB: > + case OP_EQ_BBB: > + case OP_NE_BBB: > if (n == 0 || n == 1 || n == 2) return 'b'; > break; > case OP_GT_BII: > @@ -131,10 +133,6 @@ > if (n == 0) return 'b'; > if (n == 1 || n == 2) return 'f'; > break; > - case OP_CAST_IB: > - if (n == 0) return 'i'; > - if (n == 1) return 'b'; > - break; > case OP_COPY_II: > case OP_ONES_LIKE_II: > case OP_NEG_II: > @@ -152,10 +150,6 @@ > if (n == 0 || n == 2 || n == 3) return 'i'; > if (n == 1) return 'f'; > break; > - case OP_CAST_FB: > - if (n == 0) return 'f'; > - if (n == 1) return 'b'; > - break; > case OP_CAST_FI: > if (n == 0) return 'f'; > if (n == 1) return 'i'; > @@ -194,10 +188,6 @@ > if (n == 0) return 'b'; > if (n == 1 || n == 2) return 'c'; > break; > - case OP_CAST_CB: > - if (n == 0) return 'c'; > - if (n == 1) return 'b'; > - break; > case OP_CAST_CI: > if (n == 0) return 'c'; > if (n == 1) return 'i'; > @@ -1296,6 +1286,10 @@ > add_op("invert_bb", OP_INVERT_BB); > add_op("and_bbb", OP_AND_BBB); > add_op("or_bbb", OP_OR_BBB); > + > + add_op("eq_bbb", OP_EQ_BBB); > + add_op("ne_bbb", OP_NE_BBB); > + > add_op("gt_bii", OP_GT_BII); > add_op("ge_bii", OP_GE_BII); > add_op("eq_bii", OP_EQ_BII); > @@ -1306,7 +1300,6 @@ > add_op("eq_bff", OP_EQ_BFF); > add_op("ne_bff", OP_NE_BFF); > > - add_op("cast_ib", OP_CAST_IB); > add_op("ones_like_ii", OP_ONES_LIKE_II); > add_op("copy_ii", OP_COPY_II); > add_op("neg_ii", OP_NEG_II); > @@ -1318,7 +1311,6 @@ > add_op("mod_iii", OP_MOD_III); > add_op("where_ifii", OP_WHERE_IFII); > > - add_op("cast_fb", OP_CAST_FB); > add_op("cast_fi", OP_CAST_FI); > add_op("copy_ff", OP_COPY_FF); > add_op("ones_like_ff", OP_ONES_LIKE_FF); > @@ -1342,7 +1334,6 @@ > add_op("eq_bcc", OP_EQ_BCC); > add_op("ne_bcc", OP_NE_BCC); > > - add_op("cast_cb", OP_CAST_CB); > add_op("cast_ci", OP_CAST_CI); > add_op("cast_cf", OP_CAST_CF); > add_op("copy_cc", OP_COPY_CC); > Index: expressions.py > =================================================================== > --- expressions.py (revisión: 2299) > +++ expressions.py (copia de trabajo) > @@ -62,7 +62,13 @@ > return kind_rank[n] > > def bestConstantType(x): > - for converter in bool, int, float, complex: > + # Numeric conversion to boolean values is not tried because > + # ``bool(1) == True`` (same for 0 and False), so 0 and 1 would be > + # interpreted as booleans when ``False`` and ``True`` are already > + # supported. > + if isinstance(x, bool): > + return bool > + for converter in int, float, complex: > try: > y = converter(x) > except StandardError, err: > @@ -122,10 +128,7 @@ > return a > if isinstance(a, (bool, int, float, complex)): > a = ConstantNode(a) > - kind = a.astKind > - if kind == 'bool': > - kind = 'int' > - return FuncNode('sum', [a, axis], kind=kind) > + return FuncNode('sum', [a, axis], kind=a.astKind) > > def prod_func(a, axis=-1): > axis = encode_axis(axis) > @@ -133,10 +136,7 @@ > a = ConstantNode(a) > if isinstance(a, ConstantNode): > return a > - kind = a.astKind > - if kind == 'bool': > - kind = 'int' > - return FuncNode('prod', [a, axis], kind=kind) > + return FuncNode('prod', [a, axis], kind=a.astKind) > > @ophelper > def div_op(a, b): > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > ------------------------------------------------------------------------ > > _______________________________________________ > Numpy-discussion mailing list > Num...@li... > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > |
From: Travis O. <oli...@ie...> - 2006-10-26 18:12:42
|
Charles R Harris wrote: > > > On 10/26/06, *Travis Oliphant* <oli...@ie... > <mailto:oli...@ie...>> wrote: > > Ted Horst wrote: > > On Mac OS X tiger (10.4) ppc, long double has increased > precision but > > the same range as double (it really is 128 bits not 80, btw), so > > e**1000 is inf, so this is not really an error. > > > > > > Thanks for the clarification. Long-double is not standard across > platforms with different platforms choosing to do different things > with > the extra bytes. This helps explain one more platform. > > > I'm not sure what is the right thing to do in the test, check for > > overflow? Also, finfo has never worked properly for this type. > > > In machar.py is the code that runs to detect all of the > parameters. I > think the code should be moved to C as detecting precision on a > long-double takes too long. > > The overflow check is a good idea. The test should probably check for > overflow and not try to run if it's detected. > > > How to check overflow? According to the documentation the flag is not > set by the hardware. And the precision is variable! Somewhere in the > neighborhood of 31 decimal digits, more or less, depending. So I think > it is hard to figure out what to do here. Let's drop the test. Long-double is available but is not consistent across platforms and NumPy has done nothing to try and make it so. Thus, let's just let the user beware. -Travis |
From: Charles R H. <cha...@gm...> - 2006-10-26 17:57:25
|
On 10/26/06, Travis E. Oliphant <oli...@ie...> wrote: > > > We are very pleased to announce the release of NumPy 1.0 available for > download at http://www.numpy.org Congratulations, Travis. Numpy was a needed unification and involved an enormous amount of work, most of it your own. Thanks for taking this on. Chuck |
From: Travis E. O. <oli...@ie...> - 2006-10-26 17:23:11
|
We are very pleased to announce the release of NumPy 1.0 available for download at http://www.numpy.org This release is the culmination of over 18 months of effort to allow unification of the Numeric and Numarray communities. NumPy provides the features of both packages as well as comparable speeds in the domains where both were considered fast --- often beating both packages on certain problems. If there is an area where we can speed up NumPy then we are interested in hearing about the solution. NumPy is essentially a re-write of Numeric to include the features of Numarray plus more. NumPy is a C-based extension module to Python that provides an N-dimensional array object (ndarray), a collection of fast math functions, basic linear algebra, array-producing random number generators, and basic Fourier transform capabilities. Also included with NumPy are: 1) A data-type object. The data-type of all NumPy arrays are defined by a data-type object that describes how the block of memory that makes up an element of the array is to be interpreted. Supported are all basic C-types, structures containing C-types, arrays of C-types, and structures containing structures of C-types. Data-types can also be in big or little-endian order. NumPy arrays can therefore be constructed from any regularly-sized chunk of data. A chunk of data can also be a pointer to a Python object and therefore Object arrays can be constructed (including record arrays with object members). 2) Array scalars: there is a Python scalar object (inheriting from the standard object where possible) defined for every basic data-type that an array can have. 2) A matrix object so that '*' is re-defined as matrix-multiplication and '**' as matrix-power. 3) A character array object that can replace Numarray's similarly-named object. It is basically an array of strings (or unicode) with methods matching the string and unicode methods. 4) A record array that builds on the advanced data-type support of the basic array object to allow field access using attribute look-up as well as to provide more ways to build-up a record-array. 5) A memory-map object that makes it easier to use memory-mapped areas as the memory for an array object. 6) A basic container class that uses the ndarray as a member. This often facilitates multiple-inheritance. 7) A large collection of basic functions on the array. 8) Compatibility layer for Numeric including code to help in the conversion to NumPy and full C-API support. 9) Compatibility layer for NumPy including code to help in the conversion to NumPy and full C-API support. NumPy can work with Numeric and Numarray installed and while the three array objects are different to Python, they can all share each other's data through the use of the array interface. As the developers for Numeric we can definitively say development of Numeric has ceased as has effective support. You may still find an answer to a question or two and Numeric will be available for download as long as Sourceforge is around so and code written to Numeric will still work, but there will not be "official" releases of Numeric for future versions of Python (including Python2.5). The development of NumPy has been supported by the people at STScI who created Numarray and support it. They have started to port their applications to NumPy and have indicated that support for Numarray will be phased out over the next year. You are strongly encouraged to move to NumPy. The whole point of NumPy is to unite the Numeric/Numarray development and user communities. We have done our part in releasing NumPy 1.0 and doing our best to make the transistion as easy as possible. Please support us by adopting NumPy. If you have trouble with that, please let us know why so that we can address the problems you identify. Even better, help us in fixing the problems. New users should download NumPy first unless they need an older package to work with third party code. Third-party package writers should migrate to use NumPy. Though it is not difficult, there are some things that have to be altered. Several people are available to help with that process, just ask (we will do it free for open source code and as work-for-hire for commercial code). This release would not have been possible without the work of many people. Thanks go to (if we have missed your contribution please let us know): * Travis Oliphant for the majority of the code adaptation (blame him for code problems :-) ) * Jim Hugunin, Paul Dubois, Konrad Hinsen, David Ascher, Jim Fulton and many others for Numeric on which the code is based. * Perry Greenfield, J Todd Miller, Rick White, Paul Barrett for Numarray which gave much inspiration and showed the way forward. * Paul Dubois for Masked Arrays * Pearu Peterson for f2py and numpy.distutils and help with code organization * Robert Kern for mtrand, bug fixes, help with distutils, code organization, and much more. * David Cooke for many code improvements including the auto-generated C-API and optimizations. * Alexander Belopolsky (Sasha) for Masked array bug-fixes and tests, rank-0 array improvements, scalar math help and other code additions * Francesc Altet for unicode and nested record tests and much help with rooting out nested record array bugs. * Tim Hochberg for getting the build working on MSVC, optimization improvements, and code review * Charles Harris for the sorting code originally written for Numarray and for improvements to polyfit, many bug fixes, and documentation strings. * Robert Cimrman for numpy.distutils help and the set-operations for arrays * David Huard for histogram code improvements including 2-d and d-d code * Eric Jones for sundry subroutines borrowed from scipy_base * Fernando Perez for code snippets, ideas, bugfixes, and testing. * Ed Schofield for matrix.py patches, bugfixes, testing, and docstrings. * John Hunter for code snippets (from matplotlib) * Chris Hanley for help with records.py, testing, and bug fixes. * Travis Vaught, Joe Cooper, Jeff Strunk for administration of numpy.org web site and SVN * Andrew Straw for bug-reports and help with www.scipy.org * Albert Strasheim for bug-reports, unit-testing and Valgrind runs * Stefan van der Walt for bug-reports, regression-testing, and bug-fixes. * Eric Firing for bugfixes. * Arnd Baecker for 64-bit testing * A.M. Archibald for code that decreases the number of times reshape makes a copy. More information is available at http://numpy.scipy.org and http://www.scipy.org. Bug-reports and feature requests should be submitted as tickets to the Trac pages at http://projects.scipy.org/scipy/numpy/ As an anti-SPAM measure, you must create an account in order to post tickets. Enjoy the new release, Sincerely, The NumPy Developers *Disclaimer*: The main author, Travis Oliphant, has written a 350+ page book entitled "Guide to NumPy" that documents the new system fairly thoroughly. The first two chapters of this book are available on-line for free, but the remainder must be purchased (until 2010 or a certain number of total sales has been reached). See http://www.trelgol.com for more details. There is plenty of free documentation available now for NumPy, however. Go to http://www.scipy.org for more details. |
From: Charles R H. <cha...@gm...> - 2006-10-26 17:08:57
|
On 10/26/06, Travis Oliphant <oli...@ie...> wrote: > > Ted Horst wrote: > > On Mac OS X tiger (10.4) ppc, long double has increased precision but > > the same range as double (it really is 128 bits not 80, btw), so > > e**1000 is inf, so this is not really an error. > > > > > > Thanks for the clarification. Long-double is not standard across > platforms with different platforms choosing to do different things with > the extra bytes. This helps explain one more platform. > > > I'm not sure what is the right thing to do in the test, check for > > overflow? Also, finfo has never worked properly for this type. > > > In machar.py is the code that runs to detect all of the parameters. I > think the code should be moved to C as detecting precision on a > long-double takes too long. > > The overflow check is a good idea. The test should probably check for > overflow and not try to run if it's detected. How to check overflow? According to the documentation the flag is not set by the hardware. And the precision is variable! Somewhere in the neighborhood of 31 decimal digits, more or less, depending. So I think it is hard to figure out what to do here. Chuck. |
From: Travis O. <oli...@ie...> - 2006-10-26 16:13:11
|
Ted Horst wrote: > On Mac OS X tiger (10.4) ppc, long double has increased precision but > the same range as double (it really is 128 bits not 80, btw), so > e**1000 is inf, so this is not really an error. > > Thanks for the clarification. Long-double is not standard across platforms with different platforms choosing to do different things with the extra bytes. This helps explain one more platform. > I'm not sure what is the right thing to do in the test, check for > overflow? Also, finfo has never worked properly for this type. > In machar.py is the code that runs to detect all of the parameters. I think the code should be moved to C as detecting precision on a long-double takes too long. The overflow check is a good idea. The test should probably check for overflow and not try to run if it's detected. -Travis |
From: Charles R H. <cha...@gm...> - 2006-10-26 15:20:46
|
On 10/26/06, Ted Horst <ted...@ea...> wrote: > > On Mac OS X tiger (10.4) ppc, long double has increased precision but > the same range as double (it really is 128 bits not 80, btw), Looks like you are right: http://www.freestandards.org/spec/ELF/ppc64/PPC-elf64abi-1.9.html#PREC Actually two doubles with some strange rules, the quad value is the sum. Hmmm, I can see why compiler support was problematic. The extended precision also has some oddities. This "Extended precision" differs from the IEEE 754 Standard in the following ways: - The software support is restricted to round-to-nearest mode. Programs that use extended precision must ensure that this rounding mode is in effect when extended-precision calculations are performed. - Does not fully support the IEEE special numbers NaN and INF. These values are encoded in the high-order double value only. The low-order value is not significant. - Does not support the IEEE status flags for overflow, underflow, and other conditions. These flag have no meaning in this format. so > e**1000 is inf, so this is not really an error. > > I'm not sure what is the right thing to do in the test, check for > overflow? Also, finfo has never worked properly for this type. See above. Chuck |
From: Christopher H. <ch...@st...> - 2006-10-26 15:05:43
|
I just tried this on one of our G4's and see the same behavior. Chris ---- Original message ---- >Date: Thu, 26 Oct 2006 15:46:50 +0100 >From: Andrew Jaffe <a.h...@gm...> >Subject: Re: [Numpy-discussion] Still a ticket 112 "check_longfloat_repr" issue on OSX >To: Discussion of Numerical Python <num...@li...> > >Andrew Jaffe wrote: >> OS X 10.4, PPC >> >> In [5]: import numpy as N >> >> In [6]: N.__version__ >> Out[6]: '1.0.1.dev3399' >> >> In [7]: print N.longfloat(0).itemsize >> 16 >> >> In [8]: a = N.exp(N.array([1000],dtype=N.longfloat)) >> >> In [9]: print str(a) >> [inf] >> >> In [10]: print str(a[0]) >> inf >> >> In [11]: print a.itemsize >> 16 > >Are others still seeing this at this point, or just me? > >A |
From: Yves <yve...@gm...> - 2006-10-26 14:49:20
|
Hi, It seems that random.shuffle does not 'shuffle' anymore when presented with an n-dimensional array. In [1]: import numpy as N In [2]: a = N.arange(5).reshape((5,1)) In [3]: a Out[3]: array([[0], [1], [2], [3], [4]]) In [4]: N.random.shuffle(a) In [5]: a Out[5]: array([[0], [1], [1], [3], [3]]) In [6]: N.__version__ Out[6]: '1.0.dev3390' After application some rows appear to be duplicated. Is this documented/intended behaviour? Cheers, YVES |
From: Andrew J. <a.h...@gm...> - 2006-10-26 14:46:59
|
Andrew Jaffe wrote: > OS X 10.4, PPC > > In [5]: import numpy as N > > In [6]: N.__version__ > Out[6]: '1.0.1.dev3399' > > In [7]: print N.longfloat(0).itemsize > 16 > > In [8]: a = N.exp(N.array([1000],dtype=N.longfloat)) > > In [9]: print str(a) > [inf] > > In [10]: print str(a[0]) > inf > > In [11]: print a.itemsize > 16 Are others still seeing this at this point, or just me? A |
From: Ted H. <ted...@ea...> - 2006-10-26 12:56:50
|
On Mac OS X tiger (10.4) ppc, long double has increased precision but the same range as double (it really is 128 bits not 80, btw), so e**1000 is inf, so this is not really an error. I'm not sure what is the right thing to do in the test, check for overflow? Also, finfo has never worked properly for this type. Ted On Oct 23, 2006, at 05:50, Mark Hymers wrote: > On Thu, 19, Oct, 2006 at 08:29:26AM -0600, Travis Oliphant spoke > thus.. >> Actually, you shouldn't be getting an INF at all. This is what the >> test is designed to test for (so I guess it's working). The test was >> actually written wrong and was never failing because previously >> keyword >> arguments to ufuncs were ignored. >> >> Can you show us what 'a' is on your platform. > > Hi, > > I've just done a Mac OS X PPC build of the SVN trunk and am getting > this > failure too. > > nidesk046:~/scratch/upstream/scipy mark$ python > Python 2.4.1 (#2, Mar 31 2005, 00:05:10) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin > Type "help", "copyright", "credits" or "license" for more information. >>>> import numpy as N >>>> N.__version__ > '1.0.dev3378' >>>> N.array([1000],dtype=N.float).dtype > dtype('float64') >>>> N.array([1000],dtype=N.longfloat).dtype > dtype('float128') >>>> N.test() > ...snip... > FAIL: Ticket #112 > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ > python2.4/site-packages/numpy/core/tests/test_regression.py", line > 220, in check_longfloat_repr > assert(str(a)[1:9] == str(a[0])[:8]) > AssertionError >>>> a = N.exp(N.array([1000],dtype=N.longfloat)) >>>> str(a) > '[inf]' > > > Any ideas about this? > > Mark > > -- > Mark Hymers <mark at hymers dot org dot uk> > > "I once absent-mindedly ordered Three Mile Island dressing in a > restaurant > and, with great presence of mind, they brought Thousand Island > Dressing and > a bottle of chili sauce." > Terry Pratchett, alt.fan.pratchett > ---------------------------------------------------------------------- > --- > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your > job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=120709&bid=263057&dat=121642______________________________ > _________________ > Numpy-discussion mailing list > Num...@li... > https://lists.sourceforge.net/lists/listinfo/numpy-discussion |
From: TheMoon S. <the...@gm...> - 2006-10-26 12:50:15
|
Hello, I would like to install numeric for python 1.5.2 and I don't found the numeric package.. Where can I find it or how can I intall it? Greets Francis |
From: Steven H. R. <st...@sh...> - 2006-10-26 12:03:13
|
Concur. This has been a tremendous effort. |
From: Ivan V. i B. <iv...@ca...> - 2006-10-26 11:58:19
|
Hi all. The attached diff makes some changes to Numexpr support for booleans. The changes and their rationale are below. 1. New ``True`` and ``False`` boolean constants. This is so that 1 and 0 are always proper integer constants. It is also for completeness, but I don't envision any usage for them that couldn't be expressed without the constants. 2. The only comparisons supported with booleans are ``==`` and ``!=``, so that you can compare boolean variables. Just as NumPy supports complex order comparisons and Numexpr doesn't, so goes for bools. Being relatively new, I think there is no need to keep integer-boolean compatibility in Numexpr. What was the meaning of ``True > False`` or ``2 > True`` anyway? 3. This is also why casting booleans to normal numbers is not allowed, so ``prod()`` and ``sum()`` on booleans aren't either. What is the meaning of boolean addition anyway? To make it short, this patch is kind of a strengthening of boolean values. I expect some people to disagree with the changes, and that's why I would really like to hear your opinions on it. Regards, :: Ivan Vilata i Balaguer >qo< http://www.carabos.com/ Cárabos Coop. V. V V Enjoy Data "" |
From: David C. <da...@ar...> - 2006-10-26 10:08:54
|
Lars Friedrich wrote: > Hello, > > thanks for your comments. > > Am Mittwoch, den 25.10.2006, 11:28 +0900 schrieb David Cournapeau: > >> Andrew Straw wrote: >> >>> David Cournapeau wrote: >>> >>> >>>> I don't know anything about your device, but a driver directly accessing >>>> a memory buffer from a userland program sounds like a bug to me. >>>> >>>> >>> David, DMA memory (yes, I know thats an example of RAS Syndrome, >>> apologies) allows hardware to fill a chunk of RAM and then hand it over >>> to a userspace program. In my experience, RAM used for this purpose must >>> be pre-allocated, usually in a ring-buffer type arrangement. So this is >>> normal operating procedure for something like a frame grabber and not a >>> bug at all. >>> >>> >> What I understood from former emails was that the user is allocating a >> memory buffer, and that it gives this memory buffer to the hardware. In >> this sense, I don't see how it is possible to avoid kernel panic or >> equivalents. If on the contrary, the driver gives you the memory buffer, >> then, ok, by eg a mmap-like call, you can access directly the device >> memory, but within a range fixed by the driver, which is valid if the >> driver is not buggy. >> > > The API of the camera provides a function > pl_exp_start_cont(hCam, buffer, size) > > The usage is to pass a Camera-Identifier "hCam", a pointer "buffer" and > a size "size" in bytes. The camera will then start to acquire frames and > put them to the buffer, which has to be size-bytes long. When the > function reaches the end of the buffer, it will start at the beginning > again (circular buffer mode). There is also a function available to ask > for the last buffer position that is written to. The buffer has to be > allocated by the caller of this API-function, so I guess it will be in > *userland*. > In this case, I think the data are copied from the device to your buffer. > To have enough time to read a frame, the buffer has to be sufficiently > big. I don't know what is sufficient, but I made it 50 frames big. With > an acquisition time of lets say 10ms I have about 0.5seconds to get a > frame, that was recently written to the buffer. > You have no way to check if the ringbuffer is full or not ? In audio programming under linux, what happens normally is that you have a ring buffer locked in memory (that is cannot be paged out), and you need to check if your read/write pointers overlap to detect a buffer overrun. > I know, these things are not numpy and even not Python-questions, but > C-questions, and I think I should go and read something about it. Does > anyone have a recommendation where to find information on this > memory-locking things? How is this kind of programming called? > Driver-Programming? Hardware-Programming? System-Programming? > > Real time programming, maybe ? Without a knowledge of the API of your device, it is hard to know what the problem is for me. By the way, I found the information about locking pages into memory for windows: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/memory/base/virtuallock.asp It may not work as expected, though, as it happens quite often with windows :) David |
From: Johannes L. <a.u...@gm...> - 2006-10-26 09:51:53
|
On Thursday 26 October 2006 11:39, Vincent Schut wrote: > > Of course I can easily loop over that axis, but if possible I'd like to > > prevent array loops... Depending on the problem's size, this could actually be the best solution -- if each particular sum is over enough elements, the overhead of looping is negligible. Also it would be the best solution in terms of readability. Without for-loops i would probably have come up with something like your solution, only longer and uglier. ;-) Johannes |
From: Vincent S. <sc...@sa...> - 2006-10-26 09:39:41
|
Vincent Schut wrote: > Hi list, > > probably I'm just missing something obvious, but I'm looking for a > function/construcion to sum (or better, apply any numpy function) over > all but one axis. Like when I have a nD array A, it will give me a 1D > array with the sums of A[i, ...], but the axis that is retained in the > result of course should be an argument to that function. > I thought 'apply_along_axis' would do the trick, but it does not. If I > apply that to a 3d array, it results in a 2d array instead of a 1d array. > > Of course I can easily loop over that axis, but if possible I'd like to > prevent array loops... > > Vincent. > Replying to self... the 'solution' I just found is this: 1: create a list 'axes' with the numbers of all axes except the one I want to retain 2: use numpy.apply_over_axes(function, array, axes).flatten() If anyone knows a better / more elegant solution or any related comments of course I'd still like to hear that. :-) VS. |
From: Francesc A. <fa...@ca...> - 2006-10-26 09:34:28
|
El dj 26 de 10 del 2006 a les 11:09 +0200, en/na Sven Schreiber va escriure: > Wow! The list is so quiet despite the fact that the numpy 1.0 release is > officially announced on the website, and the download is on sourceforge. > Well ok, it was expected and the download counters are all at zero, but > still. > > I want to thank everybody who made this possible very much! I'm not a > numpy veteran (never used Numeric or Numarray before, or python for very > long actually), but it feels great nevertheless. > > Since I'm not an insider, I can't give all the names that deserve to be > mentioned, but it's quite obvious that one should at least mention > Travis explicitly. Travis, it's great to know somebody like you is there > who takes users' concerns seriously! (I should really leave it to others > to praise his development skills, since due to my ignorance in that area > I cannot even appreciate it fully.) > > Thanks, and relax a little after all the hard work! Yeah, I completely agree. Congratulations to Travis and all the NumPy team. Long life to NumPy! -- Francesc Altet | Be careful about using the following code -- Carabos Coop. V. | I've only proven that it works, www.carabos.com | I haven't tested it. -- Donald Knuth |
From: Vincent S. <sc...@sa...> - 2006-10-26 09:16:46
|
Hi list, probably I'm just missing something obvious, but I'm looking for a function/construcion to sum (or better, apply any numpy function) over all but one axis. Like when I have a nD array A, it will give me a 1D array with the sums of A[i, ...], but the axis that is retained in the result of course should be an argument to that function. I thought 'apply_along_axis' would do the trick, but it does not. If I apply that to a 3d array, it results in a 2d array instead of a 1d array. Of course I can easily loop over that axis, but if possible I'd like to prevent array loops... Vincent. |
From: Sven S. <sve...@gm...> - 2006-10-26 09:10:10
|
Wow! The list is so quiet despite the fact that the numpy 1.0 release is officially announced on the website, and the download is on sourceforge. Well ok, it was expected and the download counters are all at zero, but still. I want to thank everybody who made this possible very much! I'm not a numpy veteran (never used Numeric or Numarray before, or python for very long actually), but it feels great nevertheless. Since I'm not an insider, I can't give all the names that deserve to be mentioned, but it's quite obvious that one should at least mention Travis explicitly. Travis, it's great to know somebody like you is there who takes users' concerns seriously! (I should really leave it to others to praise his development skills, since due to my ignorance in that area I cannot even appreciate it fully.) Thanks, and relax a little after all the hard work! -Sven |
From: Lars F. <lfr...@im...> - 2006-10-26 08:52:24
|
Hello, thanks for your comments. Am Mittwoch, den 25.10.2006, 11:28 +0900 schrieb David Cournapeau: > Andrew Straw wrote: > > David Cournapeau wrote: > > > >> I don't know anything about your device, but a driver directly accessing > >> a memory buffer from a userland program sounds like a bug to me. > >> > > David, DMA memory (yes, I know thats an example of RAS Syndrome, > > apologies) allows hardware to fill a chunk of RAM and then hand it over > > to a userspace program. In my experience, RAM used for this purpose must > > be pre-allocated, usually in a ring-buffer type arrangement. So this is > > normal operating procedure for something like a frame grabber and not a > > bug at all. > > > What I understood from former emails was that the user is allocating a > memory buffer, and that it gives this memory buffer to the hardware. In > this sense, I don't see how it is possible to avoid kernel panic or > equivalents. If on the contrary, the driver gives you the memory buffer, > then, ok, by eg a mmap-like call, you can access directly the device > memory, but within a range fixed by the driver, which is valid if the > driver is not buggy. The API of the camera provides a function pl_exp_start_cont(hCam, buffer, size) The usage is to pass a Camera-Identifier "hCam", a pointer "buffer" and a size "size" in bytes. The camera will then start to acquire frames and put them to the buffer, which has to be size-bytes long. When the function reaches the end of the buffer, it will start at the beginning again (circular buffer mode). There is also a function available to ask for the last buffer position that is written to. The buffer has to be allocated by the caller of this API-function, so I guess it will be in *userland*. To have enough time to read a frame, the buffer has to be sufficiently big. I don't know what is sufficient, but I made it 50 frames big. With an acquisition time of lets say 10ms I have about 0.5seconds to get a frame, that was recently written to the buffer. I know, these things are not numpy and even not Python-questions, but C-questions, and I think I should go and read something about it. Does anyone have a recommendation where to find information on this memory-locking things? How is this kind of programming called? Driver-Programming? Hardware-Programming? System-Programming? Thanks Lars -- Dipl.-Ing. Lars Friedrich Optical Measurement Technology Department of Microsystems Engineering -- IMTEK University of Freiburg Georges-Köhler-Allee 102 D-79110 Freiburg Germany phone: +49-761-203-7531 fax: +49-761-203-7537 room: 01 088 email: lfr...@im... |
From: <ET...@HO...> - 2006-10-26 08:47:07
|
肌寒くなってきましたね。人肌恋しいですね。 友達探しの決定版特集! http://o-oooo-o.com/ccc/ |
From: Nils W. <nw...@ia...> - 2006-10-26 07:19:49
|
Bill Baxter wrote: > > On 10/26/06, *jeremito* <jer...@gm... > <mailto:jer...@gm...>> wrote: > > > Hmmm. I guess I'll have to find another way to get some > "standard/well-known" matrices to work with. Thanks for your help. > > > Well if all you want is some matrices, there's nothing stopping you > from grabbing the matrices in the LAPACK distribution and using them > yourself. Robert's just saying they won't be included in Numpy. > > There's also the matrix market, whcih has a large number of > (sparse-only?) example matrices. > http://math.nist.gov/MatrixMarket/index.html > > --bb > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > ------------------------------------------------------------------------ > > _______________________________________________ > Numpy-discussion mailing list > Num...@li... > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > You might be also interested in the Matrix Computation Toolbox which is a collection of MATLAB M-files containing functions for constructing test matrices ... http://www.ma.man.ac.uk/~higham/mctoolbox/ and http://www.mathworks.com/access/helpdesk/help/techdoc/ref/*gallery*.html BTW, you can easily import matrices given in the MatrixMarket format in scipy. See* io.mmread * mmread(source) Reads the contents of a Matrix Market file 'filename' into a matrix. Inputs: source - Matrix Market filename (extensions .mtx, .mtz.gz) or open file object. Outputs: a - sparse or full matrix Nils |
From: Christian K. <ck...@ho...> - 2006-10-26 06:57:03
|
Hi, I noticed that plain distutils and numpy.distutils differ in where they put the files specified with the keyword 'data_files' ( at least on windows XP). With distutils they go to 'PREFIX' and with numpy.distutils they go to 'PLATLIB', i.e. relative to the package installation directory. I guess this is for backward compatibility with python 2.3 which lacks a 'package_data' option. How can I install files to 'PREFIX' with numpy.disutils? Some data I really don't want to have lying around in the package dir, like e.g. documentation files, examples, etc. Regards, Christian |