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

Re: [Numpy-discussion] [ANN] NumPy 1.0 release

[Erin S. <eri...@gm...>]

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
>
>
>

Re: [Numpy-discussion] Changes to bools under Numexpr

[Colin J. W. <cj...@sy...>]

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
>   

Re: [Numpy-discussion] Unit test error with numpy rc3

[Travis O. <oli...@ie...>]

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

Re: [Numpy-discussion] [ANN] NumPy 1.0 release

[Charles R H. <cha...@gm...>]

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

[Numpy-discussion] [ANN] NumPy 1.0 release

[Travis E. O. <oli...@ie...>]

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.

Re: [Numpy-discussion] Unit test error with numpy rc3

[Charles R H. <cha...@gm...>]

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.

Re: [Numpy-discussion] Unit test error with numpy rc3

[Travis O. <oli...@ie...>]

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

Re: [Numpy-discussion] Unit test error with numpy rc3

[Charles R H. <cha...@gm...>]

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

Re: [Numpy-discussion] Still a ticket 112 "check_longfloat_repr" issue on OSX

[Christopher H. <ch...@st...>]

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

[Numpy-discussion] Behaviour of numpy.random.shuffle

[Yves <yve...@gm...>]

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

Re: [Numpy-discussion] Still a ticket 112 "check_longfloat_repr" issue on OSX

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

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

Re: [Numpy-discussion] Unit test error with numpy rc3

[Ted H. <ted...@ea...>]

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

[Numpy-discussion] How to install numeric on python 1.5.2

[TheMoon S. <the...@gm...>]

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

Re: [Numpy-discussion] 1.0

[Steven H. R. <st...@sh...>]

Concur.  This has been a tremendous effort.

[Numpy-discussion] Changes to bools under Numexpr

[Ivan V. i B. <iv...@ca...>]

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
	                          ""

Re: [Numpy-discussion] memory position of numpy arrays

[David C. <da...@ar...>]

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

Re: [Numpy-discussion] sum over all but one axis

[Johannes L. <a.u...@gm...>]

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

Re: [Numpy-discussion] sum over all but one axis

[Vincent S. <sc...@sa...>]

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.

Re: [Numpy-discussion] 1.0

[Francesc A. <fa...@ca...>]

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

[Numpy-discussion] sum over all but one axis

[Vincent S. <sc...@sa...>]

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.

[Numpy-discussion] 1.0

[Sven S. <sve...@gm...>]

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

Re: [Numpy-discussion] memory position of numpy arrays

[Lars F. <lfr...@im...>]

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...

[Numpy-discussion] =?iso-2022-jp?b?GyRCTDVOQT1QMnEkJEY7STgbKEI=?=

[<ET...@HO...>]

肌寒くなってきましたね。人肌恋しいですね。
友達探しの決定版特集！
http://o-oooo-o.com/ccc/

Re: [Numpy-discussion] Matrices for testing

[Nils W. <nw...@ia...>]

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

[Numpy-discussion] =?utf-8?q?distutils_data=5Ffiles_target?=

[Christian K. <ck...@ho...>]

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