From pete at shinners.org Mon Oct 2 13:57:55 2000 From: pete at shinners.org (Pete Shinners) Date: Mon, 2 Oct 2000 10:57:55 -0700 Subject: [Numpy-discussion] quick optimization Message-ID: <006e01c02ca6$1ece3e40$0200a8c0@home> i've got a quick optimization for the arrayobject.c source. it speeds my usage of numpy up by about 100%. i've tested with other numpy apps and noticed a minimum of about 20% speed. anyways, in "do_sliced_copy", change out the following block: if (src_nd == 0 && dest_nd == 0) { for(j=0; j Message-ID: <39D971DD.79D2915A@lipn.univ-paris13.fr> Oups, you're right... In most (all ?) systems, memcpy() is a true function, and is *not* inlined. Jim was coding in the C++ way: trusting the optimizer ! Thank you, Emmanuel From pauldubois at home.com Mon Oct 9 15:50:30 2000 From: pauldubois at home.com (Paul F. Dubois) Date: Mon, 9 Oct 2000 12:50:30 -0700 Subject: [Numpy-discussion] [ANNOUNCE] Ninth International Python Conference Message-ID: CALL FOR PAPERS, POSTERS, AND PARTICIPATION Ninth International Python Conference March 5-8, 2001 Long Beach, California Web site: http://python9.org The 9th International Python Conference (Python 9) is a forum for Python users, software developers, and researchers to present current work, discuss future plans for the language and commercial applications, and learn about interesting uses of Python. The conference will consist of a day of tutorials, two days of refereed paper and application tracks including a Zope track and a multi-technology Python Applications Track, a developers' day, a small exhibition, demonstrations, and posters. Paper submission deadline: Monday, November 6, 2000 Notification of acceptance: Monday, December 11, 2000 Final papers due: Monday, January 15, 2001 Authors are invited to submit papers for the Refereed Paper Track that: * Present new and useful applications and tools that utilize Python * Describe the use of Python in large, mission-critical or unusual applications * Address practical programming problems, and provide lessons based on experience for Python programmers Also sought are poster presentations of interesting work in progress. Full information is available on the website, http://python9.org From pearu at ioc.ee Tue Oct 10 13:42:38 2000 From: pearu at ioc.ee (Pearu Peterson) Date: Tue, 10 Oct 2000 19:42:38 +0200 (GMT-2) Subject: [Numpy-discussion] ANNOUNCE: PySymbolic - Doing Symbolics in Python Message-ID: Hi! I have started a project PySymbolic - "Doing Symbolics in Python" PySymbolic is a collection of tools for doing elementary symbolic calculations in Python. The project is in alpha stage. Current features include basic simplifications: *** removing redundant parenthesis: (a) -> a *** applying factorization: -(a) -> -a, +a -> a, ~(a) -> ~a *** collecting terms: n*a+b+m*a -> k*a+b (where k=n+m) *** collecting powers: a**c*b/a**d -> a**(c-d)*b *** cancellations: 0*a -> 0, a+0 -> 0, a**0 -> 1, 1*a -> a, a**1 -> a *** rational arithmetic: 3/4+2/6-1 -> 1/12 *** opening parenthesis: (a+b)*c -> a*c+b*c *** expanding integer powers: (a+b)**n -> a**n+a**(n-1)*b+... *** sorting terms in alphabethic order: a+c+b -> a+b+c *** (more to come) Projects homepage is http://cens.ioc.ee/projects/pysymbolic/ You can download the source from http://cens.ioc.ee/projects/pysymbolic/PySymbolic.tgz Regards, Pearu From fred at ontosys.com Tue Oct 10 15:16:13 2000 From: fred at ontosys.com (Fred Yankowski) Date: Tue, 10 Oct 2000 14:16:13 -0500 Subject: [Numpy-discussion] version.py vs numeric_version.py Message-ID: <20001010141612.A77833@enteract.com> I couldn't seem to download a prebuilt distribution of NumPy from SourceForge earlier today, so I connected via CVS and grabbed the latest code. I was eventually able to build and install it OK, but I had to copy Lib/version.py to Lib/numeric_version.py since the latter didn't exist but other code refers to it. Just a "heads up"... -- Fred Yankowski fred at OntoSys.com tel: +1.630.879.1312 Principal Consultant www.OntoSys.com fax: +1.630.879.1370 OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA From pauldubois at home.com Wed Oct 11 08:53:42 2000 From: pauldubois at home.com (Paul F. Dubois) Date: Wed, 11 Oct 2000 05:53:42 -0700 Subject: [Numpy-discussion] Re: numpy, overflow, inf, ieee, and rich comparison Message-ID: About controlling floating-point behavior with Numpy: I think that somewhere buried in the sources Lee Busby had us all set if we would just go through the source and stick in some macro in the right places (this was maybe 3 years ago, hence the accurate and detailed memory dump) but it was on the todo list so long it outlived the death of the todo list. Anyway, my recollection is if we ever did it then we would have control when things like overflow happen. But we haven't. My last experience of this sort of thing was that it was completely a hardware-dependent thing, and you had to find out from each manufacturer what their routine was and how to call it or what compiler flag to use. Well, sorry to be so imprecise but I thought it worth mentioning that some steps had been taken even if I don't remember what they were. From busby at icf.llnl.gov Wed Oct 11 14:01:40 2000 From: busby at icf.llnl.gov (L. Busby) Date: Wed, 11 Oct 2000 11:01:40 -0700 (PDT) Subject: [Numpy-discussion] Re: numpy, overflow, inf, ieee, and rich comparison Message-ID: <200010111801.LAA02047@icf.llnl.gov> It was an optional module (fpectl) that got added into Python 1.5. Looks like it has been carried forward pretty much unchanged into the 2.0 release candidate. To use the facility, you need to build python with --with-fpectl, then identify "dangerous" (likely to generate SIGFPE) operations, and surround them with a pair of macros PyFPE_START_PROTECT and PyFPE_END_PROTECT. This has the effect of turning any SIGFPE into a Python exception. Start with Include/pyfpe.h, look for example usage in Objects/floatobject.c. Grep the python source for FPE_ to find the several places where these hooks are located. [ Paul Dubois wrote ] >About controlling floating-point behavior with Numpy: I think that somewhere >buried in the sources Lee Busby had us all set if we would just go through >the source and stick in some macro in the right places (this was maybe 3 >years ago, hence the accurate and detailed memory dump) but it was on the >todo list so long it outlived the death of the todo list. > >Anyway, my recollection is if we ever did it then we would have control when >things like overflow happen. But we haven't. My last experience of this sort >of thing was that it was completely a hardware-dependent thing, and you had >to find out from each manufacturer what their routine was and how to call it >or what compiler flag to use. > >Well, sorry to be so imprecise but I thought it worth mentioning that some >steps had been taken even if I don't remember what they were. From huaiyu_zhu at yahoo.com Wed Oct 11 19:33:08 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Wed, 11 Oct 2000 16:33:08 -0700 (PDT) Subject: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: On the issue of whether Python should ignore over/underflow on IEEE-enabled platforms: [Tim Peters] > That would stop the exception on exp() underflow, which is what you're > concerned about. It would also stop exceptions on exp() overflow, and on > underflow and overflow for all other math functions too. I doubt Guido will > ever let Python ignore overflow by default, #ifdef'ed or not. A semantic > change that jarring certainly won't happen for 2.0 (which is just a week > away). It can be argued that on IEEE enabled systems the proper thing to do for overflow is simply return Inf. Raising exception is WRONG. See below. [Guido van Rossum] > Incidentally, math.exp(800) returns inf in 1.5, and raises > OverflowError in 2.0. So at least it's consistent. That is not consistent at all. Suppose I'm plotting the curve f(x) where x include some singular points of f. In the first case the plot works with some portion of the curve clipped. In the second case it bombs. [Tim Peters] > Nothing like that will happen without a PEP first. I would like to see > *serious* 754 support myself, but that depends too on many platform experts > contributing real work (if everyone ran WinTel, I could do it myself > ). [Guido van Rossum] > Bingo! > > 1.5.2 links with -lieee while 2.0 doesn't. Removing -lieee from the > 1.5.2 link line makes is raise OverflowError too. Adding it to the > 2.0 link line makes it return 0.0 for exp(-1000) and inf for > exp(1000). If using ieee is as simple as setting such a flag, there is no reason at all not to use it. Here are some more examples: Suppose you have done hours of computation on a problem. Just as you are about to get the result, you get an exception. Why? Because the residual error is too close to zero. Suppose you want to plot the curve of Gausian distribution. Oops, it fails. Because beyond a certain region the value is near zero. With these kinds of problems, vectorized numerical calculation becomes nearly impossible. How do you work in such an environment? You have to wrap every calculation in a try/except structure, and whenever there is an exception, you have to revert to elementwise operations. In practice this simply means Python would not be suitable for numerical work at all. What about the other way round? No problem. It is easy to write functions like isNaN, isInf, etc. With these one can raise exceptions in any place one want. It is even possible to raise exceptions if a matrix is singular to a certain precision, etc. The key point to observe here is that most numerical work involve more than one element. Some of them may be out of mahcine bounds but the whole thing could still be quite meaningful. Vice versa it is also quite possible that all elements are within bounds while the whole thing is meaningless. The language should never take over or subvert decisions based on numerical analysis. [Tim Peters] > Ignoring ERANGE entirely is not at all the same behavior as 1.5.2, and > current code certainly relies on detecting overflows in math functions. As Guido observed ERANGE is not generated with ieee, even for overflow. So it is the same behavior as 1.5.2. Besides, no correct numerical code should depend on exceptions like this unless the machine is incapable of handling Inf and NaN. Even in the cases where you do want to detect overflow, it is still wrong to use exceptions. Here's an example: x*log(x) approaches 0 as x approaches 0. If x==0 then log(x)==-Inf but 0*-Inf==NaN, not what one would want. But exception is the wrong tool to hangle this, because if x is an array, some of its element may be zero but other's may not. The right way to do it is something like def entropy(probability): p = max(probability, 1e-323) return p*log(p) [Tim Peters] > In no case can you expect to see overflow ignored in 2.0. You are proposing a dramatic change from the behavior of 1.5.2. This looks like to me to need a PEP and a big debate. It would break a LOT of numerical computations. [Thomas Wouters] > I remember the patch that did this, on SF. It was titled "don't link with > -lieee if it isn't necessary" or something. Not sure what it would break, > but mayhaps declaring -lieee necessary on glibc systems is the right fix ? > > (For the non-autoconf readers among us: the first snippet writes a test > program to see if the function '__fpu_control' exists when linking with > -lieee in addition to $LIBS, and if so, adds -lieee to $LIBS. The second > snippet writes a test program to see if the function '__fpu_control' > exists with the current collection of $LIBS. If it doesn't, it tries it > again with -lieee, > > Pesonally, I think the patch should just be reversed... The comment above > the check certainly could be read as 'Linux requires -lieee for correct > f.p. operations', and perhaps that's how it was meant. The patch as described seems to be based on flawed thinking. The numbers Inf and NaN are always necessary. The -lieee could only be unnecessary if the behavior is the same as IEEE. Obviously it isn't. So I second Thomas's suggestion. [Tim Peters] > If no progress is made on determining the true cause over the next few days, > I'll hack mathmodule.c to ignore ERANGE in the specific case the result > returned is a zero (which would "fix" your exp underflow problem without > stopping overflow detection). Since this will break code on any platform > where errno was set to ERANGE on underflow in 1.5.2, I'll need to have a > long discussion w/ Guido first. I *believe* that much is actually sellable > for 2.0, because it moves Python in a direction I know he likes regardless > of whether he ever becomes a 754 True Believer. [Guido van Rossum] > No, the configure patch is right. Tim will check in a change that > treats ERANGE with a return value of 0.0 as underflow (returning 0.0, > not raising OverflowError). What is the reason to do this? It looks like intetionally subverting ieee even when it is available. I thought Tim meant that only logistical problems prevent using ieee. If you do choose this route, please please please ignore ERANGE entirely, whether return value is zero or not. The only possible way that ERANGE could be useful at all is if it could be set independently for each element of an array, and if it behave as a warning instead of an exception, ie. the calculation would continue if it is not caught. Well, then, Inf and NaN serve this purpose perfectly. It is very reasonable to set errno in glibc for this; it is completely unreasonable to raise an exception in Python, because exceptions cannot be set to individual elements and they cannot be ignored. Huaiyu -- Huaiyu Zhu hzhu at users.sourceforge.net Matrix for Python Project http://MatPy.sourceforge.net From pauldubois at home.com Wed Oct 11 20:04:51 2000 From: pauldubois at home.com (Paul F. Dubois) Date: Wed, 11 Oct 2000 17:04:51 -0700 Subject: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: I don't have time to follow in detail this thread about changed behavior between versions. These observations are based on working with hundreds of code authors. I offer them as is. a. Nobody runs a serious numeric calculation without setting underflow-to-zero, in the hardware. You can't even afford the cost of software checks. Unfortunately there is no portable way to do that that I know of. b. Some people use Inf but most people want the code to STOP so they can find out where the INFS started. Otherwise, two hours later you have big arrays of Infs and no idea how it happened. Likewise sqrt(-1.) needs to stop, not put a zero and keep going. From guido at python.org Wed Oct 11 21:45:30 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 11 Oct 2000 20:45:30 -0500 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Your message of "Wed, 11 Oct 2000 17:04:51 MST." References: Message-ID: <200010120145.UAA02030@cj20424-a.reston1.va.home.com> > I don't have time to follow in detail this thread about changed behavior > between versions. These observations are based on working with hundreds of > code authors. I offer them as is. > > a. Nobody runs a serious numeric calculation without setting > underflow-to-zero, in the hardware. You can't even afford the cost of > software checks. Unfortunately there is no portable way to do that that I > know of. > > b. Some people use Inf but most people want the code to STOP so they can > find out where the INFS started. Otherwise, two hours later you have big > arrays of Infs and no idea how it happened. Likewise sqrt(-1.) needs to > stop, not put a zero and keep going. Thanks, Paul! This behavior has always been what I wanted Python to do (even though it's not always what Python did, depending on the platform) and also what Tim's proposed patch will implement for the specific case of math.exp() (and other math functions that may underflow or overflow), on most reasonable platforms. There are still lots of places where the platform gives Python no choice of creating NaN and Inf, and because there's no platform-independent way to test for these, they are hard to avoid in some cases; but eventually, Tim will find a way to root them out. And for people like Huaiyu, who want to see Inf, there will (eventually) be a way to select this as a run-time option; and ditto for whoever might want underflow to raise an exception. --Guido van Rossum (home page: http://www.python.org/~guido/) From huaiyu_zhu at yahoo.com Wed Oct 11 22:22:54 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Wed, 11 Oct 2000 19:22:54 -0700 (PDT) Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <200010120145.UAA02030@cj20424-a.reston1.va.home.com> Message-ID: [Paul Dubois] > > > > a. Nobody runs a serious numeric calculation without setting > > underflow-to-zero, in the hardware. You can't even afford the cost of > > software checks. Unfortunately there is no portable way to do that that I > > know of. Amen. > > > > b. Some people use Inf but most people want the code to STOP so they can > > find out where the INFS started. Otherwise, two hours later you have big > > arrays of Infs and no idea how it happened. Likewise sqrt(-1.) needs to > > stop, not put a zero and keep going. $ /usr/bin/python Python 1.5.2 (#1, Sep 17 1999, 20:15:36) [GCC egcs-2.91.66 19990314/Linux (egcs- on linux-i386 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> from math import * >>> exp(777) inf >>> exp(-777) 0.0 >>> sqrt(-1) Traceback (innermost last): File "", line 1, in ? OverflowError: math range error This was sane behavior. Are we saying that Python 2.0 has invented something better than IEEE 754? [Guido van Rossum] > Thanks, Paul! This behavior has always been what I wanted Python to > do (even though it's not always what Python did, depending on the > platform) and also what Tim's proposed patch will implement for the > specific case of math.exp() (and other math functions that may > underflow or overflow), on most reasonable platforms. Guido, with due respect to your decisions on Python issues, I simply have to fight this one. It is one thing to accomodate for naive users, but it is another to dumb down every one else. Case 1. Someone writes a flawed numerical routine. Two hours later he finds his array filled with Inf and NaN. Case 2. Someone writes a perfect numerical routine. Two hours later he gets an exception, because the error is near zero. Solution for case 1. Use better algorithm. Use better error control. Raise exceptions when error is too large. These are proper solutions. They are easy and efficient to implement. They are needed anyway - If something's wrong, you want to raise exceptions far earlier than Inf, certainly before you get arrays filled with elements like 1e300. Solution for case 2. Almost impossible. The division between under- and over-flow is artificial. What about 1/x or similar functions? The only way to work on such a platform is to abandon vectorized computation. > There are still lots of places where the platform gives Python no > choice of creating NaN and Inf, and because there's no > platform-independent way to test for these, they are hard to avoid in > some cases; but eventually, Tim will find a way to root them out. And > for people like Huaiyu, who want to see Inf, there will (eventually) > be a way to select this as a run-time option; and ditto for whoever > might want underflow to raise an exception. I can understand that exceptions are the only available choices if IEEE is not available. But is there a compelling reason that Python should behave "better" than IEEE when it's in fact available? If the reason is to protect naive users, I can think of several responses: 1. For people doing one-off interactive work, returning Inf is in fact more informative. 2. For users iterative numerical computations, they need to be educated about error control. Otherwise they won't get corrent results anyway. 3. For really serious work, we could provide good numerical modules so that they don't need to write themselves. To make this happen fast the fewer debacles like this one the better. Case in point: Someone asked for regession modules two weeks ago. I was trying to convert my old matlab programs, which only took a few hours. But I wasted a week of (spare) time fighting for some mysterious "overflow". Turns out that a Guassian is near zero when it's far from center, and Python does not like it. In practice, Inf may be generated more often as a proper value than by mistake. This is not an issue about whether someone "prefers" Inf or exception. It is about whether there is a choice to do proper computation. Returning Inf does not prevent someone to raise exception. Raising exception automatically prevents perfect algorithms to work properly. As Kevin has volunteered to help with IEEE implementation and made a plan, is there a strong reason to drop IEEE for Linux in 2.0? If there is insufficient time to carry out his plan, wouldn't it be prudent to keep things as they were in 1.5.2? Huaiyu From tim_one at email.msn.com Wed Oct 11 22:44:20 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 11 Oct 2000 22:44:20 -0400 Subject: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: [Huaiyu Zhu] > On the issue of whether Python should ignore over/underflow on > IEEE-enabled platforms: > > It can be argued that on IEEE enabled systems the proper thing to do for > overflow is simply return Inf. Raising exception is WRONG. See below. Python was not designed with IEEE-754 in mind, and *anything* that happens wrt Infs, NaNs, and all other 754 features in Python is purely an accident that can and does vary wildly across platforms. And, as you've discovered in this case, can vary wildly also across even a single library, depending on config options. We cannot consider this to be a bug since Python has had no *intended* behavior whatsoever wrt 754 gimmicks. We can and do consider gripes about these accidents to be feature requests. [Guido] > Incidentally, math.exp(800) returns inf in 1.5, and raises > OverflowError in 2.0. So at least it's consistent. [Huaiyu] > That is not consistent at all. Please read with an assumption of good faith. Guido was pointing out that-- all in the specific case of gcc+glibc on Linux (these don't hold on other platforms) --exp(800) returning Inf in 1.5 and OverflowError in 2.0 is consistent *with* that exp(-800) returns 0 in 1.5 and raises an exception in 2.0. He's right; indeed, he is in part agreeing with you. [Guido > 1.5.2 links with -lieee while 2.0 doesn't. Removing -lieee from the > 1.5.2 link line makes is raise OverflowError too. Adding it to the > 2.0 link line makes it return 0.0 for exp(-1000) and inf for > exp(1000). [Huaiyu] > If using ieee is as simple as setting such a flag, there is no > reason at all not to use it. The patch to stop setting -lieee was contributed by a Python user who claimed it fixed bugs on *their* platform. That's "the reason". We don't want to screw them either. > Here are some more examples: > ... I understand that 754 semantics can be invaluable. So does Guido. There's no argument about that. But Python doesn't yet support them, and wishing it did doesn't make it so. If linking with -lieee happens to give you the semantics you want on your platform today, you're welcome to build with that switch. It appears to be a bad choice for *most* Python users, though (more below), so we don't want to do it in the std 2.0 distro. > ... > In practice this simply means Python would not be suitable for numerical > work at all. Your biggest obstacle in getting Python support for 754 will in fact be opposition from number-crunchers. I've been slinging fp for 21 years, 15 of those writing compilers and math libraries for "supercomputer" vendors. 754 is a Very Good Thing, but is Evil in subset form (see Kahan's (justified!) vilification of Java on this point); ironically, 754 is hardest to sell to those who could benefit from it the most. > What about the other way round? No problem. It is easy to write > functions like isNaN, isInf, etc. It's easy for a platform expert to write such functions for their specific platform of expertise, but it's impossible to write them in a portable way before C99 is implemented (C99 requires that library suppliers provide them, rendering the question moot). > ... > The language should never take over or subvert decisions based on > numerical analysis. Which is why a subset of 754 is evil. 754 requires that the user be able to *choose* whether or not, e.g., overflow signals an exception. Your crusade to insist that it never raise an exception is as least as bad (I think it's much worse) as Python's most common accidental behavior (where overflow from libm usually raises an exception). One size does not fit all. [Tim] > Ignoring ERANGE entirely is not at all the same behavior as 1.5.2, and > current code certainly relies on detecting overflows in math functions. [Huaiyu] > As Guido observed ERANGE is not generated with ieee, even for > overflow. So it is the same behavior as 1.5.2. You've got a bit of a case of tunnel vision here, Huaiyu. Yes, in the specific case of gcc+glibc+Linux, ignoring ERANGE returned from exp() is what 1.5.2 acted like. But you have not proposed to ignore it merely from ERANGE returned from exp() in the specific case of gcc+glibc+Linux. This code runs on many dozens of platforms, and, e.g., as I suggested before, it looks like HPUX has always set errno on both overflow and underflow. MS Windows sets it on overflow but not underflow. Etc. We have to worry about the effects on all platforms. > Besides, no correct numerical code should depend on exceptions like > this unless the machine is incapable of handling Inf and NaN. Nonsense. 754 provides the option to raise an exception on overflow, or not, at the user's discretion, precisely because exceptions are sometimes more appropriate than Infs of NaNs. Kahan himself isn't happy with Infs and NaNs because they're too often too gross a clue (see his writings on "presubstitution" for a more useful approach). [Tim] > In no case can you expect to see overflow ignored in 2.0. [Huaiyu] > You are proposing a dramatic change from the behavior of 1.5.2. > This looks like to me to need a PEP and a big debate. It would break > a LOT of numerical computations. I personally doubt that, but realize it may be true. That's why he have beta releases. So far yours is the only feedback we've heard (thanks!), and as a result we're going to change 2.0 to stop griping about underflow, and do so in a way that will actually work across all platforms. We're probably going to break some HPUX programs as a result; but they were relying on accidents too. [Guido] > No, the configure patch is right. Tim will check in a change that > treats ERANGE with a return value of 0.0 as underflow (returning 0.0, > not raising OverflowError). [Huaiyu] > What is the reason to do this? It looks like intetionally subverting > ieee even when it is available. I thought Tim meant that only logistical > problems prevent using ieee. Python does not support 754 today. Period. I would like it to, but not in any half-assed, still platform-dependent, still random crap-shoot, still random subset of 754 features, still rigidly inflexible, way. When it does support it, Guido & I will argue that it should enable (what 754 calls) the overflow, divide-by-0 and invalid operation exceptions by default, and disable the underflow and inexact exceptions by default. This ensures that, under the default, an infinity or NaN can never be created from non-exceptional inputs without triggering an exception. Not only is that best for newbies, you'll find it's the *only* scheme for a default that can be sold to working number-crunchers (been there, done that, at Kendall Square Research). It also matches Guido's original, pre-754, *intent* for how Python numerics should work by default (it is, e.g., no accident that Python has always had an OverflowError exception but never an UnderflowError one). And that corresponds to the change Guido says I'm going to make in mathmodule.c: suppress complaints about underflow, but let complaints about overflow go through. This is not a solution, it's a step on a path towards a solution. The next step (which will not happen for 2.0!) is to provide an explicit way to, from Python, disable overflow checking, and that's simply part of providing the control and inquiry functions mandated by 754. Then code that would rather deal with Infs than exceptions can, at its explicit discretion. > If you do choose this route, please please please ignore ERANGE entirely, > whether return value is zero or not. It should be clear that isn't going to happen. I realize that triggering overflow is going to piss you off, but you have to realize that not triggering overflow is going to piss more people off, and *especially* your fellow number-crunchers. Short of serious 754 support, picking "a winner" is the best we can do for now. You have the -lieee flag on your platform du jour if you can't bear it. [Paul Dubois] > I don't have time to follow in detail this thread about changed behavior > between versions. What makes you think we do <0.5 wink>? > These observations are based on working with hundreds of code authors. I > offer them as is. FWIW, they exactly match my observations from 15 years on the HW vendor side. > a. Nobody runs a serious numeric calculation without setting underflow-to- > zero, in the hardware. You can't even afford the cost of software checks. > Unfortunately there is no portable way to do that that I know of. C allows libm implementations a lot of discretion in whether to set errno to ERANGE in case of underflow. The change we're going to make is to ignore ERANGE in case of underflow, ensuring that math.* functions will *stop* raising underflow exceptions on all platforms (they'll return a zero instead; whether +0 or -0 will remain a platform-dependent crap shoot for now). Nothing here addresses underflow exceptions that may be raised by fp hardware, though; this has solely to do with the platform libm's treatment of errno. So in this respect, we're removing Python's current unpredictability, and in the way you favor. > b. Some people use Inf but most people want the code to STOP so they can > find out where the INFS started. Otherwise, two hours later you have big > arrays of Infs and no idea how it happened. Apparently Python on libc+glibc+Linux never raised OverflowError from math.* functions in 1.5.2 (although it did on most other platforms I know about). A patch checked in to fix some other complaint on some other Unixish platform had the side-effect of making Python on libc+glibc+Linux start raising OverflowError from math.* functions in 2.0, but in both overflow and underflow cases. We intend to (as above) suppress the underflow exceptions, but let the overflow cases continue to raise OverflowError. Huaiyu's original complaint was about the underflow cases, but (as such things often do) expanded beyond that when it became clear he would get what he asked for . Again we're removing Python's current unpredictability, and again in the way you favor -- although this one is still at the mercy of whether the platform libm sets errno correctly on overflow (but it seems that most do these days). > Likewise sqrt(-1.) needs to stop, not put a zero and keep going. Nobody has proposed changing anything about libm domain (as opposed to range) errors (although Huaiyu probably should if he's serious about his flavor of 754 subsetism -- I have no idea what gcc+glibc+Linux did here on 1.5.2, but it *should* have silently returned a NaN (not a zero) without setting errno if it was *self*-consistent -- anyone care to check that under -lieee?: import math math.sqrt(-1) NaN or ValueError? 2.0 should raise ValueError regardless of what 1.5.2 did here.). just-another-day-of-universal-python-harmony-ly y'rs - tim From sdm7g at virginia.edu Wed Oct 11 23:23:32 2000 From: sdm7g at virginia.edu (Steven D. Majewski) Date: Wed, 11 Oct 2000 23:23:32 -0400 (EDT) Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: First: I haven't followed this thread from the beginning -- only the last ten or so posts. Second: One reason I didn't follow it from the start is that I'm not doing any heavy numerical stuff in Python. I've been using Lisp for that, and use Python more for string/symbolic or GUI hacking. But, if I was going to do the sort of numerical stuff I now do in Lisp in Python, I would agree with Huaiya Zhu. I do a lot of vectorized operations on what are often independent samples. If some of the numbers overflow or underflow, that just represents an outlier or bad sample. I don't want it to blow off the whole pipeline of operations on the other data points in the vector -- they are independent of the bad points. In my case, it's not that these are lengthy calculations. It's that they are interactive and tied to immediate graphical representations. If there are strange zero's or infinities in the result, there is (or should be) a way to backtrack and investigate. ( That's why people want interactive and graphical regression analysis and modeling tools! ) The idea that your calculation should blow up and you should check it and resubmit your job sounds just so ancient-20th-century- Fortran-JCL-and-punched-cards-technology! ---| Steven D. Majewski (804-982-0831) |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| University of Virginia Health Sciences Center |--- ---| P.O. Box 10011 Charlottesville, VA 22906-0011 |--- "All operating systems want to be unix, All programming languages want to be lisp." From tim_one at email.msn.com Thu Oct 12 02:16:23 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 12 Oct 2000 02:16:23 -0400 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: [Huaiyu Zhu] > ... > $ /usr/bin/python > Python 1.5.2 (#1, Sep 17 1999, 20:15:36) [GCC egcs-2.91.66 19990314/Linux > (egcs- on linux-i386 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> from math import * > >>> exp(777) > inf > >>> exp(-777) > 0.0 > >>> sqrt(-1) > Traceback (innermost last): > File "", line 1, in ? > OverflowError: math range error > > This was sane behavior. Are we saying that Python 2.0 has invented > something better than IEEE 754? 754 allows users to choose the behaviors they want. Any *fixed* policy is not 754. So long as we have to fix a single policy, yes, I believe Guido (& know I) would say that raising OverflowError on exp(777), and silently returning 0 on exp(-777), and raising ValueError on sqrt(-1) (*not* OverflowError, as shown above), is indeed better than the 754 default behaviors. And 2.0 will do all three of those (& I just checked in the code to make that happen). About the sqrt example above, that's neither 754 behavior nor sane behavior: default 754 behavior on sqrt(-1) is to return a NaN and keep on going. I'm pretty sure that's what glibc linked w/ -lieee actually does, too (if it doesn't, glibc -lieee is violating 754). That 1.5.2 raised an OverflowError instead is insane, and appears purely due to an accident of how gcc compiles code to compare Infs to NaNs (Python's mathmodule.c's CHECK() macro was fooled by this into setting errno to ERANGE itself). Python should raise a ValueError there instead (corresponding to libm setting errno to EDOM -- this is a domain error, not a range error) -- which it does now under CVS Python. 754-doesn't-work-unless-you've-got-all-of-it-ly y'rs - tim From jhauser at ifm.uni-kiel.de Thu Oct 12 03:37:08 2000 From: jhauser at ifm.uni-kiel.de (Janko Hauser) Date: Thu, 12 Oct 2000 09:37:08 +0200 (CEST) Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: References: Message-ID: <20001012073708.15731.qmail@lisboa.ifm.uni-kiel.de> To look for another way out of this, the current problem are the two different wishes for vectorized computations to have NaN/Inf or Exceptions. As the actual computations for NumPy are all done in C, isn't it possible to implement a special signal handling in the NumPy code? As an option, for the people who know that they are then possibly in trouble (different behavior for arrays than for Python scalars) __Janko Just for the record. Python 1.5.2 (#1, May 10 1999, 18:46:39) [GCC egcs-2.91.60 Debian 2.1 (egcs-1.1. on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam (IPP) Type ? for more help >>> import math >>> math.sqrt(-1) Traceback (innermost last): File "", line 1, in ? OverflowError: math range error >>> math.exp(-800) 0.0 >>> math.exp(800) inf >>> >>> import Numeric >>> Numeric.exp(Numeric.array([800, -800.])) array([ inf, 0.00000000e+000]) >>> Numeric.sqrt(Numeric.array([-1])) array([ nan]) >>> # So the current behavior is already inconsistent on at least one >>> # platform # Other platform (DEC Alpha) raising domain error Python 1.5.2 (#6, Sep 20 1999, 17:44:09) [C] on osf1V4 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import math >>> math.exp(-800) Traceback (innermost last): File "", line 1, in ? OverflowError: math range error >>> math.exp(800) Traceback (innermost last): File "", line 1, in ? OverflowError: math range error >>> math.sqrt(-1) Traceback (innermost last): File "", line 1, in ? ValueError: math domain error >>> import Numeric >>> Numeric.exp(Numeric.array([800, -800.])) Traceback (innermost last): File "", line 1, in ? OverflowError: math range error >>> Numeric.sqrt(Numeric.array([-1])) Traceback (innermost last): File "", line 1, in ? ValueError: math domain error From thomas at xs4all.net Thu Oct 12 04:11:57 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 12 Oct 2000 10:11:57 +0200 Subject: [Numpy-discussion] Re: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: ; from tim_one@email.msn.com on Wed, Oct 11, 2000 at 10:44:20PM -0400 References: Message-ID: <20001012101157.Y12812@xs4all.nl> On Wed, Oct 11, 2000 at 10:44:20PM -0400, Tim Peters wrote: > > Likewise sqrt(-1.) needs to stop, not put a zero and keep going. > Nobody has proposed changing anything about libm domain (as opposed to > range) errors (although Huaiyu probably should if he's serious about his > flavor of 754 subsetism -- I have no idea what gcc+glibc+Linux did here on > 1.5.2, but it *should* have silently returned a NaN (not a zero) without > setting errno if it was *self*-consistent -- anyone care to check that > under -lieee?: > import math > math.sqrt(-1) >>> import math >>> math.sqrt(-1) Traceback (most recent call last): File "", line 1, in ? OverflowError: math range error The same under both 1.5.2 and 2.0c1 with -lieee. Without -lieee, both do: >>> import math >>> math.sqrt(-1) Traceback (innermost last): File "", line 1, in ? ValueError: math domain error Consistency-conschmistency-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Aureli.Soria_Frisch at ipk.fhg.de Thu Oct 12 08:22:14 2000 From: Aureli.Soria_Frisch at ipk.fhg.de (Aureli Soria Frisch) Date: Thu, 12 Oct 2000 14:22:14 +0200 Subject: [Numpy-discussion] Possible bug in LinearAlgebra module Message-ID: Hi, I have been working with the function (implmenting the Moore-Penrose generalized inverse) : generalized_inverse of the module LinearAlgebra. It seems to present a bug when operating on matrices of complex numbers. I want someone to confirm this point before submitting the source. Thanks in advance, Aureli ################################# Aureli Soria Frisch Fraunhofer IPK Dept. Pattern Recognition post: Pascalstr. 8-9, 10587 Berlin, Germany e-mail:aureli at ipk.fhg.de fon: +49 30 39 00 61 50 fax: +49 30 39 17 517 ################################# From gpk at bell-labs.com Thu Oct 12 11:01:19 2000 From: gpk at bell-labs.com (Greg Kochanski) Date: Thu, 12 Oct 2000 11:01:19 -0400 Subject: [Numpy-discussion] Re: Numpy-discussion digest, Vol 1 #112 - 8 msgs References: <200010120325.e9C3P1H01217@lists.sourceforge.net> Message-ID: <39E5D23F.2B647F6D@bell-labs.com> Python has *got* to ignore underflow exceptions. Otherwise, virtually any numeric calculation that subtracts numbers will fail for no good reason. Worse, it will fail in a very sporadic, data-dependent manner. With double precision numbers, the failures will be rare, but anyone doing computations with floats will see unwanted exceptions with noticeable frequency. I once did a numeric calculation (a SVD classifier) on a system with IEEE-754 underflow exceptions turned on, and I lost a good square inch of hair and a solid week of life because of it. At one point, the numbers were converted from doubles to floats, and about 1 in every 10,000,000 of the numbers were too small to represent as a float. So, in about 1 in ten runs (an hour each), the code would crash for no obvious reason. It was a debugging nightmare. If python catches underflows, I'm going back to FORTRAN. On less crucial topics, I'm strongly in favor of preserving NaN and Inf. If I want my code to crash when some computation goes awry, I'll use assert, and crash it myself. Any serious numeric code should be loaded with assertions (any code at all, in fact). Asking the interpreter to do it for you is a crude and blunt instrument. If I may ask, what kind of platforms are there where people do math where the hardware *won't* support IEEE-754? From pauldubois at home.com Thu Oct 12 11:17:53 2000 From: pauldubois at home.com (Paul F. Dubois) Date: Thu, 12 Oct 2000 08:17:53 -0700 Subject: [Numpy-discussion] Re: Numpy-discussion digest, Vol 1 #112 - 8 msgs In-Reply-To: <39E5D23F.2B647F6D@bell-labs.com> Message-ID: If I may ask, what kind of platforms are there where people do math where the hardware *won't* support IEEE-754? _______________________________________________ The problem isn't that the hardware doesn't support it, although there used to be some important machines that didn't. (Burton Smith once told me that adding this to a supercomputer architecture slows down the cycle time by a very considerable amount, he guessed at least 20% if I recall correctly.) The problem is that access to control the hardware has no standard. Usually you have to get out the Fortran manual and look in the back if you're lucky. I've had computers where I couldn't find this information at all. Probably things have improved in the last few years but this situation is still not great. Worse, it needs to be a runtime control, not a compile option. As everyone who has tried it found out, actually using the Infs and NaN's in any portable way is pretty difficult. I prefer algorithmic vigor to prevent their appearance. While my opinion is a minority one, I wish the "standard" had never been born and I had my cycles back. It isn't really a standard, is it? From nick at nickbower.com Thu Oct 12 11:30:22 2000 From: nick at nickbower.com (Nick Bower) Date: Thu, 12 Oct 2000 15:30:22 GMT Subject: [Numpy-discussion] Re: Numpy-discussion digest, Vol 1 #112 - 8 msgs In-Reply-To: <39E5D23F.2B647F6D@bell-labs.com> References: <200010120325.e9C3P1H01217@lists.sourceforge.net> <39E5D23F.2B647F6D@bell-labs.com> Message-ID: <20001012.15302200@cricket.> > So, in about 1 in ten runs (an hour each), the code > would crash for no obvious reason. It was a debugging > nightmare. If python catches underflows, I'm going > back to FORTRAN. hear hear. or is that here here ;) but it is a scarey concept isn't it? i've pieced together an interactive python visualization environment (a clone of RSI's IDL in fact - nickbower.com/computer/pydl) and although i didn't write the plot engine, surely there's no way to "make the algorithm better" if you have no idea if the user will try to graph asymptotic curves for example. it's just not realistic to expect the compiler to bomb out and force the user to tweak the calculation limits. > On less crucial topics, I'm strongly in favor of > preserving NaN and Inf. If I want my code to crash > when some computation goes awry, I'll use assert, > and crash it myself. i'm in favour of this too. i think favouring people who don't want to come back after hours of code execution to find Nan and Inf arrays may shaft a great deal of people (be it a minority or not). nick From hinsen at dirac.cnrs-orleans.fr Thu Oct 12 13:24:18 2000 From: hinsen at dirac.cnrs-orleans.fr (hinsen at dirac.cnrs-orleans.fr) Date: Thu, 12 Oct 2000 19:24:18 +0200 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: (sdm7g@virginia.edu) References: Message-ID: <200010121724.TAA15487@chinon.cnrs-orleans.fr> > The idea that your calculation should blow up and you should > check it and resubmit your job sounds just so ancient-20th-century- > Fortran-JCL-and-punched-cards-technology! Long-running jobs are still with us, even there's neither Fortran nor JCL in them. And for these applications, stopping is better than going on with nonsense values. On the other hand, as you point out, exceptions for math errors are a bit of a pain for interactive work. So how about making this a run-time option? I'd choose exceptions by default and Infs and Nans by specifying a command-line option, but there are certainly others who would prefer it the other way round. What matters most to me is that the choice is possible somehow. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen at cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From hinsen at cnrs-orleans.fr Thu Oct 12 13:26:29 2000 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Thu, 12 Oct 2000 19:26:29 +0200 Subject: [Numpy-discussion] Possible bug in LinearAlgebra module In-Reply-To: (message from Aureli Soria Frisch on Thu, 12 Oct 2000 14:22:14 +0200) References: Message-ID: <200010121726.TAA15490@chinon.cnrs-orleans.fr> > I have been working with the function (implmenting the Moore-Penrose > generalized inverse) : > > generalized_inverse > > of the module LinearAlgebra. It seems to present a bug when operating on > matrices of complex numbers. That is well possible. I use this function a lot but always on real matrices. I am not sure I even tested it on complex matrices when I wrote it ages ago. If you have a fix, it is certainly appreciated. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen at cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From Robert.Harrison at pnl.gov Thu Oct 12 13:37:20 2000 From: Robert.Harrison at pnl.gov (Harrison, Robert J) Date: Thu, 12 Oct 2000 10:37:20 -0700 Subject: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) Message-ID: I watch but rarely contribute to these dicussions, but I feel compelled to whole heartedly support Tim Peters comments regarding full 754 support with consistent cross platform behaviour. Like Tim I've being doing numerical computing for over two decades and IEEE is an indispensible standard. Yes, we usually disable most exception handling within performance critical kernels, but within robust solvers or modern linear algebra packages, full IEEE exception handling is vital. As Tim has said, full 754 will satisfy all users to the maximum extent possible. Robert -----Original Message----- From: Tim Peters [mailto:tim_one at email.msn.com] Sent: Wednesday, October 11, 2000 7:44 PM To: Huaiyu Zhu Cc: python-list at python.org; PythonDev; Numpy-Discussion; dubois at users.sourceforge.net Subject: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) [Huaiyu Zhu] > On the issue of whether Python should ignore over/underflow on > IEEE-enabled platforms: > > It can be argued that on IEEE enabled systems the proper thing to do for > overflow is simply return Inf. Raising exception is WRONG. See below. Python was not designed with IEEE-754 in mind, and *anything* that happens wrt Infs, NaNs, and all other 754 features in Python is purely an accident that can and does vary wildly across platforms. And, as you've discovered in this case, can vary wildly also across even a single library, depending on config options. We cannot consider this to be a bug since Python has had no *intended* behavior whatsoever wrt 754 gimmicks. We can and do consider gripes about these accidents to be feature requests. [Guido] > Incidentally, math.exp(800) returns inf in 1.5, and raises > OverflowError in 2.0. So at least it's consistent. [Huaiyu] > That is not consistent at all. Please read with an assumption of good faith. Guido was pointing out that-- all in the specific case of gcc+glibc on Linux (these don't hold on other platforms) --exp(800) returning Inf in 1.5 and OverflowError in 2.0 is consistent *with* that exp(-800) returns 0 in 1.5 and raises an exception in 2.0. He's right; indeed, he is in part agreeing with you. [Guido > 1.5.2 links with -lieee while 2.0 doesn't. Removing -lieee from the > 1.5.2 link line makes is raise OverflowError too. Adding it to the > 2.0 link line makes it return 0.0 for exp(-1000) and inf for > exp(1000). [Huaiyu] > If using ieee is as simple as setting such a flag, there is no > reason at all not to use it. The patch to stop setting -lieee was contributed by a Python user who claimed it fixed bugs on *their* platform. That's "the reason". We don't want to screw them either. > Here are some more examples: > ... I understand that 754 semantics can be invaluable. So does Guido. There's no argument about that. But Python doesn't yet support them, and wishing it did doesn't make it so. If linking with -lieee happens to give you the semantics you want on your platform today, you're welcome to build with that switch. It appears to be a bad choice for *most* Python users, though (more below), so we don't want to do it in the std 2.0 distro. > ... > In practice this simply means Python would not be suitable for numerical > work at all. Your biggest obstacle in getting Python support for 754 will in fact be opposition from number-crunchers. I've been slinging fp for 21 years, 15 of those writing compilers and math libraries for "supercomputer" vendors. 754 is a Very Good Thing, but is Evil in subset form (see Kahan's (justified!) vilification of Java on this point); ironically, 754 is hardest to sell to those who could benefit from it the most. > What about the other way round? No problem. It is easy to write > functions like isNaN, isInf, etc. It's easy for a platform expert to write such functions for their specific platform of expertise, but it's impossible to write them in a portable way before C99 is implemented (C99 requires that library suppliers provide them, rendering the question moot). > ... > The language should never take over or subvert decisions based on > numerical analysis. Which is why a subset of 754 is evil. 754 requires that the user be able to *choose* whether or not, e.g., overflow signals an exception. Your crusade to insist that it never raise an exception is as least as bad (I think it's much worse) as Python's most common accidental behavior (where overflow from libm usually raises an exception). One size does not fit all. [Tim] > Ignoring ERANGE entirely is not at all the same behavior as 1.5.2, and > current code certainly relies on detecting overflows in math functions. [Huaiyu] > As Guido observed ERANGE is not generated with ieee, even for > overflow. So it is the same behavior as 1.5.2. You've got a bit of a case of tunnel vision here, Huaiyu. Yes, in the specific case of gcc+glibc+Linux, ignoring ERANGE returned from exp() is what 1.5.2 acted like. But you have not proposed to ignore it merely from ERANGE returned from exp() in the specific case of gcc+glibc+Linux. This code runs on many dozens of platforms, and, e.g., as I suggested before, it looks like HPUX has always set errno on both overflow and underflow. MS Windows sets it on overflow but not underflow. Etc. We have to worry about the effects on all platforms. > Besides, no correct numerical code should depend on exceptions like > this unless the machine is incapable of handling Inf and NaN. Nonsense. 754 provides the option to raise an exception on overflow, or not, at the user's discretion, precisely because exceptions are sometimes more appropriate than Infs of NaNs. Kahan himself isn't happy with Infs and NaNs because they're too often too gross a clue (see his writings on "presubstitution" for a more useful approach). [Tim] > In no case can you expect to see overflow ignored in 2.0. [Huaiyu] > You are proposing a dramatic change from the behavior of 1.5.2. > This looks like to me to need a PEP and a big debate. It would break > a LOT of numerical computations. I personally doubt that, but realize it may be true. That's why he have beta releases. So far yours is the only feedback we've heard (thanks!), and as a result we're going to change 2.0 to stop griping about underflow, and do so in a way that will actually work across all platforms. We're probably going to break some HPUX programs as a result; but they were relying on accidents too. [Guido] > No, the configure patch is right. Tim will check in a change that > treats ERANGE with a return value of 0.0 as underflow (returning 0.0, > not raising OverflowError). [Huaiyu] > What is the reason to do this? It looks like intetionally subverting > ieee even when it is available. I thought Tim meant that only logistical > problems prevent using ieee. Python does not support 754 today. Period. I would like it to, but not in any half-assed, still platform-dependent, still random crap-shoot, still random subset of 754 features, still rigidly inflexible, way. When it does support it, Guido & I will argue that it should enable (what 754 calls) the overflow, divide-by-0 and invalid operation exceptions by default, and disable the underflow and inexact exceptions by default. This ensures that, under the default, an infinity or NaN can never be created from non-exceptional inputs without triggering an exception. Not only is that best for newbies, you'll find it's the *only* scheme for a default that can be sold to working number-crunchers (been there, done that, at Kendall Square Research). It also matches Guido's original, pre-754, *intent* for how Python numerics should work by default (it is, e.g., no accident that Python has always had an OverflowError exception but never an UnderflowError one). And that corresponds to the change Guido says I'm going to make in mathmodule.c: suppress complaints about underflow, but let complaints about overflow go through. This is not a solution, it's a step on a path towards a solution. The next step (which will not happen for 2.0!) is to provide an explicit way to, from Python, disable overflow checking, and that's simply part of providing the control and inquiry functions mandated by 754. Then code that would rather deal with Infs than exceptions can, at its explicit discretion. > If you do choose this route, please please please ignore ERANGE entirely, > whether return value is zero or not. It should be clear that isn't going to happen. I realize that triggering overflow is going to piss you off, but you have to realize that not triggering overflow is going to piss more people off, and *especially* your fellow number-crunchers. Short of serious 754 support, picking "a winner" is the best we can do for now. You have the -lieee flag on your platform du jour if you can't bear it. [Paul Dubois] > I don't have time to follow in detail this thread about changed behavior > between versions. What makes you think we do <0.5 wink>? > These observations are based on working with hundreds of code authors. I > offer them as is. FWIW, they exactly match my observations from 15 years on the HW vendor side. > a. Nobody runs a serious numeric calculation without setting underflow-to- > zero, in the hardware. You can't even afford the cost of software checks. > Unfortunately there is no portable way to do that that I know of. C allows libm implementations a lot of discretion in whether to set errno to ERANGE in case of underflow. The change we're going to make is to ignore ERANGE in case of underflow, ensuring that math.* functions will *stop* raising underflow exceptions on all platforms (they'll return a zero instead; whether +0 or -0 will remain a platform-dependent crap shoot for now). Nothing here addresses underflow exceptions that may be raised by fp hardware, though; this has solely to do with the platform libm's treatment of errno. So in this respect, we're removing Python's current unpredictability, and in the way you favor. > b. Some people use Inf but most people want the code to STOP so they can > find out where the INFS started. Otherwise, two hours later you have big > arrays of Infs and no idea how it happened. Apparently Python on libc+glibc+Linux never raised OverflowError from math.* functions in 1.5.2 (although it did on most other platforms I know about). A patch checked in to fix some other complaint on some other Unixish platform had the side-effect of making Python on libc+glibc+Linux start raising OverflowError from math.* functions in 2.0, but in both overflow and underflow cases. We intend to (as above) suppress the underflow exceptions, but let the overflow cases continue to raise OverflowError. Huaiyu's original complaint was about the underflow cases, but (as such things often do) expanded beyond that when it became clear he would get what he asked for . Again we're removing Python's current unpredictability, and again in the way you favor -- although this one is still at the mercy of whether the platform libm sets errno correctly on overflow (but it seems that most do these days). > Likewise sqrt(-1.) needs to stop, not put a zero and keep going. Nobody has proposed changing anything about libm domain (as opposed to range) errors (although Huaiyu probably should if he's serious about his flavor of 754 subsetism -- I have no idea what gcc+glibc+Linux did here on 1.5.2, but it *should* have silently returned a NaN (not a zero) without setting errno if it was *self*-consistent -- anyone care to check that under -lieee?: import math math.sqrt(-1) NaN or ValueError? 2.0 should raise ValueError regardless of what 1.5.2 did here.). just-another-day-of-universal-python-harmony-ly y'rs - tim _______________________________________________ Numpy-discussion mailing list Numpy-discussion at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/numpy-discussion From cgw at fnal.gov Thu Oct 12 14:24:55 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Thu, 12 Oct 2000 13:24:55 -0500 (CDT) Subject: [Numpy-discussion] Possible bug in LinearAlgebra module In-Reply-To: References: Message-ID: <14822.503.389177.597875@buffalo.fnal.gov> Aureli Soria Frisch writes: > I have been working with the function (implmenting the Moore-Penrose > generalized inverse) : of the module LinearAlgebra. It seems to > present a bug when operating on matrices of complex numbers. This may or may not be related, but there are definitely problems with arrays of complex numbers sometimes being unneccessarily promoted to type "Object" - for example: Python 2.0b1 (#2, Sep 8 2000, 12:10:17) [GCC 2.95.2 19991024 (release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from Numeric import * >>> a = array([1,2,3], Complex) >>> a array([ 1.+0.j, 2.+0.j, 3.+0.j]) >>> a % 2.0 array([(1+0j) , 0j , (1+0j) ],'O') And we also know that there are a lot of problems with arrays of type "Object". So it's possible that somehow your Complex array is getting promoted to "Object" and running against a problem there. Just a guess, -cgw From sdm7g at virginia.edu Thu Oct 12 14:25:44 2000 From: sdm7g at virginia.edu (Steven D. Majewski) Date: Thu, 12 Oct 2000 14:25:44 -0400 (EDT) Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <200010121724.TAA15487@chinon.cnrs-orleans.fr> Message-ID: On Thu, 12 Oct 2000 hinsen at dirac.cnrs-orleans.fr wrote: > > The idea that your calculation should blow up and you should > > check it and resubmit your job sounds just so ancient-20th-century- > > Fortran-JCL-and-punched-cards-technology! > > Long-running jobs are still with us, even there's neither Fortran nor > JCL in them. And for these applications, stopping is better than going > on with nonsense values. On the other hand, as you point out, exceptions > for math errors are a bit of a pain for interactive work. > > So how about making this a run-time option? I'd choose exceptions by > default and Infs and Nans by specifying a command-line option, but > there are certainly others who would prefer it the other way round. > What matters most to me is that the choice is possible somehow. > I agree entirely! Maybe I was being a bit too glib, but I didn't mean to imply that wanting it to halt or throw an exception on errors is wrongheaded. I just wanted to make sure the counter-case to what Paul was saying also got heard: Yes-- underflows or infinities where they aren't expected are usually a sign that something is very wrong somewhere. But in the case where the vector holds independent observations or data points, then usually what it means is that there's something wrong with *that* data point -- miscallibrated or mislabeled -- but no reason not to complete the calculations for all of the other points. Scaling or doing projections for interactive graphics is another case where bad points are often better than throwing an exception. ( And it's a pain to have to remember to lambda wrap all the function calls with some sort of guard when you'ld be happy to get NaNs. ) I also mostly agree with Tim, except that I'm not sure that bad or incomplete ieee support is always better than none at all. ---| Steven D. Majewski (804-982-0831) |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| University of Virginia Health Sciences Center |--- ---| P.O. Box 10011 Charlottesville, VA 22906-0011 |--- "All operating systems want to be unix, All programming languages want to be lisp." From tim_one at email.msn.com Thu Oct 12 16:33:41 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 12 Oct 2000 16:33:41 -0400 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: [Steven D. Majewski] > ... > I also mostly agree with Tim, except that I'm not sure that bad or > incomplete ieee support is always better than none at all. This is true, because having Python is better than not having Python, and in having Python you indeed have bad *and* incomplete 754 support on every 754 platform it runs on. Even better, it's a subset of damaged 754 support unique to each platform whose details can't be guessed or documented in advance of trying it exhaustively to see what happens(*), and a subset that can change delightfully across releases, compiler upgrades, library upgrades and seemingly irrelevant minor config changes. So if bad or incomplete IEEE support is good, Python is-- here as elsewhere --the King of Languages . Every step of this dance is thoroughly predictable. In this case, I'm doing my darnedest to nudge Python its very first step towards *real* 754 support, and getting dumped on for it by a 754 fan. Simultaneously, the "old guard" defends their lifestyle against new-fangled ideas , asking for protections unaware that 754 *requires* they get a better form of the protections they seek than they've dreamed of so far. It appears that nobody on either side has actually read the std, and I've become the very 754 Storm Trooper I used to despise. Computer life is great . all-it's-missing-is-variety-ly y'rs - tim (*) Quiz: *if* you can manage to trick Python into creating a NaN on your particular 754 platform, does the Python expression NaN == 1.0 return true, false, or raise an exception? Answer before you try it. Then try it on enough 754 platforms until you give up trying to guess in advance. NaN == NaN is predictable in Python, and is the one 754 feature Python guarantees won't work correctly on any 754 platform (although I've heard that it loses this predictability when run using NumPy's flavor of comparisons instead of core Python's). From jonathan.gilligan at vanderbilt.edu Thu Oct 12 17:47:40 2000 From: jonathan.gilligan at vanderbilt.edu (Jonathan M. Gilligan) Date: Thu, 12 Oct 2000 16:47:40 -0500 Subject: [Numpy-discussion] Off-Topic 754 question (was RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: References: Message-ID: <5.0.0.25.0.20001012162809.02742290@g.mail.vanderbilt.edu> This is a bit off-topic, but I noticed that there are lots of experts here and I have a question about IEEE-754 that has been bugging me for some time and which I was not able to get a good answer for on the USENET newsgroups. I am hoping that one of the experts in this list will take pity on my ignorance and answer what should be a simple question. Under Microsoft Visual C++, the Standard C++ library's numeric_limits::signaling_NaN() and numeric_limits::signaling_NaN() both return -INF values. The numeric_limits::quiet_NaN() and numeric_limits::quiet_NaN() both return -IND. I have not been able to determine whether this is "proper" behavior or whether it is another example of Microsoft ignoring standards? I would have thought that one of the two should return NaN. I certainly can't for the life of me figure out why someone would call INF a NaN, but as I have said, I'm pretty ignorant. Right now, if I want to use NaN's in my C++ code (e.g., to initialize newly allocated memory blocks) I build NaNs thus: >static long iNAN[2] = >{ > 0xFFFFFFFF, 0xFFFFFFFF >}; > >static double dNAN( > *reinterpret_cast(iNaN)) but would prefer something a little less bit-tweaky. Microsoft's documentation that this is the way they intend their library to work may be found at: http://msdn.microsoft.com/library/devprods/vs6/visualc/vclang/sample_Members_of_the_numeric_limits_Class_(STL_Sample).htm#_sample_stl_numeric_limits_class Thanks, Jonathan ============================================================================= Jonathan M. Gilligan jonathan.gilligan at vanderbilt.edu The Robert T. Lagemann Assistant Professor Office: 615 343-6252 of Living State Physics Lab (FEL) 343-7580 Dept. of Physics and Astronomy, Box 1807-B Fax: 343-7263 6823 Stevenson Center Vanderbilt University, Nashville, TN 37235 Dep't Office: 322-2828 From hinsen at dirac.cnrs-orleans.fr Fri Oct 13 10:11:03 2000 From: hinsen at dirac.cnrs-orleans.fr (hinsen at dirac.cnrs-orleans.fr) Date: Fri, 13 Oct 2000 16:11:03 +0200 Subject: [Numpy-discussion] Possible bug in LinearAlgebra module In-Reply-To: <14822.503.389177.597875@buffalo.fnal.gov> (message from Charles G Waldman on Thu, 12 Oct 2000 13:24:55 -0500 (CDT)) References: <14822.503.389177.597875@buffalo.fnal.gov> Message-ID: <200010131411.QAA17618@chinon.cnrs-orleans.fr> > This may or may not be related, but there are definitely problems with > arrays of complex numbers sometimes being unneccessarily promoted to > type "Object" - for example: Interesting. I have been fighting against a strangely version-dependent bug in which similar unwanted promotions to Object arrays occur when ufuncs are called, and now I wonder if there is any relation. I have tried a few times to track this down, but the code is so, well, complicated that I never get far enough before I run out of time. > And we also know that there are a lot of problems with arrays of > type "Object". So it's possible that somehow your Complex array is > getting promoted to "Object" and running against a problem there. LinearAlgebra certainly doesn't (and won't) work for Object arrays; it can handle only the data types supported by LAPACK. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen at cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From tbreuel at parc.xerox.com Fri Oct 13 13:59:30 2000 From: tbreuel at parc.xerox.com (tbreuel at parc.xerox.com) Date: Fri, 13 Oct 2000 10:59:30 PDT Subject: [Numpy-discussion] Re: Numpy-discussion digest, Vol 1 #115 - 4 msgs In-Reply-To: <200010131916.e9DJGtH22268@lists.sourceforge.net> Message-ID: On Fri, 13 Oct 2000 numpy-discussion-request at lists.sourceforge.net wrote: > having Python you indeed have bad *and* incomplete 754 support on every 754 > platform it runs on. Well, it depends on what you mean by "bad *and* incomplete 754 support". IEEE recommends specific semantics for comparison operators in language bindings, but I think their recommendations are undesirable from a programming language and software engineering point of view. If you follow IEEE semantics, you prohibit optimizers from optimizing in many cases and it contradicts type system semantics in some languages. Worst of all, programs that rely on IEEE semantics (in particular, of comparison operators) give no lexical indication that they do so; they will simply do something wrong, like go into an infinite loop or terminate a loop prematurely. I think it's best to raise an exception for any expression involving a NaN, unless the programmer explicitly indicated that he wants a NaN result and IEEE semantics. Another good approach is to provide separate IEEE operators and leave the behavior of the built-in operators on IEEE special values explicitly undefined. This keeps people from relying on one behavior or the other. To me, the worst possible choice is to "implement IEEE semantics correctly", i.e., in the way the IEEE authors envisioned it. (Of course, IEEE is reasonably nice from a numerical point of view; I just think they overextended themselves when talking about language bindings). > (*) Quiz: *if* you can manage to trick Python into creating a NaN on your > particular 754 platform, does the Python expression NaN == 1.0 return true, > false, or raise an exception? Answer before you try it. Then try it on > enough 754 platforms until you give up trying to guess in advance. NaN == > NaN is predictable in Python, and is the one 754 feature Python guarantees > won't work correctly on any 754 platform (although I've heard that it loses > this predictability when run using NumPy's flavor of comparisons instead of > core Python's). This is just the sort of issue I was referring to. In many dynamic languages, the assumption is that pointer quality implies object equality. That's a perfectly reasonable semantic choice. While Python may not implement "754 correctly" in the sense of the (probably) Fortran-thinking IEEE floating point designers, I think Python's choice is correct and should not be altered. People who really want IEEE floating point comparison operations can use something like ieee.equal(a,b). That alerts the reader that something special is going on, it will fail on non-IEEE platforms (indicating that the code wouldn't work correctly there anyway), and it makes only the code that needs to pay the price for strict IEEE conformance. Cheers, Thomas. From sdhyok at email.unc.edu Fri Oct 13 20:25:53 2000 From: sdhyok at email.unc.edu (Daehyok Shin) Date: Fri, 13 Oct 2000 17:25:53 -0700 Subject: [Numpy-discussion] [Q]Best way for an array operation? Message-ID: <008601c03575$5036fa80$52f9a218@nc.rr.com> What is the best Numpy way for the following work? for i in range(len(x)): if x[i] > 0: y[i] = v[i] z[i] = u[i]+2 Daehyok Shin (Peter) From jhauser at ifm.uni-kiel.de Fri Oct 13 19:13:23 2000 From: jhauser at ifm.uni-kiel.de (Janko Hauser) Date: Sat, 14 Oct 2000 01:13:23 +0200 (CEST) Subject: [Numpy-discussion] [Q]Best way for an array operation? In-Reply-To: <008601c03575$5036fa80$52f9a218@nc.rr.com> References: <008601c03575$5036fa80$52f9a218@nc.rr.com> Message-ID: <20001013231323.28257.qmail@lisboa.ifm.uni-kiel.de> You do not define, what values are in z,y if x < 0, so I presume, they keep the current value. >>> true = greater(x,0.) >>> z=where(true, u+2., z) >>> y=where(true, v, y) HTH, __Janko Daehyok Shin writes: > What is the best Numpy way for the following work? > > for i in range(len(x)): > if x[i] > 0: > y[i] = v[i] > z[i] = u[i]+2 > > Daehyok Shin (Peter) > > > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion at lists.sourceforge.net > http://lists.sourceforge.net/mailman/listinfo/numpy-discussion From cbarker at jps.net Fri Oct 13 21:22:28 2000 From: cbarker at jps.net (Chris Barker) Date: Fri, 13 Oct 2000 18:22:28 -0700 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) References: Message-ID: <39E7B554.29A168E3@jps.net> Incomplete vs. non-at-all IEEE 754 support is a non argument. If you have full IEEE support (which it seems everyone here thinks would be good, but difficult), it is clear what you have. If not, you are not consistent with a standard, and therefor making up your own. That being the case, it's a matter of what we want the Python standard to be. I, for one think that NaN and Inf are fantastic!!! I think the best argument for them here is that it is almost impossible to do a lot of array based calculations without them, and you can't do serious number crunching in Python without array based calculations. I've come to Python from MATLAB for numerics, and I really appreciated MATLAB's way of handling all this. I don't think MATLAB has true 754 support, as I don't think you can change the behaviour, but you do get a consistent result across platforms (including non-iee machines like the Cray?---I have no idea). I have not yet heard a decent response to the question of what to do when a single value in a large array is bad, and causes an exception. This really does render Python essentially useless for Numerics for me. I suspect all those number crunchers that want an exception rather than an Inf are NOT using array-oriented languages. My goal is to dump MATLAB for Python, but this may prevent me from doing that. Does anyone know what other array-oriented languages use? I know what MATLAB does: >> exp(-777) ans = 0 >> exp(777) ans = Inf >> sqrt(-1) ans = 0 + 1.0000i Hey! I like that! Python is dynamic, why can't we just get the actual answer to sqrt(-1), without using cmath, that always returns a complex ? sorry, other subjet, not meant to be raised at the moment. >> 54/0 Warning: Divide by zero. ans = Inf Here we get a warning, but also a result that won't crash the computation. >> a = 0/0 Warning: Divide by zero. a = NaN >> b = a b = NaN >> a == b ans = 0 So comparing two NaNs yields a false, as it should, and though Python won't do it now, it could. One thing that a numerical routine should NEVER do is give an incorrect answer. No answer is often bad, but an incorrect one is much worse. NaN == NaN must return false. Does anyone know what FORTRAN 90 specifies (if anything)? What other array-oriented languages are there? I think what MATLAB does is what Tim is calling "bad *and* incomplete 754 support" Incomplete is surely true, "bad" is clearly a matter of opinion. It seems we have a variety of users of numerics in Python, that I break into three broad catagories: Casual users: mostly doing non-numeric stuff, with the occasional calculation: This group could use any non-cryptic handling of over/underflow, it just doesn't matter. Mid-level number crunchers: This is the group I put myself in. We crunch a lot of numbers, really like the array semantics (and speed) of NumPy, and are doing things like graphing functions, statistical calculations, etc. We have probably only taken one of two (at most) numerical analysis courses, and many don't know what the heck IEE 754 is. (The one Numerical Analysis course I did take, happened to be with Kahan, which is why I know what it is) For this group, the incomplete IEEE support is probably the best way to go. We're more likely to be annoyed by our whole computation stopping because of one bad data point, than we are to be pissed off that it didn't stop when it started to compute garbage. Hard Core Number crunchers: These are the folks that do things like write optimised routines for particular architectures, adn teach numerical analysis courses. These folks want either FULL IEEE, or plain old "classic" overflow and underflow errors, that they can handle themselves. Do these folks really use Python as other than a glue language? Are they really doing massive number crunching in Python itself, rather than in C (or whatever) extensions? If so, I'd be surprised is they didn't find Huaiyu's argument compelling when doing array based calculations. Tim pointed out that Python was not designed with 754 in mind, so for 2.0, what he is doing is probably our best bet, but it seems to not be the best ultimate solution, I hope using NaN and Inf will be considered for future versions, even if it is incomplete 754 compliance. Note: if the ultimate goal is REAL IEEE 754 compliance, is it possible without custom re-compiling your own interpreter? If so, is there any chance that it will come any time soon (2.1 ?) , so we don't have to have this discussion at all? Thanks for all of your work on this, Python just keeps getting better!! -Chris -- Christopher Barker, Ph.D. cbarker at jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From cgw at fnal.gov Fri Oct 13 22:44:42 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Fri, 13 Oct 2000 21:44:42 -0500 (CDT) Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <39E7B554.29A168E3@jps.net> References: <39E7B554.29A168E3@jps.net> Message-ID: <14823.51354.977817.409017@buffalo.fnal.gov> Chris Barker writes: > Hey! I like that! Python is dynamic, why can't we just get the actual > answer to sqrt(-1), without using cmath, that always returns a complex ? You have to import the sqrt function from somewhere. Either you import it from math or from cmath, depending on which flavor you need. Anybody sophisticated enough to know what complex numbers are, and sophisticated enough to want to get complex values as a result of a calculation, should be sophisticated enough to be able to type "cmath". From pauldubois at home.com Sat Oct 14 11:58:37 2000 From: pauldubois at home.com (Paul F. Dubois) Date: Sat, 14 Oct 2000 08:58:37 -0700 Subject: [Numpy-discussion] [Q]Best way for an array operation? In-Reply-To: <008601c03575$5036fa80$52f9a218@nc.rr.com> Message-ID: There is (in CVS) a new function, putmask: c = greater(x, 0) putmask(y, c, v) putmask(z, c, u+2) The documentation is now online. Briefly: putmask(a, m, v) sets a to v where m is true. a must be a contiguous array m must be the same total size as a (shape ignored) v will be repeated as needed to that size The underlying work is done in C. -----Original Message----- From: numpy-discussion-admin at lists.sourceforge.net [mailto:numpy-discussion-admin at lists.sourceforge.net]On Behalf Of Daehyok Shin Sent: Friday, October 13, 2000 5:26 PM To: Numpy Discussion Subject: [Numpy-discussion] [Q]Best way for an array operation? What is the best Numpy way for the following work? for i in range(len(x)): if x[i] > 0: y[i] = v[i] z[i] = u[i]+2 Daehyok Shin (Peter) _______________________________________________ Numpy-discussion mailing list Numpy-discussion at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/numpy-discussion From jhauser at ifm.uni-kiel.de Sat Oct 14 14:32:33 2000 From: jhauser at ifm.uni-kiel.de (Janko Hauser) Date: Sat, 14 Oct 2000 20:32:33 +0200 (CEST) Subject: [Numpy-discussion] [Q]Best way for an array operation? In-Reply-To: References: <008601c03575$5036fa80$52f9a218@nc.rr.com> Message-ID: <20001014183233.28900.qmail@lisboa.ifm.uni-kiel.de> What is the difference of putmask and where? As it seems the only difference is the inplace behavior. This becomes more and more complicated as we have this subtle difference at many places (ravel vs. flat) and in future also the augmented assignment stuff, which also works for arrays now, although I do not know, if it's really an inplace assignment. What are the next functions for which a spacesaving variant is introduced? Would it be better to come to another convention for this type of optimization? As a side note the order of arguments is different for putmask and where. __Janko Paul F. Dubois writes: > There is (in CVS) a new function, putmask: > > c = greater(x, 0) > putmask(y, c, v) > putmask(z, c, u+2) > > The documentation is now online. Briefly: > putmask(a, m, v) sets a to v where m is true. > > a must be a contiguous array > m must be the same total size as a (shape ignored) > v will be repeated as needed to that size > > The underlying work is done in C. > > -----Original Message----- > From: numpy-discussion-admin at lists.sourceforge.net > [mailto:numpy-discussion-admin at lists.sourceforge.net]On Behalf Of > Daehyok Shin > Sent: Friday, October 13, 2000 5:26 PM > To: Numpy Discussion > Subject: [Numpy-discussion] [Q]Best way for an array operation? > > > What is the best Numpy way for the following work? > > for i in range(len(x)): > if x[i] > 0: > y[i] = v[i] > z[i] = u[i]+2 > > Daehyok Shin (Peter) > > > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion at lists.sourceforge.net > http://lists.sourceforge.net/mailman/listinfo/numpy-discussion > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion at lists.sourceforge.net > http://lists.sourceforge.net/mailman/listinfo/numpy-discussion From nick at nickbower.com Sun Oct 15 01:09:26 2000 From: nick at nickbower.com (Nick Bower) Date: Sun, 15 Oct 2000 05:09:26 GMT Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <39E7B554.29A168E3@jps.net> References: <39E7B554.29A168E3@jps.net> Message-ID: <20001015.5092600@cricket.> > Does anyone know what other array-oriented languages use? I know what > MATLAB does: I'm an Interactive Data Language or IDL user (the Univ of Wisconsin's Space Science Ceter is split down the middle between this and MatLab, but python/numpy is definitely on the increase). As you can see from results below, like MatLab over/under-flows in IDL are reported but do not stop execution. This is the best (only) possible scenario for an interactive arrays and visualization environment. IDL> print, exp(-777) 0.00000 % Program caused arithmetic error: Floating underflow IDL> print, exp(777) Inf % Program caused arithmetic error: Floating overflow IDL> print, sqrt(-1) -NaN % Program caused arithmetic error: Floating illegal operand IDL> print, 54/0 54 % Program caused arithmetic error: Integer divide by 0 From hinsen at cnrs-orleans.fr Sun Oct 15 15:04:27 2000 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Sun, 15 Oct 2000 21:04:27 +0200 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <39E7B554.29A168E3@jps.net> (message from Chris Barker on Fri, 13 Oct 2000 18:22:28 -0700) References: <39E7B554.29A168E3@jps.net> Message-ID: <200010151904.VAA32561@chinon.cnrs-orleans.fr> > I've come to Python from MATLAB for numerics, and I really appreciated > MATLAB's way of handling all this. I don't think MATLAB has true 754 MATLAB is fine for simple interactive data processing, and its behaviour is adapted to this task. I don't think anyone would use MATLAB for developing complex algorithms, its programming language isn't strong enough for that. Python is, so complex algorithms have to be considered as well. And for that kind of application, continuing a calculation with Infs and NaNs is a debugging nightmare. > I have not yet heard a decent response to the question of what to do > when a single value in a large array is bad, and causes an exception. I'd like to have at least the option of raising an exception in that case. Note that this is not what NumPy does today. > >> sqrt(-1) > ans = > 0 + 1.0000i > > Hey! I like that! Python is dynamic, why can't we just get the actual > answer to sqrt(-1), without using cmath, that always returns a complex ? For the same reason that makes 2/3 return zero instead of a float division result. Like C or Fortran, Python treats integers, floats, and complex numbers as different data types. And the return type of a function should depend only on the types, but not the values, of its parameters (for consistency, not because of any implementational limitation). So sqrt(a) for a of type float can either always return a float (math, Numeric) and crash for negative arguments, or always return a complex (cmath). The "right" solution, in my opinion, would be to have a single "number" type of which integers, float, and complex numbers are simply different internal representations. But such a change cannot be introduced without breaking a lot of code. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen at cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From tim_one at email.msn.com Sun Oct 15 16:35:27 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 15 Oct 2000 16:35:27 -0400 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <200010151904.VAA32561@chinon.cnrs-orleans.fr> Message-ID: [cbarker at jps.net] >> I've come to Python from MATLAB for numerics, and I really appreciated >> MATLAB's way of handling all this. I don't think MATLAB has true 754 ... [Konrad Hinsen] > MATLAB is fine for simple interactive data processing, and its > behaviour is adapted to this task. I don't think anyone would use > MATLAB for developing complex algorithms, its programming language > isn't strong enough for that. Python is, so complex algorithms have to > be considered as well. And for that kind of application, continuing a > calculation with Infs and NaNs is a debugging nightmare. A non-constructive (because futile) speculation: the first time I saw what 754 was intending to do, my immediate reaction was "hmm -- the exponent field is too narrow!". With a max (double) val in the ballpark of 1e300, you get an infinity as soon as you square something as small as 1e150, and once you get a few infinities, NaNs are sure to follow (due to Inf-Inf and Inf/Inf). The dynamic range for 754 singles is much smaller still. There's no doubt about Cray arithmetic being hard to live with, but while Mr. Cray didn't worry about proper rounding, he did devote 15 bits to Cray's exponent field (vs. 11 for 754). As a result, overflows were generally a non-issue on Cray boxes, and *nobody* complained (in my decade there) about Cray HW raising a fatal exception if one occurred. In return, you got only 48 bits of precision (vs. 53 for 754). But, for most physical problems, how accurate are the inputs? 10 bits on a good day, 20 bits on a great day? Crays worked despite their sloppy numerics because, for most problems to which they were applied, they carried more than twice the precision *and* dynamic range than the final results needed. >> I have not yet heard a decent response to the question of what to do >> when a single value in a large array is bad, and causes an exception. I'd usually trace back and try to figure out how it got "bad" to begin with ... > I'd like to have at least the option of raising an exception in that > case. Note that this is not what NumPy does today. Does NumPy use the fpectl module? I suppose not. LLNL contribued that code, but we hear very little feedback on it. It arranges to (in platform-dependent ways) convert the 754 overflow, divide-by-0 and invalid-operation signals into Python exceptions. In core Python, this is accomplished at the extraordinary expense of doing a setjmp before, and a function call + double->int conversion after, every single fp operation. A chief problem is that SIGFPE is the only handle C gives us on fp "errors", and the C std does not allow returning from a SIGFPE handler (the result of trying to is undefined, and indeed varies wildly across platforms); so if you want to regain control, you have to longjmp out of the handler. The NumPy implementation could use the PyFPE_START_PROTECT and PyFPE_END_PROTECT macros to brackete entire array operations, though, and so pay for the setjmp etc only once per array op. This is difficult stuff, but doable. >> >> sqrt(-1) >> ans = >> 0 + 1.0000i >> >> Hey! I like that! Python is dynamic, why can't we just get the actual >> answer to sqrt(-1), without using cmath, that always returns a complex ? > For the same reason that makes 2/3 return zero instead of a float > division result. Like C or Fortran, Python treats integers, floats, > and complex numbers as different data types. You know I'm in general agreement with you on this one, but I have to draw a distinction here: Guido thinks that 2/3 returning 0 was a design mistake, but not that math.sqrt(-1) raising an exception is a mistake. Most Python users won't know what to do with a complex number, so it's "an error" to them. I would like to view this in P3K (if not earlier) as being akin to 754 exceptions: some people are delighted to have 1e300**2 return +Inf, while others want to see OverflowError instead, and still others want to see +Inf *and* have a sticky flag set saying "an overflow occurred". We could treat f(x) (for f == sqrt and everything else) the same way wrt to a new ComplexResultFromNonComplexInputsError: define "non-stop" complex results, let the user choose whether to do nonstop or raise an exception, and a supply a sticky flag saying whether or not any complex results were generated from non-complex inputs. > ... > The "right" solution, in my opinion, would be to have a single > "number" type of which integers, float, and complex numbers are simply > different internal representations. But such a change cannot be > introduced without breaking a lot of code. The current distinction between ints and longs (unbounded ints) should also get swallowed by this. A way to get from here to there is especially irksome at the C API level, since, e.g., many C API functions pass Python ints as C longs directly. A smaller number pass Python floats as C doubles directly. it's-wonderful-that-p3k-will-solve-everything-ly y'rs - tim From jsaenz at wm.lc.ehu.es Mon Oct 16 11:45:43 2000 From: jsaenz at wm.lc.ehu.es (Jon Saenz) Date: Mon, 16 Oct 2000 17:45:43 +0200 (MET DST) Subject: [Numpy-discussion] ANNOUNCE: PyClimate 1.0 Message-ID: Monday, 10/16/2000 Hello, all. We are making the first announce of the first stable release (1.0) of our package pyclimate, which presents some tools used for climate variability analysis and which make extensive use of Numerical Python and C. It is released under the GNU Public License. Changes from the previous release Version 1.0--October, 2000. 1) Improved tests. They are more accurate, reliable, informative, comprehensive and use less disk space. 2) The package compiles using distutils. This feature has been checked on FreeBSD, Linux and OSF platforms. 3) Some minor typos corrected in the documentation. 4) Added KPDF.c, a extension module to estimate univariate and multivariate kernel--based probability density functions. 5) Added a class to compute the vertical component of the curl of a vectorial field in diffoperators.py. 6) DCDFLIB.C is currently distributed with the package. 7) KZFilter.py has been converted into a general purpose LinearFilter.py which holds the basic operations of any linear filter. There are two different subclasses currently, the Lanczos filter and the previous Kolmogorov--Zurbenko filter, KZFilter.py. The user can define new filters just by redefining the filter coefficients subclassing LinearFilter. The package also contains (from release 0.0): IO functions ------------ -ASCII files (simple, but useful) -ncstruct.py: netCDF structure copier. From a COARDS compliant netCDF file, this module creates a COARDS compliant file, copying the needed attributes, comments, and so on in one call. Time handling routines ---------------------- * JDTime.py -> Some C/Python functions to convert from date to Scaliger's Julian Day and from Julian Day to date. We are not trying to replace mxDate, but addressing a different problem. In particular, this module contains a routine especially suited to handling monthly time steps for climatological use. * JDTimeHandler.py -> Python module which parses the units attribute of the time variable in a COARDS file and which offsets and scales adequately the time values to read/save date fields. Interface to DCDFLIB.C ---------------------- A C/Python interface to the free DCDFLIB.C library is provided. This library allows direct and inverse computations of parameters for several probability distribution functions like Chi^2, normal, binomial, F, noncentral F, and many many more. EOF analysis ------------ Empirical Orthogonal Function analysis based on the SVD decomposition of the data matrix and related functions to test the reliability/degeneracy of eigenvalues (truncation rules). Monte Carlo test of the stability of eigenvectors to temporal subsampling. SVD decomposition ----------------- SVD decomposition of the correlation matrix of two datasets, functions to compute the expansion coefficients, the squared cumulative covariance fraction and the homogeneous and heterogeneous correlation maps. Monte Carlo test of the stability of singular vectors to temporal subsampling. Multivariate digital filter --------------------------- Multivariate digital filter (high and low pass) based on the Kolmogorov-Zurbenko filter Differential operators on the sphere ------------------------------------ Some classes to compute differential operators (gradient and divergence) on a regular latitude/longitude grid. LICENSE ======= GNU General Public License Version 2. PREREQUISITES ============= To be able to use it, you will need: 1. Python ;-) 2. netCDF library 3.4 or later 3. Scientific Python, by Konrad Hinsen IF AND ONLY IF you really want to change the C code (JDTime.[hc] and pycdf.[hc]), then, you will also need SWIG. COMPILATION =========== Now, we use distutils. The installation is simpler. DOCUMENTATION ============= Postscript and PDF versions of the manual are included in the distribution. We are preparing an even better version of the documentation. AVAILABILITY ============ http://lcdx00.wm.lc.ehu.es/~jsaenz/pyclimate (Europe) http://pyclimate.zubi.net/ (USA) http://starship.python.net/crew/~jsaenz (USA) Any feedback from the users of the package will be really appreciated by the authors. Enjoy. Jon Saenz, jsaenz at wm.lc.ehu.es Juan Zubillaga, wmpzuesj at lg.ehu.es Jesus Fernandez, chus at wm.lc.ehu.es

PyClimate 1.0 - Several routines for the analysis of climate variability. (16-Oct-00) From hinsen at cnrs-orleans.fr Mon Oct 16 11:52:43 2000 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Mon, 16 Oct 2000 17:52:43 +0200 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: References: Message-ID: <200010161552.RAA02685@chinon.cnrs-orleans.fr> > > I'd like to have at least the option of raising an exception in that > > case. Note that this is not what NumPy does today. > > Does NumPy use the fpectl module? I suppose not. LLNL contribued that No. Perhaps it should, but it doesn't make sense unless fpectl works on a large number of platforms. I confess I have never looked at it. I want my code to be portable, so I don't even consider using packages that aren't. > > For the same reason that makes 2/3 return zero instead of a float > > division result. Like C or Fortran, Python treats integers, floats, > > and complex numbers as different data types. > > You know I'm in general agreement with you on this one, but I have to draw a > distinction here: Guido thinks that 2/3 returning 0 was a design mistake, > but not that math.sqrt(-1) raising an exception is a mistake. Most Python > users won't know what to do with a complex number, so it's "an error" to > them. Well, that would be a good occasion to learn about complex numbers! I remember having learned about generalized inverses by using APL in high school (in a very similar way: I was amazed that it could invert non-square matrices), and that turned out to be very useful knowledge later on. Perhaps that's a topic for the EDU-SIG... Anyway, I don't care what math.sqrt(-1) does, but I would definitely prefer Numeric.sqrt(-1) to return a complex result. And I think that someone who uses NumPy has probably heard about complex numbers. > I would like to view this in P3K (if not earlier) as being akin to > 754 exceptions: some people are delighted to have 1e300**2 return +Inf, > while others want to see OverflowError instead, and still others want to see > +Inf *and* have a sticky flag set saying "an overflow occurred". We could > treat f(x) (for f == sqrt and everything else) the same way wrt to a new > ComplexResultFromNonComplexInputsError: define "non-stop" complex results, > let the user choose whether to do nonstop or raise an exception, and a > supply a sticky flag saying whether or not any complex results were > generated from non-complex inputs. There is, however, one difference: in properly debugged production code, there should be no overflow situations, so it doesn't matter much how they are treated. Complex number can (do!) occur in production code, but there could also be production code relying on exceptions for sqrt(-1) (e.g. for input error checking). Therefore a program using several libraries might be impossible to run with either setting. Since this concerns only the math module, I'd prefer to keep separate module versions for the two cases, which can be used in parallel. > > The "right" solution, in my opinion, would be to have a single > > "number" type of which integers, float, and complex numbers are simply > > different internal representations. But such a change cannot be > > introduced without breaking a lot of code. > > The current distinction between ints and longs (unbounded ints) should also > get swallowed by this. A way to get from here to there is especially > irksome at the C API level, since, e.g., many C API functions pass Python > ints as C longs directly. A smaller number pass Python floats as C doubles > directly. I don't see the problem in that direction, it's rather C API functions that *return* numbers in C data types that would be difficult to adapt. But then, why should be C API not be allowed in P3K? it's-wonderful-that-anything-may-be-changed-in-p3k'ly Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen at cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From cbarker at jps.net Mon Oct 16 13:38:11 2000 From: cbarker at jps.net (Chris Barker) Date: Mon, 16 Oct 2000 10:38:11 -0700 Subject: [Numpy-discussion] Re: numpy, overflow, inf, ieee, and rich comparison References: Message-ID: <39EB3D03.A00C78B6@jps.net> > >> I have not yet heard a decent response to the question of what to do > >> when a single value in a large array is bad, and causes an exception. > > I'd usually trace back and try to figure out how it got "bad" to begin with And from Konrad Hinsen >I'd like to have at least the option of raising an exception in that >case. Note that this is not what NumPy does today. Exactly. This was Huaiyu's point. The problem is that for your code to be usable for folks other than yourself, you'd have to have a lot of checks in there, and essentially revert to elementwise code, which would kill you. With the addition of the occasional "isnan" and something like Matlab's "any" ( "any(isnan(A))" returns true if any of the elements of A are NaNs) you could set up your code to raise an exception in the middle of computation. If, on the other hand the Code definiately raises an exception, than you are stuck with a lot of elementwise coding. > over/under-flows in IDL are reported but do > not stop execution. This is the best (only) possible scenario for an > interactive arrays and visualization environment. Exactly!!! ("the best (only) possible scenario" part) > IDL> print, 54/0 > 54 > % Program caused arithmetic error: Integer divide by 0 This, however, is wierd!! 54/0 == 54 ??? I'd much rather see a NaN or Inf here! > MATLAB is fine for simple interactive data processing, and its > behaviour is adapted to this task. I don't think anyone would use > MATLAB for developing complex algorithms, its programming language > isn't strong enough for that. Python is, so complex algorithms have to > be considered as well. And for that kind of application, continuing a > calculation with Infs and NaNs is a debugging nightmare. People do some pretty complex algorith develpment with MATLAB. I'm also no so sure about "continuing a calculation with Infs and NaNs is a debugging nightmare" I'm don't think it's any more of a nighmare than having your calculation on an entire array stop because of one Inf. It's just a different trade off. Sprinkle a few "isnan"'s in there and and you can get the behaviour you want, while not forcing it on all calculations. Of course, the best option is to have it switchable, but that may prove to be very difficult. Are people doing the kind of numeric programming with "complex algorithms" using Python that Konrad refers to? More importantly, how many people? > Guido thinks that 2/3 returning 0 was a design mistake, > but not that math.sqrt(-1) raising an exception is a mistake. Most Python > users won't know what to do with a complex number, so it's "an error" to > them. Guido's philosophy is clearly that Python defaults should be geared to "Most Python users". I agree, and as I wrote in an earlier post, the only users for whom the "exception raising only" option is best are the users Konrad refers to as writing "complex algorithms". I would argue that those users are few, and the group most able to deal with a less-that-optimum system. Maybe we can have true 754 compliance in Py3k, and we can all be happy!! -Chris -- Christopher Barker, Ph.D. cbarker at jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From pete at shinners.org Mon Oct 16 23:25:35 2000 From: pete at shinners.org (Pete Shinners) Date: Mon, 16 Oct 2000 20:25:35 -0700 Subject: [Numpy-discussion] compile for application Message-ID: <003301c037e9$ed436ae0$0200a8c0@home> i have a python application which has a small extension module it needs. (written in C for speed). does anyone have an example setup.py script that will build the extension, but leave the finished module in the current directory (and not intall to PYTHONHOME?) thanks From pete at shinners.org Mon Oct 16 23:58:56 2000 From: pete at shinners.org (Pete Shinners) Date: Mon, 16 Oct 2000 20:58:56 -0700 Subject: [Numpy-discussion] simple array help? Message-ID: <004a01c037ee$964dd040$0200a8c0@home> i have a simple array with floating values >>> print a array([ 0. , 0.2, 0.4, 0.6, 0.8]) what i need to do is change each index into another dimension with 3 indices. hmm, kind of confusing, an example will explain better >>> b = array(zip(a,a,a)) >>> print b array([[ 0. , 0. , 0. ], [ 0.2, 0.2, 0.2], [ 0.4, 0.4, 0.4], [ 0.6, 0.6, 0.6], [ 0.8, 0.8, 0.8]]) ok, this does the job, but once i start using large arrays, the back-n-forth conversion between arrays and python lists is costing me quite a bit. is there a way i can reshape the array this way without the call to python's 'zip'? (no, 'map' doesn't count either) i've tried much fooling with NewAxis, resize, and friends. but either i haven't stumbled upon the correct combination or i'm not trying the correct tools. i'd like to keep this as quick as possible, so hopefully it can be done without anything too elaborate. thanks (doh, sorry for the previous distutils related post... hit the wrong mailing list) From jhauser at ifm.uni-kiel.de Tue Oct 17 03:00:36 2000 From: jhauser at ifm.uni-kiel.de (Janko Hauser) Date: Tue, 17 Oct 2000 09:00:36 +0200 (CEST) Subject: [Numpy-discussion] simple array help? In-Reply-To: <004a01c037ee$964dd040$0200a8c0@home> References: <004a01c037ee$964dd040$0200a8c0@home> Message-ID: <20001017070036.7761.qmail@lisboa.ifm.uni-kiel.de> Your mail is in some windows format :-) reshape(resize(a,(1,15)),(5,3)) ,should do it, perhaps reshape makes a new copy, to circumvent this you can do it in two steps. b=resize(a,(1,15)) b.shape = (5,3) Another way is ones((5,3), a.typecode())*a[:,NewAxis] HTH, __Janko From hinsen at cnrs-orleans.fr Tue Oct 17 16:27:22 2000 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Tue, 17 Oct 2000 22:27:22 +0200 Subject: [Numpy-discussion] simple array help? In-Reply-To: <004a01c037ee$964dd040$0200a8c0@home> (pete@shinners.org) References: <004a01c037ee$964dd040$0200a8c0@home> Message-ID: <200010172027.WAA11910@chinon.cnrs-orleans.fr> > i have a simple array with floating values > >>> print a > array([ 0. , 0.2, 0.4, 0.6, 0.8]) There are probably many solutions, my preferred one is repeat(a[:, NewAxis], [3], 1) Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen at cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From hinsen at cnrs-orleans.fr Tue Oct 17 16:27:10 2000 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Tue, 17 Oct 2000 22:27:10 +0200 Subject: [Numpy-discussion] Re: numpy, overflow, inf, ieee, and rich comparison In-Reply-To: <39EB3D03.A00C78B6@jps.net> (message from Chris Barker on Mon, 16 Oct 2000 10:38:11 -0700) References: <39EB3D03.A00C78B6@jps.net> Message-ID: <200010172027.WAA11907@chinon.cnrs-orleans.fr> > Are people doing the kind of numeric programming with "complex > algorithms" using Python that Konrad refers to? More importantly, how > many people? At least one: me. > > Guido thinks that 2/3 returning 0 was a design mistake, > > but not that math.sqrt(-1) raising an exception is a mistake. Most Python > > users won't know what to do with a complex number, so it's "an error" to > > them. > > Guido's philosophy is clearly that Python defaults should be geared to > "Most Python users". I agree, and as I wrote in an earlier post, the It's difficult to say what "most Python users" want; it's not a static community. I'd say the basic principle is "no bad surprises". 2/3 == 0 is a bad surprise for anyone who knows elementary math but is not familiar with certain programming languages, especially since the program goes on silently with a "wrong" intermediate result. > Maybe we can have true 754 compliance in Py3k, and we can all be happy!! Py3k forever! Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen at cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From michael at visionpro.com Wed Oct 18 11:35:02 2000 From: michael at visionpro.com (Michael D. Risser) Date: Wed, 18 Oct 2000 08:35:02 -0700 Subject: [Numpy-discussion] Numpy install problems Message-ID: <00101808405300.01041@penguin.visionpro.com> When attempting to install Numeric 17.0 with Python 1.5.2 and Distutils 1.0 on Red Hat 7.0, I get the following error after issuing the command 'python setup.py install' Traceback (innermost last): File "setup.py", line 15, in ? vs = map(string.atoi, v.groups()) AttributeError: 'None' object has no attribute 'groups' This error occurs regardless of whether or not I am root. I have also tried uninstalling the Red Hat Python packages and installing all from source, but I get the same error. Any help would be appreciated. Thanks. From cbarker at jps.net Wed Oct 18 20:15:40 2000 From: cbarker at jps.net (Chris Barker) Date: Wed, 18 Oct 2000 17:15:40 -0700 Subject: [Numpy-discussion] PyArray_Check problem. References: <004a01c037ee$964dd040$0200a8c0@home> Message-ID: <39EE3D2C.51A92A71@jps.net> I have been working on my first C extension, using NumPy arrays, and have run into a problem. I have a very mysterious set of bugs, that result in a segmentation fault and core dump. Frankly it's still mysterious, but at the moment the problem seems to be that I have passed in a list of tuples, rather than a list of PyArrayObjects. I don't expect this to work, but when I put a : site = PyList_GetItem(spam_list, index); if (! PyArray_Check(spam)) result = 0; I shouldn't get a crash!! (and it does crash at this line, as near as I can tell) Isn't that exactly what PyArray_Check is for?? Note: with: spam = PyList_GetItem(spam_list, index); I get a "warning: assignment from incompatible pointer type " which goes away if I typecast it: spam = (PyArrayObject *) PyList_GetItem(spam_list, index); Should I be doing this, and should PyArray_Check(spam) work either way? I'm using Redhat Linux 6.1, Python 1.5.2, and python-numpy-1.11-2.i386.rpm Also: is there a compelling reason to upgrade either Python of NumPy, from the NumPy perspective? How are NumPy and 2.0 working together? Thanks, -Chris -- Christopher Barker, Ph.D. cbarker at jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From hinsen at cnrs-orleans.fr Thu Oct 19 13:25:24 2000 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Thu, 19 Oct 2000 19:25:24 +0200 Subject: [Numpy-discussion] PyArray_Check problem. In-Reply-To: <39EE3D2C.51A92A71@jps.net> (message from Chris Barker on Wed, 18 Oct 2000 17:15:40 -0700) References: <004a01c037ee$964dd040$0200a8c0@home> <39EE3D2C.51A92A71@jps.net> Message-ID: <200010191725.TAA14895@chinon.cnrs-orleans.fr> > fault and core dump. Frankly it's still mysterious, but at the moment > the problem seems to be that I have passed in a list of tuples, rather > than a list of PyArrayObjects. I don't expect this to work, but when I > put a : > > site = PyList_GetItem(spam_list, index); > > if (! PyArray_Check(spam)) result = 0; ^^^^ Not "site"? > I shouldn't get a crash!! (and it does crash at this line, as near as I > can tell) If spam is NULL, then the check will crash. If it is anything but a pointer to a Python object, there's a good chance that it might crash. PyArray_Check just tells you if a given Python object is of type "array". A look at the value of "spam" with a debugger should tell you what's going on. > which goes away if I typecast it: > > spam = (PyArrayObject *) PyList_GetItem(spam_list, index); > > Should I be doing this, and should PyArray_Check(spam) work either way? It works either way, but I am not sure that you are supposed to rely on that. I prefer to use a cast to array objects only *after* verifying that I have an array object, if only for clarity. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen at cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From busby at icf.llnl.gov Thu Oct 19 15:27:48 2000 From: busby at icf.llnl.gov (L. Busby) Date: Thu, 19 Oct 2000 12:27:48 -0700 (PDT) Subject: [Numpy-discussion] Re: comments on the Numerical Python manual Message-ID: <200010191927.MAA07139@icf.llnl.gov> Fred - I'm forwarding your mail on to numpy-discussion at lists.sourceforge.net, which I believe is the proper venue to deal with your comments. If the current Numerical Python manual directed you to support at icf.llnl.gov for support-related questions, that also needs to be updated. Thank you - Lee Busby ======================================================================= From: Fred Yankowski To: support at icf.llnl.gov Subject: comments on the Numerical Python manual Greetings, I'm learning NumPy by working through the "Numerical Python" manual (Oct 9, 2000 version). So far the manual has been a great introduction to the software and I really appreciate the work of the authors in providing it. I have found a couple of problems in the text, as follows: On page 4 in section 4, it seems that >>> vector1 = array((1,2,4,5)) should be the following instead: >>> vector1 = array((1,2,3,4,5)) On page 48 in section 8, the translation table used in the "brightening" function acts instead to darken the image. I found that scaling proportional to a square-root function worked well: table = (arange(256)**.5 * (255**.5)).astype('b') One side note: I'm surprised that the coordinate system used by the NumTut.view function has X axis values increasing to the left. Is that standard for some graphing systems? I've never worked with such a system before. Or am I misunderstanding what I'm seeing with view? I'm basing this on inspection of view(arange(100)**2)) and view(arange(100)**.5). -- Fred Yankowski fred at OntoSys.com tel: +1.630.879.1312 Principal Consultant www.OntoSys.com fax: +1.630.879.1370 OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA From cbarker at jps.net Thu Oct 19 17:13:26 2000 From: cbarker at jps.net (Chris Barker) Date: Thu, 19 Oct 2000 14:13:26 -0700 Subject: [Numpy-discussion] PyArray_Check problem. References: <004a01c037ee$964dd040$0200a8c0@home> <39EE3D2C.51A92A71@jps.net> <200010191725.TAA14895@chinon.cnrs-orleans.fr> Message-ID: <39EF63F6.B72C3853@jps.net> Konrad Hinsen wrote: > > site = PyList_GetItem(spam_list, index); > > > > if (! PyArray_Check(spam)) result = 0; > ^^^^ > > Not "site"? oops! I thought I had Pythonized everything by putting spam everywhere. > If spam is NULL, then the check will crash. If it is anything but a pointer > to a Python object, there's a good chance that it might crash. > PyArray_Check just tells you if a given Python object is of type "array". Fair enough. In this case, I was getting spam from a Python list. Is it possible for it to be anything but a pointer to a Python object? > A look at the value of "spam" with a debugger should tell you what's > going on. I have not yet figured out how to use a de-bugger with a python extension. Does anyone know of any nifty tutorial for how to do this (with gdb, preferably)? note that I'm a newby to C too, so I need a really basic run through. > > spam = (PyArrayObject *) PyList_GetItem(spam_list, index); > > > > Should I be doing this, and should PyArray_Check(spam) work either way? > > It works either way, but I am not sure that you are supposed to rely > on that. I prefer to use a cast to array objects only *after* > verifying that I have an array object, if only for clarity. That sounds like sound advice. I do feel like I'm doing something wrong if I get a warning form the compiler however. Thanks for your help. -Chris -- Christopher Barker, Ph.D. cbarker at jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From hinsen at cnrs-orleans.fr Fri Oct 20 09:08:40 2000 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Fri, 20 Oct 2000 15:08:40 +0200 Subject: [Numpy-discussion] PyArray_Check problem. In-Reply-To: <39EF63F6.B72C3853@jps.net> (message from Chris Barker on Thu, 19 Oct 2000 14:13:26 -0700) References: <004a01c037ee$964dd040$0200a8c0@home> <39EE3D2C.51A92A71@jps.net> <200010191725.TAA14895@chinon.cnrs-orleans.fr> <39EF63F6.B72C3853@jps.net> Message-ID: <200010201308.PAA15794@chinon.cnrs-orleans.fr> > > A look at the value of "spam" with a debugger should tell you what's > > going on. > > I have not yet figured out how to use a de-bugger with a python > extension. Does anyone know of any nifty tutorial for how to do this > (with gdb, preferably)? note that I'm a newby to C too, so I need a > really basic run through. I used gdb with gcc under Linux, and I just use it as I would on any other program: gdb /usr/bin/python run spam.py and wait for the crash. Of course your module should have been compiled with -g if you want symbolic debugging. The only difficulty with debugging extension modules built as dynamic libraries is setting breakpoints. You can't do it right away because the module isn't loaded yet, so its symbols are unknown to gdb. My solution is to start my script with the import, followed immediately by "time.sleep(5)". That gives me five seconds to press Control-C to reenter the debugger, and from then on everything works as advertised. If someone knows a more elegant solution, please let me know! Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen at cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From lull at acm.org Sat Oct 21 11:59:20 2000 From: lull at acm.org (John Lull) Date: Sat, 21 Oct 2000 08:59:20 -0700 Subject: [Numpy-discussion] COM/Numeric incompatibility Message-ID: <79c3vs8bnevekqnesha986tukshcbqsol3@4ax.com> (Also posted to comp.lang.python) (Addendum -- Mark Hammond suggests this may be a threading issue -- OpenDatabase() apparently causes Python threads to be initialized. Does NumPy or lapack lite use threads for anything?) I'm working on a Windows application that needs to use both Microsoft DAO and Numeric, & have run into a problem between the two. The following code illustrates the problem: from win32com.client import Dispatch engine = Dispatch("DAO.DBEngine.35") db = engine.OpenDatabase('c:\\test.mdb') from Numeric import array m = array([[1., 2.], [3., 4.]]) y = array([2., 1.]) from LinearAlgebra import linear_least_squares print linear_least_squares(m, y) print 'success!' The problem is that the statement 'print linear_...' never completes. I step through in the debugger under pythonwin, & the lapack routine called by linear_least_squares() never returns. If I remove the statement 'db = engine...' it completes normally. If I make a call to linear_least_squares() *before* the database stuff, the later call to linear_least_squares() works properly. test.mdb is an empty database created by Access 97. Using another database seems to make no difference. I am using: Python 1.52 win32all-132 NumPy 16.1 All are standard distribution builds. OS is Win98SE. DAO.DBEngine.35 resolves to DAO350.dll, dated 4/27/98. That, in turn (I believe) is using msJet35.dll dated 4/23/99. Any ideas? Thanks. Regards, John From hinsen at cnrs-orleans.fr Mon Oct 23 12:09:41 2000 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Mon, 23 Oct 2000 18:09:41 +0200 Subject: [Numpy-discussion] COM/Numeric incompatibility In-Reply-To: <79c3vs8bnevekqnesha986tukshcbqsol3@4ax.com> (message from John Lull on Sat, 21 Oct 2000 08:59:20 -0700) References: <79c3vs8bnevekqnesha986tukshcbqsol3@4ax.com> Message-ID: <200010231609.SAA19661@chinon.cnrs-orleans.fr> > (Addendum -- Mark Hammond suggests this may be a threading issue -- > OpenDatabase() apparently causes Python threads to be initialized. > Does NumPy or lapack lite use threads for anything?) No. > The problem is that the statement 'print linear_...' never completes. > I step through in the debugger under pythonwin, & the lapack routine > called by linear_least_squares() never returns. > > If I remove the statement 'db = engine...' it completes normally. > > If I make a call to linear_least_squares() *before* the database > stuff, the later call to linear_least_squares() works properly. I don't know how dynamic libraries work under Windows, but I could imagine that your database modules uses a symbol which is also used in Linpack or the Linpack/Python interface. There ought to be tools to verify this. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen at cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From johannes at zellner.org Tue Oct 24 13:04:12 2000 From: johannes at zellner.org (Johannes Zellner) Date: Tue, 24 Oct 2000 19:04:12 +0200 Subject: [Numpy-discussion] cvs modules Message-ID: <20001024190412.A19072@zellner.org> Hello, there are three modules Numerical numpy numpy2 in the cvs repository. Could someone explain the differences please ? -- Johannes From jhauser at ifm.uni-kiel.de Sat Oct 28 12:26:30 2000 From: jhauser at ifm.uni-kiel.de (Janko Hauser) Date: Sat, 28 Oct 2000 18:26:30 +0200 (CEST) Subject: [Numpy-discussion] Save use of savespace?! Message-ID: <20001028162630.30251.qmail@lisboa.ifm.uni-kiel.de> Hello, a question in the newsgroup got me thinking about the save use of the ``savespace'' flag in modules, which should be used by third party code. Think of this function as an example: def freezing(S,P): """Returns the freezing point temperature of seawater with a salinity S and at a pressure P. """ TF=(-.0575+1.710523e-3*_A.sqrt(_A.absolute(S))-2.154996e-4*S)*S-7.53e-4*P return TF This looks simple and one wants to use the savespace flag for S and P. So now the questions are rolling. What if S or P are scalars? Use asarray with the savespace flag. -> Error, this returns a copy of the array and not a reference, which is bad for array arguments. So use first asarray and then do asarray(S).savespace(1). Ok this works for the function, but we need to reset the flag at the end of the function. Also bad, what if S or P had the flag set before they entered the function? Ok I have now build a class, which actually keeps a record of these flags and has some helper methods to handle this record. The example function looks now: def freezing(S,P): SP=mkspacesaver(S,P) if not SP.isfloat(): raise ValueError, 'Arguments need to be of some float type' TF=(-.0575+1.710523e-3*_A.sqrt(_A.absolute(S))-2.154996e-4*S)*S-7.53e-4*P SP.free(); SP.clean(TF) return TF Note the test for float type, because if the user lazily entered an integer array for e.g. the pressure, the then set savespace flag would result in a very wrong answer. Although this seems to work for me, I do not know if this really presents a solution, as I actually need to put these lines into every similar function. The other way, to put the coeff. into an array has also problems, as I first need to find out of which type all arguments are and choose the highest one and it makes it more difficult to follow the coeff. in the formula. Any other suggestions, more general ways to handle argument testing? Is the savespace flag only suited for more closed environments, where one can assume more about the arguments? Class attached, __Janko class mkspacesaver: def __init__(self, *args): """Set for all arguments the savespace flag and make them to arrays. Keep track of this. At the end of the function, all flags can be reset, by a call to the method .free() """ self.refs = [] self.flags= [] for arg in args: try: arg.spacesaver() ref = arg except AttributeError: ref = afuncs.asarray(arg) self.flags.append(ref.spacesaver()) ref.savespace(1) self.refs.append(ref) def isfloat(self, index=None): """ Test if all refs have a float type, if a sequence is given for index, only the indexed refs are tested. """ if index: for i in index: if not self.refs[i].typecode() in ('f','d'): return 0 else: for i in range(len(self.refs)): if not self.refs[i].typecode() in ('f','d'): return 0 return 1 def free(self): for i in range(len(self.refs)): self.refs[i].savespace(self.flags[i]) def clean(self, *args): """Test if the arguments have the savespace flag set and set it to zero. Handle also scalars """ for arg in args: try: arg.savespace(0) except AttributeError: pass From gvermeul at labs.polycnrs-gre.fr Sun Oct 29 04:27:27 2000 From: gvermeul at labs.polycnrs-gre.fr (Gerard Vermeulen (CRTBT)) Date: Sun, 29 Oct 2000 10:27:27 +0100 Subject: [Numpy-discussion] Legal Notice Message-ID: <39FBED7F.CC3C5FE3@labs.polycnrs-gre.fr> I like to propose a numpy-RPM to MandrakeSoft for future inclusion in their contrib-cdroms. Of course, MandrakeSoft requires that all license issues are cleared. I understand that the file Legal.htm applies to the packages MA and RNG. Is this true? I like to point out that the phrase "Permission to use, copy, modify, and distribute this software for any purpose without fee is hereby granted, provided that this entire notice is included in all copies of any software which is or includes a copy or modification of this software and in all copies of the supporting documentation for such software. " is very restrictive. It forbids the inclusion of MA and RNG on a commercial CD rom. Isn't it? It also forbids a consultant to use it for his business. But what about somebody getting paid for his work in a government research laboratory? Could you replace this by something more BSD-like? Best regards -- Gerard Vermeulen From bernd at bpc.uni-frankfurt.de Mon Oct 30 08:34:48 2000 From: bernd at bpc.uni-frankfurt.de (Bernd Weyrauch) Date: Mon, 30 Oct 2000 14:34:48 +0100 Subject: [Numpy-discussion] Numeric-17.1.1 on IRIX 6.3 Message-ID: <00103014382805.04682@mephisto.bpc.uni-frankfurt.de> Hi, I tried to install Numeric-17.1.1 under IRIX 6.3 after installing Python 2.0 without optimization and the -g workaround. I got this error message: # /usr/local/bin/python setup.py install running install running build running build_py not copying Lib/ArrayPrinter.py (output up-to-date) not copying Lib/Numeric.py (output up-to-date) not copying Lib/Precision.py (output up-to-date) not copying Lib/UserArray.py (output up-to-date) not copying Lib/numeric_version.py (output up-to-date) running build_ext building '_numpy' extension skipping Src/_numpymodule.c (build/temp.irix-6.3-2.0/Src/_numpymodule.o up-to-date) skipping Src/arrayobject.c (build/temp.irix-6.3-2.0/Src/arrayobject.o up-to-date) skipping Src/ufuncobject.c (build/temp.irix-6.3-2.0/Src/ufuncobject.o up-to-date) ld -shared -all build/temp.irix-6.3-2.0/Src/_numpymodule.o build/temp.irix-6.3-2.0/Src/arrayobject.o build/temp.irix-6.3-2.0/Src/ufuncobject.o -o build/lib.irix-6.3-2.0/_numpy.so ld: ERROR 48: Cannot access registry file ./so_locations (No locks available) - ignored. ld: FATAL 51: Can't assign virtual addresses for _numpy.so within specified range. Please check your registry file ./so_locations. error: command 'ld' failed with exit status 4 Has anybody else encountered this problem? Thanks a lot! Bernd -- Bernd Weyrauch Marie-Curie-Str. 9 D-60439 Frankfurt am Main Institute of Biophysical Chemistry Tel. +49-(0)69-798-296-72 Frankfurt J. W. Goethe University Fax +49-(0)69-798-296-32 Biocenter, N230 e-mail bernd at bpc.uni-frankfurt.de http://www.biozentrum.uni-frankfurt.de/~bernd http://www.cthulhu.onlinehome.de From jh at oobleck.tn.cornell.edu Tue Oct 31 12:34:44 2000 From: jh at oobleck.tn.cornell.edu (Joe Harrington) Date: Tue, 31 Oct 2000 12:34:44 -0500 Subject: [Numpy-discussion] Re: Legal Notice (Gerard Vermeulen (CRTBT)) In-Reply-To: <200010292025.e9TKPKu14427@lists.sourceforge.net> (numpy-discussion-request@lists.sourceforge.net) References: <200010292025.e9TKPKu14427@lists.sourceforge.net> Message-ID: <200010311734.MAA19660@oobleck.tn.cornell.edu> Gerard, Could you explain why you think that the phrase you quoted is restrictive? Lots of software comes with that phrase, and it certainly hasn't inhibited its wide promulgation. All it says is that you can't pass off this software as your own, which would be lying anyway. As far as I can tell (I'm not a lawyer, etc.), it's far less restrictive than, say, GPL. It seems very like the BSD license you suggest using instead. If you include the packages in a larger work, you can just say: This work includes the blah blah package, which bears the following license: "Permission to use, copy, modify, and distribute this software for any purpose without fee is hereby granted, provided that this entire notice is included in all copies of any software which is or includes a copy or modification of this software and in all copies of the supporting documentation for such software. " Note that the notice *doesn't* say you have to *copyright* the larger package under the terms of the notice or to the owner of the included package, it just says you have to include the notice, presumably so the recipient knows that the package is in there, who the owner of that component is, and that distributing that part is allowed. If you look at the manuals to most commercial Unices, you'll find several pages of such notices from the owners of the various packages included in the system. What's the problem? --jh-- From pauldubois at home.com Tue Oct 31 17:58:05 2000 From: pauldubois at home.com (Paul F. Dubois) Date: Tue, 31 Oct 2000 14:58:05 -0800 Subject: [Numpy-discussion] Windows zip of Numerical Python 17.1.1 available Message-ID: Numerical 17.1.1 is available in both source and prebuilt Windows versions at: http://sourceforge.net/projects/numpy Windows users, simply extract into your top level Python 2.0 directory, typically c:\python20. Thank you to Pete Shinners for putting the Windows file together. It is too late to change for the 17 series but in future I will make releases that have whole numbers only as names and add files to that release as they become available. That makes it a little clearer that you should take the most recent file of the desired type. From gball at cfa.harvard.edu Tue Oct 31 18:31:57 2000 From: gball at cfa.harvard.edu (Greg Ball) Date: Tue, 31 Oct 2000 18:31:57 -0500 (EST) Subject: [Numpy-discussion] Re: Legal Notice In-Reply-To: <200010312134.e9VLY5u23517@lists.sourceforge.net> Message-ID: I think the way Gerard is interpreting this passage > Permission to use, copy, modify, and distribute this software and its > documentation for any purpose and without fee is hereby granted, is that you can DISTRIBUTE the software but you can't CHARGE A FEE. However this appears in the normal python license and many others and I am sure the correct interpretation is that you can USE, DISTRIBUTE, etc the software without PAYING A FEE (to the copyright holders.) It is free software, a XFree86 style license according to RMS, which is BSD-like but with no advertising clause. Gerard, the license is fine for distribution and as Joe said, similar to many other free software packages. -Greg Ball From pete at shinners.org Mon Oct 2 13:57:55 2000 From: pete at shinners.org (Pete Shinners) Date: Mon, 2 Oct 2000 10:57:55 -0700 Subject: [Numpy-discussion] quick optimization Message-ID: <006e01c02ca6$1ece3e40$0200a8c0@home> i've got a quick optimization for the arrayobject.c source. it speeds my usage of numpy up by about 100%. i've tested with other numpy apps and noticed a minimum of about 20% speed. anyways, in "do_sliced_copy", change out the following block: if (src_nd == 0 && dest_nd == 0) { for(j=0; j Message-ID: <39D971DD.79D2915A@lipn.univ-paris13.fr> Oups, you're right... In most (all ?) systems, memcpy() is a true function, and is *not* inlined. Jim was coding in the C++ way: trusting the optimizer ! Thank you, Emmanuel From pauldubois at home.com Mon Oct 9 15:50:30 2000 From: pauldubois at home.com (Paul F. Dubois) Date: Mon, 9 Oct 2000 12:50:30 -0700 Subject: [Numpy-discussion] [ANNOUNCE] Ninth International Python Conference Message-ID: CALL FOR PAPERS, POSTERS, AND PARTICIPATION Ninth International Python Conference March 5-8, 2001 Long Beach, California Web site: http://python9.org The 9th International Python Conference (Python 9) is a forum for Python users, software developers, and researchers to present current work, discuss future plans for the language and commercial applications, and learn about interesting uses of Python. The conference will consist of a day of tutorials, two days of refereed paper and application tracks including a Zope track and a multi-technology Python Applications Track, a developers' day, a small exhibition, demonstrations, and posters. Paper submission deadline: Monday, November 6, 2000 Notification of acceptance: Monday, December 11, 2000 Final papers due: Monday, January 15, 2001 Authors are invited to submit papers for the Refereed Paper Track that: * Present new and useful applications and tools that utilize Python * Describe the use of Python in large, mission-critical or unusual applications * Address practical programming problems, and provide lessons based on experience for Python programmers Also sought are poster presentations of interesting work in progress. Full information is available on the website, http://python9.org From pearu at ioc.ee Tue Oct 10 13:42:38 2000 From: pearu at ioc.ee (Pearu Peterson) Date: Tue, 10 Oct 2000 19:42:38 +0200 (GMT-2) Subject: [Numpy-discussion] ANNOUNCE: PySymbolic - Doing Symbolics in Python Message-ID: Hi! I have started a project PySymbolic - "Doing Symbolics in Python" PySymbolic is a collection of tools for doing elementary symbolic calculations in Python. The project is in alpha stage. Current features include basic simplifications: *** removing redundant parenthesis: (a) -> a *** applying factorization: -(a) -> -a, +a -> a, ~(a) -> ~a *** collecting terms: n*a+b+m*a -> k*a+b (where k=n+m) *** collecting powers: a**c*b/a**d -> a**(c-d)*b *** cancellations: 0*a -> 0, a+0 -> 0, a**0 -> 1, 1*a -> a, a**1 -> a *** rational arithmetic: 3/4+2/6-1 -> 1/12 *** opening parenthesis: (a+b)*c -> a*c+b*c *** expanding integer powers: (a+b)**n -> a**n+a**(n-1)*b+... *** sorting terms in alphabethic order: a+c+b -> a+b+c *** (more to come) Projects homepage is http://cens.ioc.ee/projects/pysymbolic/ You can download the source from http://cens.ioc.ee/projects/pysymbolic/PySymbolic.tgz Regards, Pearu From fred at ontosys.com Tue Oct 10 15:16:13 2000 From: fred at ontosys.com (Fred Yankowski) Date: Tue, 10 Oct 2000 14:16:13 -0500 Subject: [Numpy-discussion] version.py vs numeric_version.py Message-ID: <20001010141612.A77833@enteract.com> I couldn't seem to download a prebuilt distribution of NumPy from SourceForge earlier today, so I connected via CVS and grabbed the latest code. I was eventually able to build and install it OK, but I had to copy Lib/version.py to Lib/numeric_version.py since the latter didn't exist but other code refers to it. Just a "heads up"... -- Fred Yankowski fred at OntoSys.com tel: +1.630.879.1312 Principal Consultant www.OntoSys.com fax: +1.630.879.1370 OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA From pauldubois at home.com Wed Oct 11 08:53:42 2000 From: pauldubois at home.com (Paul F. Dubois) Date: Wed, 11 Oct 2000 05:53:42 -0700 Subject: [Numpy-discussion] Re: numpy, overflow, inf, ieee, and rich comparison Message-ID: About controlling floating-point behavior with Numpy: I think that somewhere buried in the sources Lee Busby had us all set if we would just go through the source and stick in some macro in the right places (this was maybe 3 years ago, hence the accurate and detailed memory dump) but it was on the todo list so long it outlived the death of the todo list. Anyway, my recollection is if we ever did it then we would have control when things like overflow happen. But we haven't. My last experience of this sort of thing was that it was completely a hardware-dependent thing, and you had to find out from each manufacturer what their routine was and how to call it or what compiler flag to use. Well, sorry to be so imprecise but I thought it worth mentioning that some steps had been taken even if I don't remember what they were. From busby at icf.llnl.gov Wed Oct 11 14:01:40 2000 From: busby at icf.llnl.gov (L. Busby) Date: Wed, 11 Oct 2000 11:01:40 -0700 (PDT) Subject: [Numpy-discussion] Re: numpy, overflow, inf, ieee, and rich comparison Message-ID: <200010111801.LAA02047@icf.llnl.gov> It was an optional module (fpectl) that got added into Python 1.5. Looks like it has been carried forward pretty much unchanged into the 2.0 release candidate. To use the facility, you need to build python with --with-fpectl, then identify "dangerous" (likely to generate SIGFPE) operations, and surround them with a pair of macros PyFPE_START_PROTECT and PyFPE_END_PROTECT. This has the effect of turning any SIGFPE into a Python exception. Start with Include/pyfpe.h, look for example usage in Objects/floatobject.c. Grep the python source for FPE_ to find the several places where these hooks are located. [ Paul Dubois wrote ] >About controlling floating-point behavior with Numpy: I think that somewhere >buried in the sources Lee Busby had us all set if we would just go through >the source and stick in some macro in the right places (this was maybe 3 >years ago, hence the accurate and detailed memory dump) but it was on the >todo list so long it outlived the death of the todo list. > >Anyway, my recollection is if we ever did it then we would have control when >things like overflow happen. But we haven't. My last experience of this sort >of thing was that it was completely a hardware-dependent thing, and you had >to find out from each manufacturer what their routine was and how to call it >or what compiler flag to use. > >Well, sorry to be so imprecise but I thought it worth mentioning that some >steps had been taken even if I don't remember what they were. From huaiyu_zhu at yahoo.com Wed Oct 11 19:33:08 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Wed, 11 Oct 2000 16:33:08 -0700 (PDT) Subject: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: On the issue of whether Python should ignore over/underflow on IEEE-enabled platforms: [Tim Peters] > That would stop the exception on exp() underflow, which is what you're > concerned about. It would also stop exceptions on exp() overflow, and on > underflow and overflow for all other math functions too. I doubt Guido will > ever let Python ignore overflow by default, #ifdef'ed or not. A semantic > change that jarring certainly won't happen for 2.0 (which is just a week > away). It can be argued that on IEEE enabled systems the proper thing to do for overflow is simply return Inf. Raising exception is WRONG. See below. [Guido van Rossum] > Incidentally, math.exp(800) returns inf in 1.5, and raises > OverflowError in 2.0. So at least it's consistent. That is not consistent at all. Suppose I'm plotting the curve f(x) where x include some singular points of f. In the first case the plot works with some portion of the curve clipped. In the second case it bombs. [Tim Peters] > Nothing like that will happen without a PEP first. I would like to see > *serious* 754 support myself, but that depends too on many platform experts > contributing real work (if everyone ran WinTel, I could do it myself > ). [Guido van Rossum] > Bingo! > > 1.5.2 links with -lieee while 2.0 doesn't. Removing -lieee from the > 1.5.2 link line makes is raise OverflowError too. Adding it to the > 2.0 link line makes it return 0.0 for exp(-1000) and inf for > exp(1000). If using ieee is as simple as setting such a flag, there is no reason at all not to use it. Here are some more examples: Suppose you have done hours of computation on a problem. Just as you are about to get the result, you get an exception. Why? Because the residual error is too close to zero. Suppose you want to plot the curve of Gausian distribution. Oops, it fails. Because beyond a certain region the value is near zero. With these kinds of problems, vectorized numerical calculation becomes nearly impossible. How do you work in such an environment? You have to wrap every calculation in a try/except structure, and whenever there is an exception, you have to revert to elementwise operations. In practice this simply means Python would not be suitable for numerical work at all. What about the other way round? No problem. It is easy to write functions like isNaN, isInf, etc. With these one can raise exceptions in any place one want. It is even possible to raise exceptions if a matrix is singular to a certain precision, etc. The key point to observe here is that most numerical work involve more than one element. Some of them may be out of mahcine bounds but the whole thing could still be quite meaningful. Vice versa it is also quite possible that all elements are within bounds while the whole thing is meaningless. The language should never take over or subvert decisions based on numerical analysis. [Tim Peters] > Ignoring ERANGE entirely is not at all the same behavior as 1.5.2, and > current code certainly relies on detecting overflows in math functions. As Guido observed ERANGE is not generated with ieee, even for overflow. So it is the same behavior as 1.5.2. Besides, no correct numerical code should depend on exceptions like this unless the machine is incapable of handling Inf and NaN. Even in the cases where you do want to detect overflow, it is still wrong to use exceptions. Here's an example: x*log(x) approaches 0 as x approaches 0. If x==0 then log(x)==-Inf but 0*-Inf==NaN, not what one would want. But exception is the wrong tool to hangle this, because if x is an array, some of its element may be zero but other's may not. The right way to do it is something like def entropy(probability): p = max(probability, 1e-323) return p*log(p) [Tim Peters] > In no case can you expect to see overflow ignored in 2.0. You are proposing a dramatic change from the behavior of 1.5.2. This looks like to me to need a PEP and a big debate. It would break a LOT of numerical computations. [Thomas Wouters] > I remember the patch that did this, on SF. It was titled "don't link with > -lieee if it isn't necessary" or something. Not sure what it would break, > but mayhaps declaring -lieee necessary on glibc systems is the right fix ? > > (For the non-autoconf readers among us: the first snippet writes a test > program to see if the function '__fpu_control' exists when linking with > -lieee in addition to $LIBS, and if so, adds -lieee to $LIBS. The second > snippet writes a test program to see if the function '__fpu_control' > exists with the current collection of $LIBS. If it doesn't, it tries it > again with -lieee, > > Pesonally, I think the patch should just be reversed... The comment above > the check certainly could be read as 'Linux requires -lieee for correct > f.p. operations', and perhaps that's how it was meant. The patch as described seems to be based on flawed thinking. The numbers Inf and NaN are always necessary. The -lieee could only be unnecessary if the behavior is the same as IEEE. Obviously it isn't. So I second Thomas's suggestion. [Tim Peters] > If no progress is made on determining the true cause over the next few days, > I'll hack mathmodule.c to ignore ERANGE in the specific case the result > returned is a zero (which would "fix" your exp underflow problem without > stopping overflow detection). Since this will break code on any platform > where errno was set to ERANGE on underflow in 1.5.2, I'll need to have a > long discussion w/ Guido first. I *believe* that much is actually sellable > for 2.0, because it moves Python in a direction I know he likes regardless > of whether he ever becomes a 754 True Believer. [Guido van Rossum] > No, the configure patch is right. Tim will check in a change that > treats ERANGE with a return value of 0.0 as underflow (returning 0.0, > not raising OverflowError). What is the reason to do this? It looks like intetionally subverting ieee even when it is available. I thought Tim meant that only logistical problems prevent using ieee. If you do choose this route, please please please ignore ERANGE entirely, whether return value is zero or not. The only possible way that ERANGE could be useful at all is if it could be set independently for each element of an array, and if it behave as a warning instead of an exception, ie. the calculation would continue if it is not caught. Well, then, Inf and NaN serve this purpose perfectly. It is very reasonable to set errno in glibc for this; it is completely unreasonable to raise an exception in Python, because exceptions cannot be set to individual elements and they cannot be ignored. Huaiyu -- Huaiyu Zhu hzhu at users.sourceforge.net Matrix for Python Project http://MatPy.sourceforge.net From pauldubois at home.com Wed Oct 11 20:04:51 2000 From: pauldubois at home.com (Paul F. Dubois) Date: Wed, 11 Oct 2000 17:04:51 -0700 Subject: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: I don't have time to follow in detail this thread about changed behavior between versions. These observations are based on working with hundreds of code authors. I offer them as is. a. Nobody runs a serious numeric calculation without setting underflow-to-zero, in the hardware. You can't even afford the cost of software checks. Unfortunately there is no portable way to do that that I know of. b. Some people use Inf but most people want the code to STOP so they can find out where the INFS started. Otherwise, two hours later you have big arrays of Infs and no idea how it happened. Likewise sqrt(-1.) needs to stop, not put a zero and keep going. From guido at python.org Wed Oct 11 21:45:30 2000 From: guido at python.org (Guido van Rossum) Date: Wed, 11 Oct 2000 20:45:30 -0500 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Your message of "Wed, 11 Oct 2000 17:04:51 MST." References: Message-ID: <200010120145.UAA02030@cj20424-a.reston1.va.home.com> > I don't have time to follow in detail this thread about changed behavior > between versions. These observations are based on working with hundreds of > code authors. I offer them as is. > > a. Nobody runs a serious numeric calculation without setting > underflow-to-zero, in the hardware. You can't even afford the cost of > software checks. Unfortunately there is no portable way to do that that I > know of. > > b. Some people use Inf but most people want the code to STOP so they can > find out where the INFS started. Otherwise, two hours later you have big > arrays of Infs and no idea how it happened. Likewise sqrt(-1.) needs to > stop, not put a zero and keep going. Thanks, Paul! This behavior has always been what I wanted Python to do (even though it's not always what Python did, depending on the platform) and also what Tim's proposed patch will implement for the specific case of math.exp() (and other math functions that may underflow or overflow), on most reasonable platforms. There are still lots of places where the platform gives Python no choice of creating NaN and Inf, and because there's no platform-independent way to test for these, they are hard to avoid in some cases; but eventually, Tim will find a way to root them out. And for people like Huaiyu, who want to see Inf, there will (eventually) be a way to select this as a run-time option; and ditto for whoever might want underflow to raise an exception. --Guido van Rossum (home page: http://www.python.org/~guido/) From huaiyu_zhu at yahoo.com Wed Oct 11 22:22:54 2000 From: huaiyu_zhu at yahoo.com (Huaiyu Zhu) Date: Wed, 11 Oct 2000 19:22:54 -0700 (PDT) Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <200010120145.UAA02030@cj20424-a.reston1.va.home.com> Message-ID: [Paul Dubois] > > > > a. Nobody runs a serious numeric calculation without setting > > underflow-to-zero, in the hardware. You can't even afford the cost of > > software checks. Unfortunately there is no portable way to do that that I > > know of. Amen. > > > > b. Some people use Inf but most people want the code to STOP so they can > > find out where the INFS started. Otherwise, two hours later you have big > > arrays of Infs and no idea how it happened. Likewise sqrt(-1.) needs to > > stop, not put a zero and keep going. $ /usr/bin/python Python 1.5.2 (#1, Sep 17 1999, 20:15:36) [GCC egcs-2.91.66 19990314/Linux (egcs- on linux-i386 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> from math import * >>> exp(777) inf >>> exp(-777) 0.0 >>> sqrt(-1) Traceback (innermost last): File "", line 1, in ? OverflowError: math range error This was sane behavior. Are we saying that Python 2.0 has invented something better than IEEE 754? [Guido van Rossum] > Thanks, Paul! This behavior has always been what I wanted Python to > do (even though it's not always what Python did, depending on the > platform) and also what Tim's proposed patch will implement for the > specific case of math.exp() (and other math functions that may > underflow or overflow), on most reasonable platforms. Guido, with due respect to your decisions on Python issues, I simply have to fight this one. It is one thing to accomodate for naive users, but it is another to dumb down every one else. Case 1. Someone writes a flawed numerical routine. Two hours later he finds his array filled with Inf and NaN. Case 2. Someone writes a perfect numerical routine. Two hours later he gets an exception, because the error is near zero. Solution for case 1. Use better algorithm. Use better error control. Raise exceptions when error is too large. These are proper solutions. They are easy and efficient to implement. They are needed anyway - If something's wrong, you want to raise exceptions far earlier than Inf, certainly before you get arrays filled with elements like 1e300. Solution for case 2. Almost impossible. The division between under- and over-flow is artificial. What about 1/x or similar functions? The only way to work on such a platform is to abandon vectorized computation. > There are still lots of places where the platform gives Python no > choice of creating NaN and Inf, and because there's no > platform-independent way to test for these, they are hard to avoid in > some cases; but eventually, Tim will find a way to root them out. And > for people like Huaiyu, who want to see Inf, there will (eventually) > be a way to select this as a run-time option; and ditto for whoever > might want underflow to raise an exception. I can understand that exceptions are the only available choices if IEEE is not available. But is there a compelling reason that Python should behave "better" than IEEE when it's in fact available? If the reason is to protect naive users, I can think of several responses: 1. For people doing one-off interactive work, returning Inf is in fact more informative. 2. For users iterative numerical computations, they need to be educated about error control. Otherwise they won't get corrent results anyway. 3. For really serious work, we could provide good numerical modules so that they don't need to write themselves. To make this happen fast the fewer debacles like this one the better. Case in point: Someone asked for regession modules two weeks ago. I was trying to convert my old matlab programs, which only took a few hours. But I wasted a week of (spare) time fighting for some mysterious "overflow". Turns out that a Guassian is near zero when it's far from center, and Python does not like it. In practice, Inf may be generated more often as a proper value than by mistake. This is not an issue about whether someone "prefers" Inf or exception. It is about whether there is a choice to do proper computation. Returning Inf does not prevent someone to raise exception. Raising exception automatically prevents perfect algorithms to work properly. As Kevin has volunteered to help with IEEE implementation and made a plan, is there a strong reason to drop IEEE for Linux in 2.0? If there is insufficient time to carry out his plan, wouldn't it be prudent to keep things as they were in 1.5.2? Huaiyu From tim_one at email.msn.com Wed Oct 11 22:44:20 2000 From: tim_one at email.msn.com (Tim Peters) Date: Wed, 11 Oct 2000 22:44:20 -0400 Subject: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: [Huaiyu Zhu] > On the issue of whether Python should ignore over/underflow on > IEEE-enabled platforms: > > It can be argued that on IEEE enabled systems the proper thing to do for > overflow is simply return Inf. Raising exception is WRONG. See below. Python was not designed with IEEE-754 in mind, and *anything* that happens wrt Infs, NaNs, and all other 754 features in Python is purely an accident that can and does vary wildly across platforms. And, as you've discovered in this case, can vary wildly also across even a single library, depending on config options. We cannot consider this to be a bug since Python has had no *intended* behavior whatsoever wrt 754 gimmicks. We can and do consider gripes about these accidents to be feature requests. [Guido] > Incidentally, math.exp(800) returns inf in 1.5, and raises > OverflowError in 2.0. So at least it's consistent. [Huaiyu] > That is not consistent at all. Please read with an assumption of good faith. Guido was pointing out that-- all in the specific case of gcc+glibc on Linux (these don't hold on other platforms) --exp(800) returning Inf in 1.5 and OverflowError in 2.0 is consistent *with* that exp(-800) returns 0 in 1.5 and raises an exception in 2.0. He's right; indeed, he is in part agreeing with you. [Guido > 1.5.2 links with -lieee while 2.0 doesn't. Removing -lieee from the > 1.5.2 link line makes is raise OverflowError too. Adding it to the > 2.0 link line makes it return 0.0 for exp(-1000) and inf for > exp(1000). [Huaiyu] > If using ieee is as simple as setting such a flag, there is no > reason at all not to use it. The patch to stop setting -lieee was contributed by a Python user who claimed it fixed bugs on *their* platform. That's "the reason". We don't want to screw them either. > Here are some more examples: > ... I understand that 754 semantics can be invaluable. So does Guido. There's no argument about that. But Python doesn't yet support them, and wishing it did doesn't make it so. If linking with -lieee happens to give you the semantics you want on your platform today, you're welcome to build with that switch. It appears to be a bad choice for *most* Python users, though (more below), so we don't want to do it in the std 2.0 distro. > ... > In practice this simply means Python would not be suitable for numerical > work at all. Your biggest obstacle in getting Python support for 754 will in fact be opposition from number-crunchers. I've been slinging fp for 21 years, 15 of those writing compilers and math libraries for "supercomputer" vendors. 754 is a Very Good Thing, but is Evil in subset form (see Kahan's (justified!) vilification of Java on this point); ironically, 754 is hardest to sell to those who could benefit from it the most. > What about the other way round? No problem. It is easy to write > functions like isNaN, isInf, etc. It's easy for a platform expert to write such functions for their specific platform of expertise, but it's impossible to write them in a portable way before C99 is implemented (C99 requires that library suppliers provide them, rendering the question moot). > ... > The language should never take over or subvert decisions based on > numerical analysis. Which is why a subset of 754 is evil. 754 requires that the user be able to *choose* whether or not, e.g., overflow signals an exception. Your crusade to insist that it never raise an exception is as least as bad (I think it's much worse) as Python's most common accidental behavior (where overflow from libm usually raises an exception). One size does not fit all. [Tim] > Ignoring ERANGE entirely is not at all the same behavior as 1.5.2, and > current code certainly relies on detecting overflows in math functions. [Huaiyu] > As Guido observed ERANGE is not generated with ieee, even for > overflow. So it is the same behavior as 1.5.2. You've got a bit of a case of tunnel vision here, Huaiyu. Yes, in the specific case of gcc+glibc+Linux, ignoring ERANGE returned from exp() is what 1.5.2 acted like. But you have not proposed to ignore it merely from ERANGE returned from exp() in the specific case of gcc+glibc+Linux. This code runs on many dozens of platforms, and, e.g., as I suggested before, it looks like HPUX has always set errno on both overflow and underflow. MS Windows sets it on overflow but not underflow. Etc. We have to worry about the effects on all platforms. > Besides, no correct numerical code should depend on exceptions like > this unless the machine is incapable of handling Inf and NaN. Nonsense. 754 provides the option to raise an exception on overflow, or not, at the user's discretion, precisely because exceptions are sometimes more appropriate than Infs of NaNs. Kahan himself isn't happy with Infs and NaNs because they're too often too gross a clue (see his writings on "presubstitution" for a more useful approach). [Tim] > In no case can you expect to see overflow ignored in 2.0. [Huaiyu] > You are proposing a dramatic change from the behavior of 1.5.2. > This looks like to me to need a PEP and a big debate. It would break > a LOT of numerical computations. I personally doubt that, but realize it may be true. That's why he have beta releases. So far yours is the only feedback we've heard (thanks!), and as a result we're going to change 2.0 to stop griping about underflow, and do so in a way that will actually work across all platforms. We're probably going to break some HPUX programs as a result; but they were relying on accidents too. [Guido] > No, the configure patch is right. Tim will check in a change that > treats ERANGE with a return value of 0.0 as underflow (returning 0.0, > not raising OverflowError). [Huaiyu] > What is the reason to do this? It looks like intetionally subverting > ieee even when it is available. I thought Tim meant that only logistical > problems prevent using ieee. Python does not support 754 today. Period. I would like it to, but not in any half-assed, still platform-dependent, still random crap-shoot, still random subset of 754 features, still rigidly inflexible, way. When it does support it, Guido & I will argue that it should enable (what 754 calls) the overflow, divide-by-0 and invalid operation exceptions by default, and disable the underflow and inexact exceptions by default. This ensures that, under the default, an infinity or NaN can never be created from non-exceptional inputs without triggering an exception. Not only is that best for newbies, you'll find it's the *only* scheme for a default that can be sold to working number-crunchers (been there, done that, at Kendall Square Research). It also matches Guido's original, pre-754, *intent* for how Python numerics should work by default (it is, e.g., no accident that Python has always had an OverflowError exception but never an UnderflowError one). And that corresponds to the change Guido says I'm going to make in mathmodule.c: suppress complaints about underflow, but let complaints about overflow go through. This is not a solution, it's a step on a path towards a solution. The next step (which will not happen for 2.0!) is to provide an explicit way to, from Python, disable overflow checking, and that's simply part of providing the control and inquiry functions mandated by 754. Then code that would rather deal with Infs than exceptions can, at its explicit discretion. > If you do choose this route, please please please ignore ERANGE entirely, > whether return value is zero or not. It should be clear that isn't going to happen. I realize that triggering overflow is going to piss you off, but you have to realize that not triggering overflow is going to piss more people off, and *especially* your fellow number-crunchers. Short of serious 754 support, picking "a winner" is the best we can do for now. You have the -lieee flag on your platform du jour if you can't bear it. [Paul Dubois] > I don't have time to follow in detail this thread about changed behavior > between versions. What makes you think we do <0.5 wink>? > These observations are based on working with hundreds of code authors. I > offer them as is. FWIW, they exactly match my observations from 15 years on the HW vendor side. > a. Nobody runs a serious numeric calculation without setting underflow-to- > zero, in the hardware. You can't even afford the cost of software checks. > Unfortunately there is no portable way to do that that I know of. C allows libm implementations a lot of discretion in whether to set errno to ERANGE in case of underflow. The change we're going to make is to ignore ERANGE in case of underflow, ensuring that math.* functions will *stop* raising underflow exceptions on all platforms (they'll return a zero instead; whether +0 or -0 will remain a platform-dependent crap shoot for now). Nothing here addresses underflow exceptions that may be raised by fp hardware, though; this has solely to do with the platform libm's treatment of errno. So in this respect, we're removing Python's current unpredictability, and in the way you favor. > b. Some people use Inf but most people want the code to STOP so they can > find out where the INFS started. Otherwise, two hours later you have big > arrays of Infs and no idea how it happened. Apparently Python on libc+glibc+Linux never raised OverflowError from math.* functions in 1.5.2 (although it did on most other platforms I know about). A patch checked in to fix some other complaint on some other Unixish platform had the side-effect of making Python on libc+glibc+Linux start raising OverflowError from math.* functions in 2.0, but in both overflow and underflow cases. We intend to (as above) suppress the underflow exceptions, but let the overflow cases continue to raise OverflowError. Huaiyu's original complaint was about the underflow cases, but (as such things often do) expanded beyond that when it became clear he would get what he asked for . Again we're removing Python's current unpredictability, and again in the way you favor -- although this one is still at the mercy of whether the platform libm sets errno correctly on overflow (but it seems that most do these days). > Likewise sqrt(-1.) needs to stop, not put a zero and keep going. Nobody has proposed changing anything about libm domain (as opposed to range) errors (although Huaiyu probably should if he's serious about his flavor of 754 subsetism -- I have no idea what gcc+glibc+Linux did here on 1.5.2, but it *should* have silently returned a NaN (not a zero) without setting errno if it was *self*-consistent -- anyone care to check that under -lieee?: import math math.sqrt(-1) NaN or ValueError? 2.0 should raise ValueError regardless of what 1.5.2 did here.). just-another-day-of-universal-python-harmony-ly y'rs - tim From sdm7g at virginia.edu Wed Oct 11 23:23:32 2000 From: sdm7g at virginia.edu (Steven D. Majewski) Date: Wed, 11 Oct 2000 23:23:32 -0400 (EDT) Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: First: I haven't followed this thread from the beginning -- only the last ten or so posts. Second: One reason I didn't follow it from the start is that I'm not doing any heavy numerical stuff in Python. I've been using Lisp for that, and use Python more for string/symbolic or GUI hacking. But, if I was going to do the sort of numerical stuff I now do in Lisp in Python, I would agree with Huaiya Zhu. I do a lot of vectorized operations on what are often independent samples. If some of the numbers overflow or underflow, that just represents an outlier or bad sample. I don't want it to blow off the whole pipeline of operations on the other data points in the vector -- they are independent of the bad points. In my case, it's not that these are lengthy calculations. It's that they are interactive and tied to immediate graphical representations. If there are strange zero's or infinities in the result, there is (or should be) a way to backtrack and investigate. ( That's why people want interactive and graphical regression analysis and modeling tools! ) The idea that your calculation should blow up and you should check it and resubmit your job sounds just so ancient-20th-century- Fortran-JCL-and-punched-cards-technology! ---| Steven D. Majewski (804-982-0831) |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| University of Virginia Health Sciences Center |--- ---| P.O. Box 10011 Charlottesville, VA 22906-0011 |--- "All operating systems want to be unix, All programming languages want to be lisp." From tim_one at email.msn.com Thu Oct 12 02:16:23 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 12 Oct 2000 02:16:23 -0400 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: [Huaiyu Zhu] > ... > $ /usr/bin/python > Python 1.5.2 (#1, Sep 17 1999, 20:15:36) [GCC egcs-2.91.66 19990314/Linux > (egcs- on linux-i386 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> from math import * > >>> exp(777) > inf > >>> exp(-777) > 0.0 > >>> sqrt(-1) > Traceback (innermost last): > File "", line 1, in ? > OverflowError: math range error > > This was sane behavior. Are we saying that Python 2.0 has invented > something better than IEEE 754? 754 allows users to choose the behaviors they want. Any *fixed* policy is not 754. So long as we have to fix a single policy, yes, I believe Guido (& know I) would say that raising OverflowError on exp(777), and silently returning 0 on exp(-777), and raising ValueError on sqrt(-1) (*not* OverflowError, as shown above), is indeed better than the 754 default behaviors. And 2.0 will do all three of those (& I just checked in the code to make that happen). About the sqrt example above, that's neither 754 behavior nor sane behavior: default 754 behavior on sqrt(-1) is to return a NaN and keep on going. I'm pretty sure that's what glibc linked w/ -lieee actually does, too (if it doesn't, glibc -lieee is violating 754). That 1.5.2 raised an OverflowError instead is insane, and appears purely due to an accident of how gcc compiles code to compare Infs to NaNs (Python's mathmodule.c's CHECK() macro was fooled by this into setting errno to ERANGE itself). Python should raise a ValueError there instead (corresponding to libm setting errno to EDOM -- this is a domain error, not a range error) -- which it does now under CVS Python. 754-doesn't-work-unless-you've-got-all-of-it-ly y'rs - tim From jhauser at ifm.uni-kiel.de Thu Oct 12 03:37:08 2000 From: jhauser at ifm.uni-kiel.de (Janko Hauser) Date: Thu, 12 Oct 2000 09:37:08 +0200 (CEST) Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: References: Message-ID: <20001012073708.15731.qmail@lisboa.ifm.uni-kiel.de> To look for another way out of this, the current problem are the two different wishes for vectorized computations to have NaN/Inf or Exceptions. As the actual computations for NumPy are all done in C, isn't it possible to implement a special signal handling in the NumPy code? As an option, for the people who know that they are then possibly in trouble (different behavior for arrays than for Python scalars) __Janko Just for the record. Python 1.5.2 (#1, May 10 1999, 18:46:39) [GCC egcs-2.91.60 Debian 2.1 (egcs-1.1. on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam (IPP) Type ? for more help >>> import math >>> math.sqrt(-1) Traceback (innermost last): File "", line 1, in ? OverflowError: math range error >>> math.exp(-800) 0.0 >>> math.exp(800) inf >>> >>> import Numeric >>> Numeric.exp(Numeric.array([800, -800.])) array([ inf, 0.00000000e+000]) >>> Numeric.sqrt(Numeric.array([-1])) array([ nan]) >>> # So the current behavior is already inconsistent on at least one >>> # platform # Other platform (DEC Alpha) raising domain error Python 1.5.2 (#6, Sep 20 1999, 17:44:09) [C] on osf1V4 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import math >>> math.exp(-800) Traceback (innermost last): File "", line 1, in ? OverflowError: math range error >>> math.exp(800) Traceback (innermost last): File "", line 1, in ? OverflowError: math range error >>> math.sqrt(-1) Traceback (innermost last): File "", line 1, in ? ValueError: math domain error >>> import Numeric >>> Numeric.exp(Numeric.array([800, -800.])) Traceback (innermost last): File "", line 1, in ? OverflowError: math range error >>> Numeric.sqrt(Numeric.array([-1])) Traceback (innermost last): File "", line 1, in ? ValueError: math domain error From thomas at xs4all.net Thu Oct 12 04:11:57 2000 From: thomas at xs4all.net (Thomas Wouters) Date: Thu, 12 Oct 2000 10:11:57 +0200 Subject: [Numpy-discussion] Re: [Python-Dev] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: ; from tim_one@email.msn.com on Wed, Oct 11, 2000 at 10:44:20PM -0400 References: Message-ID: <20001012101157.Y12812@xs4all.nl> On Wed, Oct 11, 2000 at 10:44:20PM -0400, Tim Peters wrote: > > Likewise sqrt(-1.) needs to stop, not put a zero and keep going. > Nobody has proposed changing anything about libm domain (as opposed to > range) errors (although Huaiyu probably should if he's serious about his > flavor of 754 subsetism -- I have no idea what gcc+glibc+Linux did here on > 1.5.2, but it *should* have silently returned a NaN (not a zero) without > setting errno if it was *self*-consistent -- anyone care to check that > under -lieee?: > import math > math.sqrt(-1) >>> import math >>> math.sqrt(-1) Traceback (most recent call last): File "", line 1, in ? OverflowError: math range error The same under both 1.5.2 and 2.0c1 with -lieee. Without -lieee, both do: >>> import math >>> math.sqrt(-1) Traceback (innermost last): File "", line 1, in ? ValueError: math domain error Consistency-conschmistency-ly y'rs, -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From Aureli.Soria_Frisch at ipk.fhg.de Thu Oct 12 08:22:14 2000 From: Aureli.Soria_Frisch at ipk.fhg.de (Aureli Soria Frisch) Date: Thu, 12 Oct 2000 14:22:14 +0200 Subject: [Numpy-discussion] Possible bug in LinearAlgebra module Message-ID: Hi, I have been working with the function (implmenting the Moore-Penrose generalized inverse) : generalized_inverse of the module LinearAlgebra. It seems to present a bug when operating on matrices of complex numbers. I want someone to confirm this point before submitting the source. Thanks in advance, Aureli ################################# Aureli Soria Frisch Fraunhofer IPK Dept. Pattern Recognition post: Pascalstr. 8-9, 10587 Berlin, Germany e-mail:aureli at ipk.fhg.de fon: +49 30 39 00 61 50 fax: +49 30 39 17 517 ################################# From gpk at bell-labs.com Thu Oct 12 11:01:19 2000 From: gpk at bell-labs.com (Greg Kochanski) Date: Thu, 12 Oct 2000 11:01:19 -0400 Subject: [Numpy-discussion] Re: Numpy-discussion digest, Vol 1 #112 - 8 msgs References: <200010120325.e9C3P1H01217@lists.sourceforge.net> Message-ID: <39E5D23F.2B647F6D@bell-labs.com> Python has *got* to ignore underflow exceptions. Otherwise, virtually any numeric calculation that subtracts numbers will fail for no good reason. Worse, it will fail in a very sporadic, data-dependent manner. With double precision numbers, the failures will be rare, but anyone doing computations with floats will see unwanted exceptions with noticeable frequency. I once did a numeric calculation (a SVD classifier) on a system with IEEE-754 underflow exceptions turned on, and I lost a good square inch of hair and a solid week of life because of it. At one point, the numbers were converted from doubles to floats, and about 1 in every 10,000,000 of the numbers were too small to represent as a float. So, in about 1 in ten runs (an hour each), the code would crash for no obvious reason. It was a debugging nightmare. If python catches underflows, I'm going back to FORTRAN. On less crucial topics, I'm strongly in favor of preserving NaN and Inf. If I want my code to crash when some computation goes awry, I'll use assert, and crash it myself. Any serious numeric code should be loaded with assertions (any code at all, in fact). Asking the interpreter to do it for you is a crude and blunt instrument. If I may ask, what kind of platforms are there where people do math where the hardware *won't* support IEEE-754? From pauldubois at home.com Thu Oct 12 11:17:53 2000 From: pauldubois at home.com (Paul F. Dubois) Date: Thu, 12 Oct 2000 08:17:53 -0700 Subject: [Numpy-discussion] Re: Numpy-discussion digest, Vol 1 #112 - 8 msgs In-Reply-To: <39E5D23F.2B647F6D@bell-labs.com> Message-ID: If I may ask, what kind of platforms are there where people do math where the hardware *won't* support IEEE-754? _______________________________________________ The problem isn't that the hardware doesn't support it, although there used to be some important machines that didn't. (Burton Smith once told me that adding this to a supercomputer architecture slows down the cycle time by a very considerable amount, he guessed at least 20% if I recall correctly.) The problem is that access to control the hardware has no standard. Usually you have to get out the Fortran manual and look in the back if you're lucky. I've had computers where I couldn't find this information at all. Probably things have improved in the last few years but this situation is still not great. Worse, it needs to be a runtime control, not a compile option. As everyone who has tried it found out, actually using the Infs and NaN's in any portable way is pretty difficult. I prefer algorithmic vigor to prevent their appearance. While my opinion is a minority one, I wish the "standard" had never been born and I had my cycles back. It isn't really a standard, is it? From nick at nickbower.com Thu Oct 12 11:30:22 2000 From: nick at nickbower.com (Nick Bower) Date: Thu, 12 Oct 2000 15:30:22 GMT Subject: [Numpy-discussion] Re: Numpy-discussion digest, Vol 1 #112 - 8 msgs In-Reply-To: <39E5D23F.2B647F6D@bell-labs.com> References: <200010120325.e9C3P1H01217@lists.sourceforge.net> <39E5D23F.2B647F6D@bell-labs.com> Message-ID: <20001012.15302200@cricket.> > So, in about 1 in ten runs (an hour each), the code > would crash for no obvious reason. It was a debugging > nightmare. If python catches underflows, I'm going > back to FORTRAN. hear hear. or is that here here ;) but it is a scarey concept isn't it? i've pieced together an interactive python visualization environment (a clone of RSI's IDL in fact - nickbower.com/computer/pydl) and although i didn't write the plot engine, surely there's no way to "make the algorithm better" if you have no idea if the user will try to graph asymptotic curves for example. it's just not realistic to expect the compiler to bomb out and force the user to tweak the calculation limits. > On less crucial topics, I'm strongly in favor of > preserving NaN and Inf. If I want my code to crash > when some computation goes awry, I'll use assert, > and crash it myself. i'm in favour of this too. i think favouring people who don't want to come back after hours of code execution to find Nan and Inf arrays may shaft a great deal of people (be it a minority or not). nick From hinsen at dirac.cnrs-orleans.fr Thu Oct 12 13:24:18 2000 From: hinsen at dirac.cnrs-orleans.fr (hinsen at dirac.cnrs-orleans.fr) Date: Thu, 12 Oct 2000 19:24:18 +0200 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: (sdm7g@virginia.edu) References: Message-ID: <200010121724.TAA15487@chinon.cnrs-orleans.fr> > The idea that your calculation should blow up and you should > check it and resubmit your job sounds just so ancient-20th-century- > Fortran-JCL-and-punched-cards-technology! Long-running jobs are still with us, even there's neither Fortran nor JCL in them. And for these applications, stopping is better than going on with nonsense values. On the other hand, as you point out, exceptions for math errors are a bit of a pain for interactive work. So how about making this a run-time option? I'd choose exceptions by default and Infs and Nans by specifying a command-line option, but there are certainly others who would prefer it the other way round. What matters most to me is that the choice is possible somehow. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen at cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From hinsen at cnrs-orleans.fr Thu Oct 12 13:26:29 2000 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Thu, 12 Oct 2000 19:26:29 +0200 Subject: [Numpy-discussion] Possible bug in LinearAlgebra module In-Reply-To: (message from Aureli Soria Frisch on Thu, 12 Oct 2000 14:22:14 +0200) References: Message-ID: <200010121726.TAA15490@chinon.cnrs-orleans.fr> > I have been working with the function (implmenting the Moore-Penrose > generalized inverse) : > > generalized_inverse > > of the module LinearAlgebra. It seems to present a bug when operating on > matrices of complex numbers. That is well possible. I use this function a lot but always on real matrices. I am not sure I even tested it on complex matrices when I wrote it ages ago. If you have a fix, it is certainly appreciated. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen at cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From Robert.Harrison at pnl.gov Thu Oct 12 13:37:20 2000 From: Robert.Harrison at pnl.gov (Harrison, Robert J) Date: Thu, 12 Oct 2000 10:37:20 -0700 Subject: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) Message-ID: I watch but rarely contribute to these dicussions, but I feel compelled to whole heartedly support Tim Peters comments regarding full 754 support with consistent cross platform behaviour. Like Tim I've being doing numerical computing for over two decades and IEEE is an indispensible standard. Yes, we usually disable most exception handling within performance critical kernels, but within robust solvers or modern linear algebra packages, full IEEE exception handling is vital. As Tim has said, full 754 will satisfy all users to the maximum extent possible. Robert -----Original Message----- From: Tim Peters [mailto:tim_one at email.msn.com] Sent: Wednesday, October 11, 2000 7:44 PM To: Huaiyu Zhu Cc: python-list at python.org; PythonDev; Numpy-Discussion; dubois at users.sourceforge.net Subject: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) [Huaiyu Zhu] > On the issue of whether Python should ignore over/underflow on > IEEE-enabled platforms: > > It can be argued that on IEEE enabled systems the proper thing to do for > overflow is simply return Inf. Raising exception is WRONG. See below. Python was not designed with IEEE-754 in mind, and *anything* that happens wrt Infs, NaNs, and all other 754 features in Python is purely an accident that can and does vary wildly across platforms. And, as you've discovered in this case, can vary wildly also across even a single library, depending on config options. We cannot consider this to be a bug since Python has had no *intended* behavior whatsoever wrt 754 gimmicks. We can and do consider gripes about these accidents to be feature requests. [Guido] > Incidentally, math.exp(800) returns inf in 1.5, and raises > OverflowError in 2.0. So at least it's consistent. [Huaiyu] > That is not consistent at all. Please read with an assumption of good faith. Guido was pointing out that-- all in the specific case of gcc+glibc on Linux (these don't hold on other platforms) --exp(800) returning Inf in 1.5 and OverflowError in 2.0 is consistent *with* that exp(-800) returns 0 in 1.5 and raises an exception in 2.0. He's right; indeed, he is in part agreeing with you. [Guido > 1.5.2 links with -lieee while 2.0 doesn't. Removing -lieee from the > 1.5.2 link line makes is raise OverflowError too. Adding it to the > 2.0 link line makes it return 0.0 for exp(-1000) and inf for > exp(1000). [Huaiyu] > If using ieee is as simple as setting such a flag, there is no > reason at all not to use it. The patch to stop setting -lieee was contributed by a Python user who claimed it fixed bugs on *their* platform. That's "the reason". We don't want to screw them either. > Here are some more examples: > ... I understand that 754 semantics can be invaluable. So does Guido. There's no argument about that. But Python doesn't yet support them, and wishing it did doesn't make it so. If linking with -lieee happens to give you the semantics you want on your platform today, you're welcome to build with that switch. It appears to be a bad choice for *most* Python users, though (more below), so we don't want to do it in the std 2.0 distro. > ... > In practice this simply means Python would not be suitable for numerical > work at all. Your biggest obstacle in getting Python support for 754 will in fact be opposition from number-crunchers. I've been slinging fp for 21 years, 15 of those writing compilers and math libraries for "supercomputer" vendors. 754 is a Very Good Thing, but is Evil in subset form (see Kahan's (justified!) vilification of Java on this point); ironically, 754 is hardest to sell to those who could benefit from it the most. > What about the other way round? No problem. It is easy to write > functions like isNaN, isInf, etc. It's easy for a platform expert to write such functions for their specific platform of expertise, but it's impossible to write them in a portable way before C99 is implemented (C99 requires that library suppliers provide them, rendering the question moot). > ... > The language should never take over or subvert decisions based on > numerical analysis. Which is why a subset of 754 is evil. 754 requires that the user be able to *choose* whether or not, e.g., overflow signals an exception. Your crusade to insist that it never raise an exception is as least as bad (I think it's much worse) as Python's most common accidental behavior (where overflow from libm usually raises an exception). One size does not fit all. [Tim] > Ignoring ERANGE entirely is not at all the same behavior as 1.5.2, and > current code certainly relies on detecting overflows in math functions. [Huaiyu] > As Guido observed ERANGE is not generated with ieee, even for > overflow. So it is the same behavior as 1.5.2. You've got a bit of a case of tunnel vision here, Huaiyu. Yes, in the specific case of gcc+glibc+Linux, ignoring ERANGE returned from exp() is what 1.5.2 acted like. But you have not proposed to ignore it merely from ERANGE returned from exp() in the specific case of gcc+glibc+Linux. This code runs on many dozens of platforms, and, e.g., as I suggested before, it looks like HPUX has always set errno on both overflow and underflow. MS Windows sets it on overflow but not underflow. Etc. We have to worry about the effects on all platforms. > Besides, no correct numerical code should depend on exceptions like > this unless the machine is incapable of handling Inf and NaN. Nonsense. 754 provides the option to raise an exception on overflow, or not, at the user's discretion, precisely because exceptions are sometimes more appropriate than Infs of NaNs. Kahan himself isn't happy with Infs and NaNs because they're too often too gross a clue (see his writings on "presubstitution" for a more useful approach). [Tim] > In no case can you expect to see overflow ignored in 2.0. [Huaiyu] > You are proposing a dramatic change from the behavior of 1.5.2. > This looks like to me to need a PEP and a big debate. It would break > a LOT of numerical computations. I personally doubt that, but realize it may be true. That's why he have beta releases. So far yours is the only feedback we've heard (thanks!), and as a result we're going to change 2.0 to stop griping about underflow, and do so in a way that will actually work across all platforms. We're probably going to break some HPUX programs as a result; but they were relying on accidents too. [Guido] > No, the configure patch is right. Tim will check in a change that > treats ERANGE with a return value of 0.0 as underflow (returning 0.0, > not raising OverflowError). [Huaiyu] > What is the reason to do this? It looks like intetionally subverting > ieee even when it is available. I thought Tim meant that only logistical > problems prevent using ieee. Python does not support 754 today. Period. I would like it to, but not in any half-assed, still platform-dependent, still random crap-shoot, still random subset of 754 features, still rigidly inflexible, way. When it does support it, Guido & I will argue that it should enable (what 754 calls) the overflow, divide-by-0 and invalid operation exceptions by default, and disable the underflow and inexact exceptions by default. This ensures that, under the default, an infinity or NaN can never be created from non-exceptional inputs without triggering an exception. Not only is that best for newbies, you'll find it's the *only* scheme for a default that can be sold to working number-crunchers (been there, done that, at Kendall Square Research). It also matches Guido's original, pre-754, *intent* for how Python numerics should work by default (it is, e.g., no accident that Python has always had an OverflowError exception but never an UnderflowError one). And that corresponds to the change Guido says I'm going to make in mathmodule.c: suppress complaints about underflow, but let complaints about overflow go through. This is not a solution, it's a step on a path towards a solution. The next step (which will not happen for 2.0!) is to provide an explicit way to, from Python, disable overflow checking, and that's simply part of providing the control and inquiry functions mandated by 754. Then code that would rather deal with Infs than exceptions can, at its explicit discretion. > If you do choose this route, please please please ignore ERANGE entirely, > whether return value is zero or not. It should be clear that isn't going to happen. I realize that triggering overflow is going to piss you off, but you have to realize that not triggering overflow is going to piss more people off, and *especially* your fellow number-crunchers. Short of serious 754 support, picking "a winner" is the best we can do for now. You have the -lieee flag on your platform du jour if you can't bear it. [Paul Dubois] > I don't have time to follow in detail this thread about changed behavior > between versions. What makes you think we do <0.5 wink>? > These observations are based on working with hundreds of code authors. I > offer them as is. FWIW, they exactly match my observations from 15 years on the HW vendor side. > a. Nobody runs a serious numeric calculation without setting underflow-to- > zero, in the hardware. You can't even afford the cost of software checks. > Unfortunately there is no portable way to do that that I know of. C allows libm implementations a lot of discretion in whether to set errno to ERANGE in case of underflow. The change we're going to make is to ignore ERANGE in case of underflow, ensuring that math.* functions will *stop* raising underflow exceptions on all platforms (they'll return a zero instead; whether +0 or -0 will remain a platform-dependent crap shoot for now). Nothing here addresses underflow exceptions that may be raised by fp hardware, though; this has solely to do with the platform libm's treatment of errno. So in this respect, we're removing Python's current unpredictability, and in the way you favor. > b. Some people use Inf but most people want the code to STOP so they can > find out where the INFS started. Otherwise, two hours later you have big > arrays of Infs and no idea how it happened. Apparently Python on libc+glibc+Linux never raised OverflowError from math.* functions in 1.5.2 (although it did on most other platforms I know about). A patch checked in to fix some other complaint on some other Unixish platform had the side-effect of making Python on libc+glibc+Linux start raising OverflowError from math.* functions in 2.0, but in both overflow and underflow cases. We intend to (as above) suppress the underflow exceptions, but let the overflow cases continue to raise OverflowError. Huaiyu's original complaint was about the underflow cases, but (as such things often do) expanded beyond that when it became clear he would get what he asked for . Again we're removing Python's current unpredictability, and again in the way you favor -- although this one is still at the mercy of whether the platform libm sets errno correctly on overflow (but it seems that most do these days). > Likewise sqrt(-1.) needs to stop, not put a zero and keep going. Nobody has proposed changing anything about libm domain (as opposed to range) errors (although Huaiyu probably should if he's serious about his flavor of 754 subsetism -- I have no idea what gcc+glibc+Linux did here on 1.5.2, but it *should* have silently returned a NaN (not a zero) without setting errno if it was *self*-consistent -- anyone care to check that under -lieee?: import math math.sqrt(-1) NaN or ValueError? 2.0 should raise ValueError regardless of what 1.5.2 did here.). just-another-day-of-universal-python-harmony-ly y'rs - tim _______________________________________________ Numpy-discussion mailing list Numpy-discussion at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/numpy-discussion From cgw at fnal.gov Thu Oct 12 14:24:55 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Thu, 12 Oct 2000 13:24:55 -0500 (CDT) Subject: [Numpy-discussion] Possible bug in LinearAlgebra module In-Reply-To: References: Message-ID: <14822.503.389177.597875@buffalo.fnal.gov> Aureli Soria Frisch writes: > I have been working with the function (implmenting the Moore-Penrose > generalized inverse) : of the module LinearAlgebra. It seems to > present a bug when operating on matrices of complex numbers. This may or may not be related, but there are definitely problems with arrays of complex numbers sometimes being unneccessarily promoted to type "Object" - for example: Python 2.0b1 (#2, Sep 8 2000, 12:10:17) [GCC 2.95.2 19991024 (release)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from Numeric import * >>> a = array([1,2,3], Complex) >>> a array([ 1.+0.j, 2.+0.j, 3.+0.j]) >>> a % 2.0 array([(1+0j) , 0j , (1+0j) ],'O') And we also know that there are a lot of problems with arrays of type "Object". So it's possible that somehow your Complex array is getting promoted to "Object" and running against a problem there. Just a guess, -cgw From sdm7g at virginia.edu Thu Oct 12 14:25:44 2000 From: sdm7g at virginia.edu (Steven D. Majewski) Date: Thu, 12 Oct 2000 14:25:44 -0400 (EDT) Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <200010121724.TAA15487@chinon.cnrs-orleans.fr> Message-ID: On Thu, 12 Oct 2000 hinsen at dirac.cnrs-orleans.fr wrote: > > The idea that your calculation should blow up and you should > > check it and resubmit your job sounds just so ancient-20th-century- > > Fortran-JCL-and-punched-cards-technology! > > Long-running jobs are still with us, even there's neither Fortran nor > JCL in them. And for these applications, stopping is better than going > on with nonsense values. On the other hand, as you point out, exceptions > for math errors are a bit of a pain for interactive work. > > So how about making this a run-time option? I'd choose exceptions by > default and Infs and Nans by specifying a command-line option, but > there are certainly others who would prefer it the other way round. > What matters most to me is that the choice is possible somehow. > I agree entirely! Maybe I was being a bit too glib, but I didn't mean to imply that wanting it to halt or throw an exception on errors is wrongheaded. I just wanted to make sure the counter-case to what Paul was saying also got heard: Yes-- underflows or infinities where they aren't expected are usually a sign that something is very wrong somewhere. But in the case where the vector holds independent observations or data points, then usually what it means is that there's something wrong with *that* data point -- miscallibrated or mislabeled -- but no reason not to complete the calculations for all of the other points. Scaling or doing projections for interactive graphics is another case where bad points are often better than throwing an exception. ( And it's a pain to have to remember to lambda wrap all the function calls with some sort of guard when you'ld be happy to get NaNs. ) I also mostly agree with Tim, except that I'm not sure that bad or incomplete ieee support is always better than none at all. ---| Steven D. Majewski (804-982-0831) |--- ---| Department of Molecular Physiology and Biological Physics |--- ---| University of Virginia Health Sciences Center |--- ---| P.O. Box 10011 Charlottesville, VA 22906-0011 |--- "All operating systems want to be unix, All programming languages want to be lisp." From tim_one at email.msn.com Thu Oct 12 16:33:41 2000 From: tim_one at email.msn.com (Tim Peters) Date: Thu, 12 Oct 2000 16:33:41 -0400 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: Message-ID: [Steven D. Majewski] > ... > I also mostly agree with Tim, except that I'm not sure that bad or > incomplete ieee support is always better than none at all. This is true, because having Python is better than not having Python, and in having Python you indeed have bad *and* incomplete 754 support on every 754 platform it runs on. Even better, it's a subset of damaged 754 support unique to each platform whose details can't be guessed or documented in advance of trying it exhaustively to see what happens(*), and a subset that can change delightfully across releases, compiler upgrades, library upgrades and seemingly irrelevant minor config changes. So if bad or incomplete IEEE support is good, Python is-- here as elsewhere --the King of Languages . Every step of this dance is thoroughly predictable. In this case, I'm doing my darnedest to nudge Python its very first step towards *real* 754 support, and getting dumped on for it by a 754 fan. Simultaneously, the "old guard" defends their lifestyle against new-fangled ideas , asking for protections unaware that 754 *requires* they get a better form of the protections they seek than they've dreamed of so far. It appears that nobody on either side has actually read the std, and I've become the very 754 Storm Trooper I used to despise. Computer life is great . all-it's-missing-is-variety-ly y'rs - tim (*) Quiz: *if* you can manage to trick Python into creating a NaN on your particular 754 platform, does the Python expression NaN == 1.0 return true, false, or raise an exception? Answer before you try it. Then try it on enough 754 platforms until you give up trying to guess in advance. NaN == NaN is predictable in Python, and is the one 754 feature Python guarantees won't work correctly on any 754 platform (although I've heard that it loses this predictability when run using NumPy's flavor of comparisons instead of core Python's). From jonathan.gilligan at vanderbilt.edu Thu Oct 12 17:47:40 2000 From: jonathan.gilligan at vanderbilt.edu (Jonathan M. Gilligan) Date: Thu, 12 Oct 2000 16:47:40 -0500 Subject: [Numpy-discussion] Off-Topic 754 question (was RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: References: Message-ID: <5.0.0.25.0.20001012162809.02742290@g.mail.vanderbilt.edu> This is a bit off-topic, but I noticed that there are lots of experts here and I have a question about IEEE-754 that has been bugging me for some time and which I was not able to get a good answer for on the USENET newsgroups. I am hoping that one of the experts in this list will take pity on my ignorance and answer what should be a simple question. Under Microsoft Visual C++, the Standard C++ library's numeric_limits::signaling_NaN() and numeric_limits::signaling_NaN() both return -INF values. The numeric_limits::quiet_NaN() and numeric_limits::quiet_NaN() both return -IND. I have not been able to determine whether this is "proper" behavior or whether it is another example of Microsoft ignoring standards? I would have thought that one of the two should return NaN. I certainly can't for the life of me figure out why someone would call INF a NaN, but as I have said, I'm pretty ignorant. Right now, if I want to use NaN's in my C++ code (e.g., to initialize newly allocated memory blocks) I build NaNs thus: >static long iNAN[2] = >{ > 0xFFFFFFFF, 0xFFFFFFFF >}; > >static double dNAN( > *reinterpret_cast(iNaN)) but would prefer something a little less bit-tweaky. Microsoft's documentation that this is the way they intend their library to work may be found at: http://msdn.microsoft.com/library/devprods/vs6/visualc/vclang/sample_Members_of_the_numeric_limits_Class_(STL_Sample).htm#_sample_stl_numeric_limits_class Thanks, Jonathan ============================================================================= Jonathan M. Gilligan jonathan.gilligan at vanderbilt.edu The Robert T. Lagemann Assistant Professor Office: 615 343-6252 of Living State Physics Lab (FEL) 343-7580 Dept. of Physics and Astronomy, Box 1807-B Fax: 343-7263 6823 Stevenson Center Vanderbilt University, Nashville, TN 37235 Dep't Office: 322-2828 From hinsen at dirac.cnrs-orleans.fr Fri Oct 13 10:11:03 2000 From: hinsen at dirac.cnrs-orleans.fr (hinsen at dirac.cnrs-orleans.fr) Date: Fri, 13 Oct 2000 16:11:03 +0200 Subject: [Numpy-discussion] Possible bug in LinearAlgebra module In-Reply-To: <14822.503.389177.597875@buffalo.fnal.gov> (message from Charles G Waldman on Thu, 12 Oct 2000 13:24:55 -0500 (CDT)) References: <14822.503.389177.597875@buffalo.fnal.gov> Message-ID: <200010131411.QAA17618@chinon.cnrs-orleans.fr> > This may or may not be related, but there are definitely problems with > arrays of complex numbers sometimes being unneccessarily promoted to > type "Object" - for example: Interesting. I have been fighting against a strangely version-dependent bug in which similar unwanted promotions to Object arrays occur when ufuncs are called, and now I wonder if there is any relation. I have tried a few times to track this down, but the code is so, well, complicated that I never get far enough before I run out of time. > And we also know that there are a lot of problems with arrays of > type "Object". So it's possible that somehow your Complex array is > getting promoted to "Object" and running against a problem there. LinearAlgebra certainly doesn't (and won't) work for Object arrays; it can handle only the data types supported by LAPACK. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen at cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From tbreuel at parc.xerox.com Fri Oct 13 13:59:30 2000 From: tbreuel at parc.xerox.com (tbreuel at parc.xerox.com) Date: Fri, 13 Oct 2000 10:59:30 PDT Subject: [Numpy-discussion] Re: Numpy-discussion digest, Vol 1 #115 - 4 msgs In-Reply-To: <200010131916.e9DJGtH22268@lists.sourceforge.net> Message-ID: On Fri, 13 Oct 2000 numpy-discussion-request at lists.sourceforge.net wrote: > having Python you indeed have bad *and* incomplete 754 support on every 754 > platform it runs on. Well, it depends on what you mean by "bad *and* incomplete 754 support". IEEE recommends specific semantics for comparison operators in language bindings, but I think their recommendations are undesirable from a programming language and software engineering point of view. If you follow IEEE semantics, you prohibit optimizers from optimizing in many cases and it contradicts type system semantics in some languages. Worst of all, programs that rely on IEEE semantics (in particular, of comparison operators) give no lexical indication that they do so; they will simply do something wrong, like go into an infinite loop or terminate a loop prematurely. I think it's best to raise an exception for any expression involving a NaN, unless the programmer explicitly indicated that he wants a NaN result and IEEE semantics. Another good approach is to provide separate IEEE operators and leave the behavior of the built-in operators on IEEE special values explicitly undefined. This keeps people from relying on one behavior or the other. To me, the worst possible choice is to "implement IEEE semantics correctly", i.e., in the way the IEEE authors envisioned it. (Of course, IEEE is reasonably nice from a numerical point of view; I just think they overextended themselves when talking about language bindings). > (*) Quiz: *if* you can manage to trick Python into creating a NaN on your > particular 754 platform, does the Python expression NaN == 1.0 return true, > false, or raise an exception? Answer before you try it. Then try it on > enough 754 platforms until you give up trying to guess in advance. NaN == > NaN is predictable in Python, and is the one 754 feature Python guarantees > won't work correctly on any 754 platform (although I've heard that it loses > this predictability when run using NumPy's flavor of comparisons instead of > core Python's). This is just the sort of issue I was referring to. In many dynamic languages, the assumption is that pointer quality implies object equality. That's a perfectly reasonable semantic choice. While Python may not implement "754 correctly" in the sense of the (probably) Fortran-thinking IEEE floating point designers, I think Python's choice is correct and should not be altered. People who really want IEEE floating point comparison operations can use something like ieee.equal(a,b). That alerts the reader that something special is going on, it will fail on non-IEEE platforms (indicating that the code wouldn't work correctly there anyway), and it makes only the code that needs to pay the price for strict IEEE conformance. Cheers, Thomas. From sdhyok at email.unc.edu Fri Oct 13 20:25:53 2000 From: sdhyok at email.unc.edu (Daehyok Shin) Date: Fri, 13 Oct 2000 17:25:53 -0700 Subject: [Numpy-discussion] [Q]Best way for an array operation? Message-ID: <008601c03575$5036fa80$52f9a218@nc.rr.com> What is the best Numpy way for the following work? for i in range(len(x)): if x[i] > 0: y[i] = v[i] z[i] = u[i]+2 Daehyok Shin (Peter) From jhauser at ifm.uni-kiel.de Fri Oct 13 19:13:23 2000 From: jhauser at ifm.uni-kiel.de (Janko Hauser) Date: Sat, 14 Oct 2000 01:13:23 +0200 (CEST) Subject: [Numpy-discussion] [Q]Best way for an array operation? In-Reply-To: <008601c03575$5036fa80$52f9a218@nc.rr.com> References: <008601c03575$5036fa80$52f9a218@nc.rr.com> Message-ID: <20001013231323.28257.qmail@lisboa.ifm.uni-kiel.de> You do not define, what values are in z,y if x < 0, so I presume, they keep the current value. >>> true = greater(x,0.) >>> z=where(true, u+2., z) >>> y=where(true, v, y) HTH, __Janko Daehyok Shin writes: > What is the best Numpy way for the following work? > > for i in range(len(x)): > if x[i] > 0: > y[i] = v[i] > z[i] = u[i]+2 > > Daehyok Shin (Peter) > > > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion at lists.sourceforge.net > http://lists.sourceforge.net/mailman/listinfo/numpy-discussion From cbarker at jps.net Fri Oct 13 21:22:28 2000 From: cbarker at jps.net (Chris Barker) Date: Fri, 13 Oct 2000 18:22:28 -0700 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) References: Message-ID: <39E7B554.29A168E3@jps.net> Incomplete vs. non-at-all IEEE 754 support is a non argument. If you have full IEEE support (which it seems everyone here thinks would be good, but difficult), it is clear what you have. If not, you are not consistent with a standard, and therefor making up your own. That being the case, it's a matter of what we want the Python standard to be. I, for one think that NaN and Inf are fantastic!!! I think the best argument for them here is that it is almost impossible to do a lot of array based calculations without them, and you can't do serious number crunching in Python without array based calculations. I've come to Python from MATLAB for numerics, and I really appreciated MATLAB's way of handling all this. I don't think MATLAB has true 754 support, as I don't think you can change the behaviour, but you do get a consistent result across platforms (including non-iee machines like the Cray?---I have no idea). I have not yet heard a decent response to the question of what to do when a single value in a large array is bad, and causes an exception. This really does render Python essentially useless for Numerics for me. I suspect all those number crunchers that want an exception rather than an Inf are NOT using array-oriented languages. My goal is to dump MATLAB for Python, but this may prevent me from doing that. Does anyone know what other array-oriented languages use? I know what MATLAB does: >> exp(-777) ans = 0 >> exp(777) ans = Inf >> sqrt(-1) ans = 0 + 1.0000i Hey! I like that! Python is dynamic, why can't we just get the actual answer to sqrt(-1), without using cmath, that always returns a complex ? sorry, other subjet, not meant to be raised at the moment. >> 54/0 Warning: Divide by zero. ans = Inf Here we get a warning, but also a result that won't crash the computation. >> a = 0/0 Warning: Divide by zero. a = NaN >> b = a b = NaN >> a == b ans = 0 So comparing two NaNs yields a false, as it should, and though Python won't do it now, it could. One thing that a numerical routine should NEVER do is give an incorrect answer. No answer is often bad, but an incorrect one is much worse. NaN == NaN must return false. Does anyone know what FORTRAN 90 specifies (if anything)? What other array-oriented languages are there? I think what MATLAB does is what Tim is calling "bad *and* incomplete 754 support" Incomplete is surely true, "bad" is clearly a matter of opinion. It seems we have a variety of users of numerics in Python, that I break into three broad catagories: Casual users: mostly doing non-numeric stuff, with the occasional calculation: This group could use any non-cryptic handling of over/underflow, it just doesn't matter. Mid-level number crunchers: This is the group I put myself in. We crunch a lot of numbers, really like the array semantics (and speed) of NumPy, and are doing things like graphing functions, statistical calculations, etc. We have probably only taken one of two (at most) numerical analysis courses, and many don't know what the heck IEE 754 is. (The one Numerical Analysis course I did take, happened to be with Kahan, which is why I know what it is) For this group, the incomplete IEEE support is probably the best way to go. We're more likely to be annoyed by our whole computation stopping because of one bad data point, than we are to be pissed off that it didn't stop when it started to compute garbage. Hard Core Number crunchers: These are the folks that do things like write optimised routines for particular architectures, adn teach numerical analysis courses. These folks want either FULL IEEE, or plain old "classic" overflow and underflow errors, that they can handle themselves. Do these folks really use Python as other than a glue language? Are they really doing massive number crunching in Python itself, rather than in C (or whatever) extensions? If so, I'd be surprised is they didn't find Huaiyu's argument compelling when doing array based calculations. Tim pointed out that Python was not designed with 754 in mind, so for 2.0, what he is doing is probably our best bet, but it seems to not be the best ultimate solution, I hope using NaN and Inf will be considered for future versions, even if it is incomplete 754 compliance. Note: if the ultimate goal is REAL IEEE 754 compliance, is it possible without custom re-compiling your own interpreter? If so, is there any chance that it will come any time soon (2.1 ?) , so we don't have to have this discussion at all? Thanks for all of your work on this, Python just keeps getting better!! -Chris -- Christopher Barker, Ph.D. cbarker at jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From cgw at fnal.gov Fri Oct 13 22:44:42 2000 From: cgw at fnal.gov (Charles G Waldman) Date: Fri, 13 Oct 2000 21:44:42 -0500 (CDT) Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <39E7B554.29A168E3@jps.net> References: <39E7B554.29A168E3@jps.net> Message-ID: <14823.51354.977817.409017@buffalo.fnal.gov> Chris Barker writes: > Hey! I like that! Python is dynamic, why can't we just get the actual > answer to sqrt(-1), without using cmath, that always returns a complex ? You have to import the sqrt function from somewhere. Either you import it from math or from cmath, depending on which flavor you need. Anybody sophisticated enough to know what complex numbers are, and sophisticated enough to want to get complex values as a result of a calculation, should be sophisticated enough to be able to type "cmath". From pauldubois at home.com Sat Oct 14 11:58:37 2000 From: pauldubois at home.com (Paul F. Dubois) Date: Sat, 14 Oct 2000 08:58:37 -0700 Subject: [Numpy-discussion] [Q]Best way for an array operation? In-Reply-To: <008601c03575$5036fa80$52f9a218@nc.rr.com> Message-ID: There is (in CVS) a new function, putmask: c = greater(x, 0) putmask(y, c, v) putmask(z, c, u+2) The documentation is now online. Briefly: putmask(a, m, v) sets a to v where m is true. a must be a contiguous array m must be the same total size as a (shape ignored) v will be repeated as needed to that size The underlying work is done in C. -----Original Message----- From: numpy-discussion-admin at lists.sourceforge.net [mailto:numpy-discussion-admin at lists.sourceforge.net]On Behalf Of Daehyok Shin Sent: Friday, October 13, 2000 5:26 PM To: Numpy Discussion Subject: [Numpy-discussion] [Q]Best way for an array operation? What is the best Numpy way for the following work? for i in range(len(x)): if x[i] > 0: y[i] = v[i] z[i] = u[i]+2 Daehyok Shin (Peter) _______________________________________________ Numpy-discussion mailing list Numpy-discussion at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/numpy-discussion From jhauser at ifm.uni-kiel.de Sat Oct 14 14:32:33 2000 From: jhauser at ifm.uni-kiel.de (Janko Hauser) Date: Sat, 14 Oct 2000 20:32:33 +0200 (CEST) Subject: [Numpy-discussion] [Q]Best way for an array operation? In-Reply-To: References: <008601c03575$5036fa80$52f9a218@nc.rr.com> Message-ID: <20001014183233.28900.qmail@lisboa.ifm.uni-kiel.de> What is the difference of putmask and where? As it seems the only difference is the inplace behavior. This becomes more and more complicated as we have this subtle difference at many places (ravel vs. flat) and in future also the augmented assignment stuff, which also works for arrays now, although I do not know, if it's really an inplace assignment. What are the next functions for which a spacesaving variant is introduced? Would it be better to come to another convention for this type of optimization? As a side note the order of arguments is different for putmask and where. __Janko Paul F. Dubois writes: > There is (in CVS) a new function, putmask: > > c = greater(x, 0) > putmask(y, c, v) > putmask(z, c, u+2) > > The documentation is now online. Briefly: > putmask(a, m, v) sets a to v where m is true. > > a must be a contiguous array > m must be the same total size as a (shape ignored) > v will be repeated as needed to that size > > The underlying work is done in C. > > -----Original Message----- > From: numpy-discussion-admin at lists.sourceforge.net > [mailto:numpy-discussion-admin at lists.sourceforge.net]On Behalf Of > Daehyok Shin > Sent: Friday, October 13, 2000 5:26 PM > To: Numpy Discussion > Subject: [Numpy-discussion] [Q]Best way for an array operation? > > > What is the best Numpy way for the following work? > > for i in range(len(x)): > if x[i] > 0: > y[i] = v[i] > z[i] = u[i]+2 > > Daehyok Shin (Peter) > > > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion at lists.sourceforge.net > http://lists.sourceforge.net/mailman/listinfo/numpy-discussion > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion at lists.sourceforge.net > http://lists.sourceforge.net/mailman/listinfo/numpy-discussion From nick at nickbower.com Sun Oct 15 01:09:26 2000 From: nick at nickbower.com (Nick Bower) Date: Sun, 15 Oct 2000 05:09:26 GMT Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <39E7B554.29A168E3@jps.net> References: <39E7B554.29A168E3@jps.net> Message-ID: <20001015.5092600@cricket.> > Does anyone know what other array-oriented languages use? I know what > MATLAB does: I'm an Interactive Data Language or IDL user (the Univ of Wisconsin's Space Science Ceter is split down the middle between this and MatLab, but python/numpy is definitely on the increase). As you can see from results below, like MatLab over/under-flows in IDL are reported but do not stop execution. This is the best (only) possible scenario for an interactive arrays and visualization environment. IDL> print, exp(-777) 0.00000 % Program caused arithmetic error: Floating underflow IDL> print, exp(777) Inf % Program caused arithmetic error: Floating overflow IDL> print, sqrt(-1) -NaN % Program caused arithmetic error: Floating illegal operand IDL> print, 54/0 54 % Program caused arithmetic error: Integer divide by 0 From hinsen at cnrs-orleans.fr Sun Oct 15 15:04:27 2000 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Sun, 15 Oct 2000 21:04:27 +0200 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <39E7B554.29A168E3@jps.net> (message from Chris Barker on Fri, 13 Oct 2000 18:22:28 -0700) References: <39E7B554.29A168E3@jps.net> Message-ID: <200010151904.VAA32561@chinon.cnrs-orleans.fr> > I've come to Python from MATLAB for numerics, and I really appreciated > MATLAB's way of handling all this. I don't think MATLAB has true 754 MATLAB is fine for simple interactive data processing, and its behaviour is adapted to this task. I don't think anyone would use MATLAB for developing complex algorithms, its programming language isn't strong enough for that. Python is, so complex algorithms have to be considered as well. And for that kind of application, continuing a calculation with Infs and NaNs is a debugging nightmare. > I have not yet heard a decent response to the question of what to do > when a single value in a large array is bad, and causes an exception. I'd like to have at least the option of raising an exception in that case. Note that this is not what NumPy does today. > >> sqrt(-1) > ans = > 0 + 1.0000i > > Hey! I like that! Python is dynamic, why can't we just get the actual > answer to sqrt(-1), without using cmath, that always returns a complex ? For the same reason that makes 2/3 return zero instead of a float division result. Like C or Fortran, Python treats integers, floats, and complex numbers as different data types. And the return type of a function should depend only on the types, but not the values, of its parameters (for consistency, not because of any implementational limitation). So sqrt(a) for a of type float can either always return a float (math, Numeric) and crash for negative arguments, or always return a complex (cmath). The "right" solution, in my opinion, would be to have a single "number" type of which integers, float, and complex numbers are simply different internal representations. But such a change cannot be introduced without breaking a lot of code. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen at cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From tim_one at email.msn.com Sun Oct 15 16:35:27 2000 From: tim_one at email.msn.com (Tim Peters) Date: Sun, 15 Oct 2000 16:35:27 -0400 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: <200010151904.VAA32561@chinon.cnrs-orleans.fr> Message-ID: [cbarker at jps.net] >> I've come to Python from MATLAB for numerics, and I really appreciated >> MATLAB's way of handling all this. I don't think MATLAB has true 754 ... [Konrad Hinsen] > MATLAB is fine for simple interactive data processing, and its > behaviour is adapted to this task. I don't think anyone would use > MATLAB for developing complex algorithms, its programming language > isn't strong enough for that. Python is, so complex algorithms have to > be considered as well. And for that kind of application, continuing a > calculation with Infs and NaNs is a debugging nightmare. A non-constructive (because futile) speculation: the first time I saw what 754 was intending to do, my immediate reaction was "hmm -- the exponent field is too narrow!". With a max (double) val in the ballpark of 1e300, you get an infinity as soon as you square something as small as 1e150, and once you get a few infinities, NaNs are sure to follow (due to Inf-Inf and Inf/Inf). The dynamic range for 754 singles is much smaller still. There's no doubt about Cray arithmetic being hard to live with, but while Mr. Cray didn't worry about proper rounding, he did devote 15 bits to Cray's exponent field (vs. 11 for 754). As a result, overflows were generally a non-issue on Cray boxes, and *nobody* complained (in my decade there) about Cray HW raising a fatal exception if one occurred. In return, you got only 48 bits of precision (vs. 53 for 754). But, for most physical problems, how accurate are the inputs? 10 bits on a good day, 20 bits on a great day? Crays worked despite their sloppy numerics because, for most problems to which they were applied, they carried more than twice the precision *and* dynamic range than the final results needed. >> I have not yet heard a decent response to the question of what to do >> when a single value in a large array is bad, and causes an exception. I'd usually trace back and try to figure out how it got "bad" to begin with ... > I'd like to have at least the option of raising an exception in that > case. Note that this is not what NumPy does today. Does NumPy use the fpectl module? I suppose not. LLNL contribued that code, but we hear very little feedback on it. It arranges to (in platform-dependent ways) convert the 754 overflow, divide-by-0 and invalid-operation signals into Python exceptions. In core Python, this is accomplished at the extraordinary expense of doing a setjmp before, and a function call + double->int conversion after, every single fp operation. A chief problem is that SIGFPE is the only handle C gives us on fp "errors", and the C std does not allow returning from a SIGFPE handler (the result of trying to is undefined, and indeed varies wildly across platforms); so if you want to regain control, you have to longjmp out of the handler. The NumPy implementation could use the PyFPE_START_PROTECT and PyFPE_END_PROTECT macros to brackete entire array operations, though, and so pay for the setjmp etc only once per array op. This is difficult stuff, but doable. >> >> sqrt(-1) >> ans = >> 0 + 1.0000i >> >> Hey! I like that! Python is dynamic, why can't we just get the actual >> answer to sqrt(-1), without using cmath, that always returns a complex ? > For the same reason that makes 2/3 return zero instead of a float > division result. Like C or Fortran, Python treats integers, floats, > and complex numbers as different data types. You know I'm in general agreement with you on this one, but I have to draw a distinction here: Guido thinks that 2/3 returning 0 was a design mistake, but not that math.sqrt(-1) raising an exception is a mistake. Most Python users won't know what to do with a complex number, so it's "an error" to them. I would like to view this in P3K (if not earlier) as being akin to 754 exceptions: some people are delighted to have 1e300**2 return +Inf, while others want to see OverflowError instead, and still others want to see +Inf *and* have a sticky flag set saying "an overflow occurred". We could treat f(x) (for f == sqrt and everything else) the same way wrt to a new ComplexResultFromNonComplexInputsError: define "non-stop" complex results, let the user choose whether to do nonstop or raise an exception, and a supply a sticky flag saying whether or not any complex results were generated from non-complex inputs. > ... > The "right" solution, in my opinion, would be to have a single > "number" type of which integers, float, and complex numbers are simply > different internal representations. But such a change cannot be > introduced without breaking a lot of code. The current distinction between ints and longs (unbounded ints) should also get swallowed by this. A way to get from here to there is especially irksome at the C API level, since, e.g., many C API functions pass Python ints as C longs directly. A smaller number pass Python floats as C doubles directly. it's-wonderful-that-p3k-will-solve-everything-ly y'rs - tim From jsaenz at wm.lc.ehu.es Mon Oct 16 11:45:43 2000 From: jsaenz at wm.lc.ehu.es (Jon Saenz) Date: Mon, 16 Oct 2000 17:45:43 +0200 (MET DST) Subject: [Numpy-discussion] ANNOUNCE: PyClimate 1.0 Message-ID: Monday, 10/16/2000 Hello, all. We are making the first announce of the first stable release (1.0) of our package pyclimate, which presents some tools used for climate variability analysis and which make extensive use of Numerical Python and C. It is released under the GNU Public License. Changes from the previous release Version 1.0--October, 2000. 1) Improved tests. They are more accurate, reliable, informative, comprehensive and use less disk space. 2) The package compiles using distutils. This feature has been checked on FreeBSD, Linux and OSF platforms. 3) Some minor typos corrected in the documentation. 4) Added KPDF.c, a extension module to estimate univariate and multivariate kernel--based probability density functions. 5) Added a class to compute the vertical component of the curl of a vectorial field in diffoperators.py. 6) DCDFLIB.C is currently distributed with the package. 7) KZFilter.py has been converted into a general purpose LinearFilter.py which holds the basic operations of any linear filter. There are two different subclasses currently, the Lanczos filter and the previous Kolmogorov--Zurbenko filter, KZFilter.py. The user can define new filters just by redefining the filter coefficients subclassing LinearFilter. The package also contains (from release 0.0): IO functions ------------ -ASCII files (simple, but useful) -ncstruct.py: netCDF structure copier. From a COARDS compliant netCDF file, this module creates a COARDS compliant file, copying the needed attributes, comments, and so on in one call. Time handling routines ---------------------- * JDTime.py -> Some C/Python functions to convert from date to Scaliger's Julian Day and from Julian Day to date. We are not trying to replace mxDate, but addressing a different problem. In particular, this module contains a routine especially suited to handling monthly time steps for climatological use. * JDTimeHandler.py -> Python module which parses the units attribute of the time variable in a COARDS file and which offsets and scales adequately the time values to read/save date fields. Interface to DCDFLIB.C ---------------------- A C/Python interface to the free DCDFLIB.C library is provided. This library allows direct and inverse computations of parameters for several probability distribution functions like Chi^2, normal, binomial, F, noncentral F, and many many more. EOF analysis ------------ Empirical Orthogonal Function analysis based on the SVD decomposition of the data matrix and related functions to test the reliability/degeneracy of eigenvalues (truncation rules). Monte Carlo test of the stability of eigenvectors to temporal subsampling. SVD decomposition ----------------- SVD decomposition of the correlation matrix of two datasets, functions to compute the expansion coefficients, the squared cumulative covariance fraction and the homogeneous and heterogeneous correlation maps. Monte Carlo test of the stability of singular vectors to temporal subsampling. Multivariate digital filter --------------------------- Multivariate digital filter (high and low pass) based on the Kolmogorov-Zurbenko filter Differential operators on the sphere ------------------------------------ Some classes to compute differential operators (gradient and divergence) on a regular latitude/longitude grid. LICENSE ======= GNU General Public License Version 2. PREREQUISITES ============= To be able to use it, you will need: 1. Python ;-) 2. netCDF library 3.4 or later 3. Scientific Python, by Konrad Hinsen IF AND ONLY IF you really want to change the C code (JDTime.[hc] and pycdf.[hc]), then, you will also need SWIG. COMPILATION =========== Now, we use distutils. The installation is simpler. DOCUMENTATION ============= Postscript and PDF versions of the manual are included in the distribution. We are preparing an even better version of the documentation. AVAILABILITY ============ http://lcdx00.wm.lc.ehu.es/~jsaenz/pyclimate (Europe) http://pyclimate.zubi.net/ (USA) http://starship.python.net/crew/~jsaenz (USA) Any feedback from the users of the package will be really appreciated by the authors. Enjoy. Jon Saenz, jsaenz at wm.lc.ehu.es Juan Zubillaga, wmpzuesj at lg.ehu.es Jesus Fernandez, chus at wm.lc.ehu.es

PyClimate 1.0 - Several routines for the analysis of climate variability. (16-Oct-00) From hinsen at cnrs-orleans.fr Mon Oct 16 11:52:43 2000 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Mon, 16 Oct 2000 17:52:43 +0200 Subject: [Python-Dev] RE: [Numpy-discussion] RE: Possible bug (was Re: numpy, overflow, inf, ieee, and rich comparison) In-Reply-To: References: Message-ID: <200010161552.RAA02685@chinon.cnrs-orleans.fr> > > I'd like to have at least the option of raising an exception in that > > case. Note that this is not what NumPy does today. > > Does NumPy use the fpectl module? I suppose not. LLNL contribued that No. Perhaps it should, but it doesn't make sense unless fpectl works on a large number of platforms. I confess I have never looked at it. I want my code to be portable, so I don't even consider using packages that aren't. > > For the same reason that makes 2/3 return zero instead of a float > > division result. Like C or Fortran, Python treats integers, floats, > > and complex numbers as different data types. > > You know I'm in general agreement with you on this one, but I have to draw a > distinction here: Guido thinks that 2/3 returning 0 was a design mistake, > but not that math.sqrt(-1) raising an exception is a mistake. Most Python > users won't know what to do with a complex number, so it's "an error" to > them. Well, that would be a good occasion to learn about complex numbers! I remember having learned about generalized inverses by using APL in high school (in a very similar way: I was amazed that it could invert non-square matrices), and that turned out to be very useful knowledge later on. Perhaps that's a topic for the EDU-SIG... Anyway, I don't care what math.sqrt(-1) does, but I would definitely prefer Numeric.sqrt(-1) to return a complex result. And I think that someone who uses NumPy has probably heard about complex numbers. > I would like to view this in P3K (if not earlier) as being akin to > 754 exceptions: some people are delighted to have 1e300**2 return +Inf, > while others want to see OverflowError instead, and still others want to see > +Inf *and* have a sticky flag set saying "an overflow occurred". We could > treat f(x) (for f == sqrt and everything else) the same way wrt to a new > ComplexResultFromNonComplexInputsError: define "non-stop" complex results, > let the user choose whether to do nonstop or raise an exception, and a > supply a sticky flag saying whether or not any complex results were > generated from non-complex inputs. There is, however, one difference: in properly debugged production code, there should be no overflow situations, so it doesn't matter much how they are treated. Complex number can (do!) occur in production code, but there could also be production code relying on exceptions for sqrt(-1) (e.g. for input error checking). Therefore a program using several libraries might be impossible to run with either setting. Since this concerns only the math module, I'd prefer to keep separate module versions for the two cases, which can be used in parallel. > > The "right" solution, in my opinion, would be to have a single > > "number" type of which integers, float, and complex numbers are simply > > different internal representations. But such a change cannot be > > introduced without breaking a lot of code. > > The current distinction between ints and longs (unbounded ints) should also > get swallowed by this. A way to get from here to there is especially > irksome at the C API level, since, e.g., many C API functions pass Python > ints as C longs directly. A smaller number pass Python floats as C doubles > directly. I don't see the problem in that direction, it's rather C API functions that *return* numbers in C data types that would be difficult to adapt. But then, why should be C API not be allowed in P3K? it's-wonderful-that-anything-may-be-changed-in-p3k'ly Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen at cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From cbarker at jps.net Mon Oct 16 13:38:11 2000 From: cbarker at jps.net (Chris Barker) Date: Mon, 16 Oct 2000 10:38:11 -0700 Subject: [Numpy-discussion] Re: numpy, overflow, inf, ieee, and rich comparison References: Message-ID: <39EB3D03.A00C78B6@jps.net> > >> I have not yet heard a decent response to the question of what to do > >> when a single value in a large array is bad, and causes an exception. > > I'd usually trace back and try to figure out how it got "bad" to begin with And from Konrad Hinsen >I'd like to have at least the option of raising an exception in that >case. Note that this is not what NumPy does today. Exactly. This was Huaiyu's point. The problem is that for your code to be usable for folks other than yourself, you'd have to have a lot of checks in there, and essentially revert to elementwise code, which would kill you. With the addition of the occasional "isnan" and something like Matlab's "any" ( "any(isnan(A))" returns true if any of the elements of A are NaNs) you could set up your code to raise an exception in the middle of computation. If, on the other hand the Code definiately raises an exception, than you are stuck with a lot of elementwise coding. > over/under-flows in IDL are reported but do > not stop execution. This is the best (only) possible scenario for an > interactive arrays and visualization environment. Exactly!!! ("the best (only) possible scenario" part) > IDL> print, 54/0 > 54 > % Program caused arithmetic error: Integer divide by 0 This, however, is wierd!! 54/0 == 54 ??? I'd much rather see a NaN or Inf here! > MATLAB is fine for simple interactive data processing, and its > behaviour is adapted to this task. I don't think anyone would use > MATLAB for developing complex algorithms, its programming language > isn't strong enough for that. Python is, so complex algorithms have to > be considered as well. And for that kind of application, continuing a > calculation with Infs and NaNs is a debugging nightmare. People do some pretty complex algorith develpment with MATLAB. I'm also no so sure about "continuing a calculation with Infs and NaNs is a debugging nightmare" I'm don't think it's any more of a nighmare than having your calculation on an entire array stop because of one Inf. It's just a different trade off. Sprinkle a few "isnan"'s in there and and you can get the behaviour you want, while not forcing it on all calculations. Of course, the best option is to have it switchable, but that may prove to be very difficult. Are people doing the kind of numeric programming with "complex algorithms" using Python that Konrad refers to? More importantly, how many people? > Guido thinks that 2/3 returning 0 was a design mistake, > but not that math.sqrt(-1) raising an exception is a mistake. Most Python > users won't know what to do with a complex number, so it's "an error" to > them. Guido's philosophy is clearly that Python defaults should be geared to "Most Python users". I agree, and as I wrote in an earlier post, the only users for whom the "exception raising only" option is best are the users Konrad refers to as writing "complex algorithms". I would argue that those users are few, and the group most able to deal with a less-that-optimum system. Maybe we can have true 754 compliance in Py3k, and we can all be happy!! -Chris -- Christopher Barker, Ph.D. cbarker at jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From pete at shinners.org Mon Oct 16 23:25:35 2000 From: pete at shinners.org (Pete Shinners) Date: Mon, 16 Oct 2000 20:25:35 -0700 Subject: [Numpy-discussion] compile for application Message-ID: <003301c037e9$ed436ae0$0200a8c0@home> i have a python application which has a small extension module it needs. (written in C for speed). does anyone have an example setup.py script that will build the extension, but leave the finished module in the current directory (and not intall to PYTHONHOME?) thanks From pete at shinners.org Mon Oct 16 23:58:56 2000 From: pete at shinners.org (Pete Shinners) Date: Mon, 16 Oct 2000 20:58:56 -0700 Subject: [Numpy-discussion] simple array help? Message-ID: <004a01c037ee$964dd040$0200a8c0@home> i have a simple array with floating values >>> print a array([ 0. , 0.2, 0.4, 0.6, 0.8]) what i need to do is change each index into another dimension with 3 indices. hmm, kind of confusing, an example will explain better >>> b = array(zip(a,a,a)) >>> print b array([[ 0. , 0. , 0. ], [ 0.2, 0.2, 0.2], [ 0.4, 0.4, 0.4], [ 0.6, 0.6, 0.6], [ 0.8, 0.8, 0.8]]) ok, this does the job, but once i start using large arrays, the back-n-forth conversion between arrays and python lists is costing me quite a bit. is there a way i can reshape the array this way without the call to python's 'zip'? (no, 'map' doesn't count either) i've tried much fooling with NewAxis, resize, and friends. but either i haven't stumbled upon the correct combination or i'm not trying the correct tools. i'd like to keep this as quick as possible, so hopefully it can be done without anything too elaborate. thanks (doh, sorry for the previous distutils related post... hit the wrong mailing list) From jhauser at ifm.uni-kiel.de Tue Oct 17 03:00:36 2000 From: jhauser at ifm.uni-kiel.de (Janko Hauser) Date: Tue, 17 Oct 2000 09:00:36 +0200 (CEST) Subject: [Numpy-discussion] simple array help? In-Reply-To: <004a01c037ee$964dd040$0200a8c0@home> References: <004a01c037ee$964dd040$0200a8c0@home> Message-ID: <20001017070036.7761.qmail@lisboa.ifm.uni-kiel.de> Your mail is in some windows format :-) reshape(resize(a,(1,15)),(5,3)) ,should do it, perhaps reshape makes a new copy, to circumvent this you can do it in two steps. b=resize(a,(1,15)) b.shape = (5,3) Another way is ones((5,3), a.typecode())*a[:,NewAxis] HTH, __Janko From hinsen at cnrs-orleans.fr Tue Oct 17 16:27:22 2000 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Tue, 17 Oct 2000 22:27:22 +0200 Subject: [Numpy-discussion] simple array help? In-Reply-To: <004a01c037ee$964dd040$0200a8c0@home> (pete@shinners.org) References: <004a01c037ee$964dd040$0200a8c0@home> Message-ID: <200010172027.WAA11910@chinon.cnrs-orleans.fr> > i have a simple array with floating values > >>> print a > array([ 0. , 0.2, 0.4, 0.6, 0.8]) There are probably many solutions, my preferred one is repeat(a[:, NewAxis], [3], 1) Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen at cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From hinsen at cnrs-orleans.fr Tue Oct 17 16:27:10 2000 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Tue, 17 Oct 2000 22:27:10 +0200 Subject: [Numpy-discussion] Re: numpy, overflow, inf, ieee, and rich comparison In-Reply-To: <39EB3D03.A00C78B6@jps.net> (message from Chris Barker on Mon, 16 Oct 2000 10:38:11 -0700) References: <39EB3D03.A00C78B6@jps.net> Message-ID: <200010172027.WAA11907@chinon.cnrs-orleans.fr> > Are people doing the kind of numeric programming with "complex > algorithms" using Python that Konrad refers to? More importantly, how > many people? At least one: me. > > Guido thinks that 2/3 returning 0 was a design mistake, > > but not that math.sqrt(-1) raising an exception is a mistake. Most Python > > users won't know what to do with a complex number, so it's "an error" to > > them. > > Guido's philosophy is clearly that Python defaults should be geared to > "Most Python users". I agree, and as I wrote in an earlier post, the It's difficult to say what "most Python users" want; it's not a static community. I'd say the basic principle is "no bad surprises". 2/3 == 0 is a bad surprise for anyone who knows elementary math but is not familiar with certain programming languages, especially since the program goes on silently with a "wrong" intermediate result. > Maybe we can have true 754 compliance in Py3k, and we can all be happy!! Py3k forever! Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen at cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From michael at visionpro.com Wed Oct 18 11:35:02 2000 From: michael at visionpro.com (Michael D. Risser) Date: Wed, 18 Oct 2000 08:35:02 -0700 Subject: [Numpy-discussion] Numpy install problems Message-ID: <00101808405300.01041@penguin.visionpro.com> When attempting to install Numeric 17.0 with Python 1.5.2 and Distutils 1.0 on Red Hat 7.0, I get the following error after issuing the command 'python setup.py install' Traceback (innermost last): File "setup.py", line 15, in ? vs = map(string.atoi, v.groups()) AttributeError: 'None' object has no attribute 'groups' This error occurs regardless of whether or not I am root. I have also tried uninstalling the Red Hat Python packages and installing all from source, but I get the same error. Any help would be appreciated. Thanks. From cbarker at jps.net Wed Oct 18 20:15:40 2000 From: cbarker at jps.net (Chris Barker) Date: Wed, 18 Oct 2000 17:15:40 -0700 Subject: [Numpy-discussion] PyArray_Check problem. References: <004a01c037ee$964dd040$0200a8c0@home> Message-ID: <39EE3D2C.51A92A71@jps.net> I have been working on my first C extension, using NumPy arrays, and have run into a problem. I have a very mysterious set of bugs, that result in a segmentation fault and core dump. Frankly it's still mysterious, but at the moment the problem seems to be that I have passed in a list of tuples, rather than a list of PyArrayObjects. I don't expect this to work, but when I put a : site = PyList_GetItem(spam_list, index); if (! PyArray_Check(spam)) result = 0; I shouldn't get a crash!! (and it does crash at this line, as near as I can tell) Isn't that exactly what PyArray_Check is for?? Note: with: spam = PyList_GetItem(spam_list, index); I get a "warning: assignment from incompatible pointer type " which goes away if I typecast it: spam = (PyArrayObject *) PyList_GetItem(spam_list, index); Should I be doing this, and should PyArray_Check(spam) work either way? I'm using Redhat Linux 6.1, Python 1.5.2, and python-numpy-1.11-2.i386.rpm Also: is there a compelling reason to upgrade either Python of NumPy, from the NumPy perspective? How are NumPy and 2.0 working together? Thanks, -Chris -- Christopher Barker, Ph.D. cbarker at jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From hinsen at cnrs-orleans.fr Thu Oct 19 13:25:24 2000 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Thu, 19 Oct 2000 19:25:24 +0200 Subject: [Numpy-discussion] PyArray_Check problem. In-Reply-To: <39EE3D2C.51A92A71@jps.net> (message from Chris Barker on Wed, 18 Oct 2000 17:15:40 -0700) References: <004a01c037ee$964dd040$0200a8c0@home> <39EE3D2C.51A92A71@jps.net> Message-ID: <200010191725.TAA14895@chinon.cnrs-orleans.fr> > fault and core dump. Frankly it's still mysterious, but at the moment > the problem seems to be that I have passed in a list of tuples, rather > than a list of PyArrayObjects. I don't expect this to work, but when I > put a : > > site = PyList_GetItem(spam_list, index); > > if (! PyArray_Check(spam)) result = 0; ^^^^ Not "site"? > I shouldn't get a crash!! (and it does crash at this line, as near as I > can tell) If spam is NULL, then the check will crash. If it is anything but a pointer to a Python object, there's a good chance that it might crash. PyArray_Check just tells you if a given Python object is of type "array". A look at the value of "spam" with a debugger should tell you what's going on. > which goes away if I typecast it: > > spam = (PyArrayObject *) PyList_GetItem(spam_list, index); > > Should I be doing this, and should PyArray_Check(spam) work either way? It works either way, but I am not sure that you are supposed to rely on that. I prefer to use a cast to array objects only *after* verifying that I have an array object, if only for clarity. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen at cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From busby at icf.llnl.gov Thu Oct 19 15:27:48 2000 From: busby at icf.llnl.gov (L. Busby) Date: Thu, 19 Oct 2000 12:27:48 -0700 (PDT) Subject: [Numpy-discussion] Re: comments on the Numerical Python manual Message-ID: <200010191927.MAA07139@icf.llnl.gov> Fred - I'm forwarding your mail on to numpy-discussion at lists.sourceforge.net, which I believe is the proper venue to deal with your comments. If the current Numerical Python manual directed you to support at icf.llnl.gov for support-related questions, that also needs to be updated. Thank you - Lee Busby ======================================================================= From: Fred Yankowski To: support at icf.llnl.gov Subject: comments on the Numerical Python manual Greetings, I'm learning NumPy by working through the "Numerical Python" manual (Oct 9, 2000 version). So far the manual has been a great introduction to the software and I really appreciate the work of the authors in providing it. I have found a couple of problems in the text, as follows: On page 4 in section 4, it seems that >>> vector1 = array((1,2,4,5)) should be the following instead: >>> vector1 = array((1,2,3,4,5)) On page 48 in section 8, the translation table used in the "brightening" function acts instead to darken the image. I found that scaling proportional to a square-root function worked well: table = (arange(256)**.5 * (255**.5)).astype('b') One side note: I'm surprised that the coordinate system used by the NumTut.view function has X axis values increasing to the left. Is that standard for some graphing systems? I've never worked with such a system before. Or am I misunderstanding what I'm seeing with view? I'm basing this on inspection of view(arange(100)**2)) and view(arange(100)**.5). -- Fred Yankowski fred at OntoSys.com tel: +1.630.879.1312 Principal Consultant www.OntoSys.com fax: +1.630.879.1370 OntoSys, Inc 38W242 Deerpath Rd, Batavia, IL 60510, USA From cbarker at jps.net Thu Oct 19 17:13:26 2000 From: cbarker at jps.net (Chris Barker) Date: Thu, 19 Oct 2000 14:13:26 -0700 Subject: [Numpy-discussion] PyArray_Check problem. References: <004a01c037ee$964dd040$0200a8c0@home> <39EE3D2C.51A92A71@jps.net> <200010191725.TAA14895@chinon.cnrs-orleans.fr> Message-ID: <39EF63F6.B72C3853@jps.net> Konrad Hinsen wrote: > > site = PyList_GetItem(spam_list, index); > > > > if (! PyArray_Check(spam)) result = 0; > ^^^^ > > Not "site"? oops! I thought I had Pythonized everything by putting spam everywhere. > If spam is NULL, then the check will crash. If it is anything but a pointer > to a Python object, there's a good chance that it might crash. > PyArray_Check just tells you if a given Python object is of type "array". Fair enough. In this case, I was getting spam from a Python list. Is it possible for it to be anything but a pointer to a Python object? > A look at the value of "spam" with a debugger should tell you what's > going on. I have not yet figured out how to use a de-bugger with a python extension. Does anyone know of any nifty tutorial for how to do this (with gdb, preferably)? note that I'm a newby to C too, so I need a really basic run through. > > spam = (PyArrayObject *) PyList_GetItem(spam_list, index); > > > > Should I be doing this, and should PyArray_Check(spam) work either way? > > It works either way, but I am not sure that you are supposed to rely > on that. I prefer to use a cast to array objects only *after* > verifying that I have an array object, if only for clarity. That sounds like sound advice. I do feel like I'm doing something wrong if I get a warning form the compiler however. Thanks for your help. -Chris -- Christopher Barker, Ph.D. cbarker at jps.net --- --- --- http://www.jps.net/cbarker -----@@ -----@@ -----@@ ------@@@ ------@@@ ------@@@ Water Resources Engineering ------ @ ------ @ ------ @ Coastal and Fluvial Hydrodynamics ------- --------- -------- ------------------------------------------------------------------------ ------------------------------------------------------------------------ From hinsen at cnrs-orleans.fr Fri Oct 20 09:08:40 2000 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Fri, 20 Oct 2000 15:08:40 +0200 Subject: [Numpy-discussion] PyArray_Check problem. In-Reply-To: <39EF63F6.B72C3853@jps.net> (message from Chris Barker on Thu, 19 Oct 2000 14:13:26 -0700) References: <004a01c037ee$964dd040$0200a8c0@home> <39EE3D2C.51A92A71@jps.net> <200010191725.TAA14895@chinon.cnrs-orleans.fr> <39EF63F6.B72C3853@jps.net> Message-ID: <200010201308.PAA15794@chinon.cnrs-orleans.fr> > > A look at the value of "spam" with a debugger should tell you what's > > going on. > > I have not yet figured out how to use a de-bugger with a python > extension. Does anyone know of any nifty tutorial for how to do this > (with gdb, preferably)? note that I'm a newby to C too, so I need a > really basic run through. I used gdb with gcc under Linux, and I just use it as I would on any other program: gdb /usr/bin/python run spam.py and wait for the crash. Of course your module should have been compiled with -g if you want symbolic debugging. The only difficulty with debugging extension modules built as dynamic libraries is setting breakpoints. You can't do it right away because the module isn't loaded yet, so its symbols are unknown to gdb. My solution is to start my script with the import, followed immediately by "time.sleep(5)". That gives me five seconds to press Control-C to reenter the debugger, and from then on everything works as advertised. If someone knows a more elegant solution, please let me know! Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen at cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From lull at acm.org Sat Oct 21 11:59:20 2000 From: lull at acm.org (John Lull) Date: Sat, 21 Oct 2000 08:59:20 -0700 Subject: [Numpy-discussion] COM/Numeric incompatibility Message-ID: <79c3vs8bnevekqnesha986tukshcbqsol3@4ax.com> (Also posted to comp.lang.python) (Addendum -- Mark Hammond suggests this may be a threading issue -- OpenDatabase() apparently causes Python threads to be initialized. Does NumPy or lapack lite use threads for anything?) I'm working on a Windows application that needs to use both Microsoft DAO and Numeric, & have run into a problem between the two. The following code illustrates the problem: from win32com.client import Dispatch engine = Dispatch("DAO.DBEngine.35") db = engine.OpenDatabase('c:\\test.mdb') from Numeric import array m = array([[1., 2.], [3., 4.]]) y = array([2., 1.]) from LinearAlgebra import linear_least_squares print linear_least_squares(m, y) print 'success!' The problem is that the statement 'print linear_...' never completes. I step through in the debugger under pythonwin, & the lapack routine called by linear_least_squares() never returns. If I remove the statement 'db = engine...' it completes normally. If I make a call to linear_least_squares() *before* the database stuff, the later call to linear_least_squares() works properly. test.mdb is an empty database created by Access 97. Using another database seems to make no difference. I am using: Python 1.52 win32all-132 NumPy 16.1 All are standard distribution builds. OS is Win98SE. DAO.DBEngine.35 resolves to DAO350.dll, dated 4/27/98. That, in turn (I believe) is using msJet35.dll dated 4/23/99. Any ideas? Thanks. Regards, John From hinsen at cnrs-orleans.fr Mon Oct 23 12:09:41 2000 From: hinsen at cnrs-orleans.fr (Konrad Hinsen) Date: Mon, 23 Oct 2000 18:09:41 +0200 Subject: [Numpy-discussion] COM/Numeric incompatibility In-Reply-To: <79c3vs8bnevekqnesha986tukshcbqsol3@4ax.com> (message from John Lull on Sat, 21 Oct 2000 08:59:20 -0700) References: <79c3vs8bnevekqnesha986tukshcbqsol3@4ax.com> Message-ID: <200010231609.SAA19661@chinon.cnrs-orleans.fr> > (Addendum -- Mark Hammond suggests this may be a threading issue -- > OpenDatabase() apparently causes Python threads to be initialized. > Does NumPy or lapack lite use threads for anything?) No. > The problem is that the statement 'print linear_...' never completes. > I step through in the debugger under pythonwin, & the lapack routine > called by linear_least_squares() never returns. > > If I remove the statement 'db = engine...' it completes normally. > > If I make a call to linear_least_squares() *before* the database > stuff, the later call to linear_least_squares() works properly. I don't know how dynamic libraries work under Windows, but I could imagine that your database modules uses a symbol which is also used in Linpack or the Linpack/Python interface. There ought to be tools to verify this. Konrad. -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen at cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From johannes at zellner.org Tue Oct 24 13:04:12 2000 From: johannes at zellner.org (Johannes Zellner) Date: Tue, 24 Oct 2000 19:04:12 +0200 Subject: [Numpy-discussion] cvs modules Message-ID: <20001024190412.A19072@zellner.org> Hello, there are three modules Numerical numpy numpy2 in the cvs repository. Could someone explain the differences please ? -- Johannes From jhauser at ifm.uni-kiel.de Sat Oct 28 12:26:30 2000 From: jhauser at ifm.uni-kiel.de (Janko Hauser) Date: Sat, 28 Oct 2000 18:26:30 +0200 (CEST) Subject: [Numpy-discussion] Save use of savespace?! Message-ID: <20001028162630.30251.qmail@lisboa.ifm.uni-kiel.de> Hello, a question in the newsgroup got me thinking about the save use of the ``savespace'' flag in modules, which should be used by third party code. Think of this function as an example: def freezing(S,P): """Returns the freezing point temperature of seawater with a salinity S and at a pressure P. """ TF=(-.0575+1.710523e-3*_A.sqrt(_A.absolute(S))-2.154996e-4*S)*S-7.53e-4*P return TF This looks simple and one wants to use the savespace flag for S and P. So now the questions are rolling. What if S or P are scalars? Use asarray with the savespace flag. -> Error, this returns a copy of the array and not a reference, which is bad for array arguments. So use first asarray and then do asarray(S).savespace(1). Ok this works for the function, but we need to reset the flag at the end of the function. Also bad, what if S or P had the flag set before they entered the function? Ok I have now build a class, which actually keeps a record of these flags and has some helper methods to handle this record. The example function looks now: def freezing(S,P): SP=mkspacesaver(S,P) if not SP.isfloat(): raise ValueError, 'Arguments need to be of some float type' TF=(-.0575+1.710523e-3*_A.sqrt(_A.absolute(S))-2.154996e-4*S)*S-7.53e-4*P SP.free(); SP.clean(TF) return TF Note the test for float type, because if the user lazily entered an integer array for e.g. the pressure, the then set savespace flag would result in a very wrong answer. Although this seems to work for me, I do not know if this really presents a solution, as I actually need to put these lines into every similar function. The other way, to put the coeff. into an array has also problems, as I first need to find out of which type all arguments are and choose the highest one and it makes it more difficult to follow the coeff. in the formula. Any other suggestions, more general ways to handle argument testing? Is the savespace flag only suited for more closed environments, where one can assume more about the arguments? Class attached, __Janko class mkspacesaver: def __init__(self, *args): """Set for all arguments the savespace flag and make them to arrays. Keep track of this. At the end of the function, all flags can be reset, by a call to the method .free() """ self.refs = [] self.flags= [] for arg in args: try: arg.spacesaver() ref = arg except AttributeError: ref = afuncs.asarray(arg) self.flags.append(ref.spacesaver()) ref.savespace(1) self.refs.append(ref) def isfloat(self, index=None): """ Test if all refs have a float type, if a sequence is given for index, only the indexed refs are tested. """ if index: for i in index: if not self.refs[i].typecode() in ('f','d'): return 0 else: for i in range(len(self.refs)): if not self.refs[i].typecode() in ('f','d'): return 0 return 1 def free(self): for i in range(len(self.refs)): self.refs[i].savespace(self.flags[i]) def clean(self, *args): """Test if the arguments have the savespace flag set and set it to zero. Handle also scalars """ for arg in args: try: arg.savespace(0) except AttributeError: pass From gvermeul at labs.polycnrs-gre.fr Sun Oct 29 04:27:27 2000 From: gvermeul at labs.polycnrs-gre.fr (Gerard Vermeulen (CRTBT)) Date: Sun, 29 Oct 2000 10:27:27 +0100 Subject: [Numpy-discussion] Legal Notice Message-ID: <39FBED7F.CC3C5FE3@labs.polycnrs-gre.fr> I like to propose a numpy-RPM to MandrakeSoft for future inclusion in their contrib-cdroms. Of course, MandrakeSoft requires that all license issues are cleared. I understand that the file Legal.htm applies to the packages MA and RNG. Is this true? I like to point out that the phrase "Permission to use, copy, modify, and distribute this software for any purpose without fee is hereby granted, provided that this entire notice is included in all copies of any software which is or includes a copy or modification of this software and in all copies of the supporting documentation for such software. " is very restrictive. It forbids the inclusion of MA and RNG on a commercial CD rom. Isn't it? It also forbids a consultant to use it for his business. But what about somebody getting paid for his work in a government research laboratory? Could you replace this by something more BSD-like? Best regards -- Gerard Vermeulen From bernd at bpc.uni-frankfurt.de Mon Oct 30 08:34:48 2000 From: bernd at bpc.uni-frankfurt.de (Bernd Weyrauch) Date: Mon, 30 Oct 2000 14:34:48 +0100 Subject: [Numpy-discussion] Numeric-17.1.1 on IRIX 6.3 Message-ID: <00103014382805.04682@mephisto.bpc.uni-frankfurt.de> Hi, I tried to install Numeric-17.1.1 under IRIX 6.3 after installing Python 2.0 without optimization and the -g workaround. I got this error message: # /usr/local/bin/python setup.py install running install running build running build_py not copying Lib/ArrayPrinter.py (output up-to-date) not copying Lib/Numeric.py (output up-to-date) not copying Lib/Precision.py (output up-to-date) not copying Lib/UserArray.py (output up-to-date) not copying Lib/numeric_version.py (output up-to-date) running build_ext building '_numpy' extension skipping Src/_numpymodule.c (build/temp.irix-6.3-2.0/Src/_numpymodule.o up-to-date) skipping Src/arrayobject.c (build/temp.irix-6.3-2.0/Src/arrayobject.o up-to-date) skipping Src/ufuncobject.c (build/temp.irix-6.3-2.0/Src/ufuncobject.o up-to-date) ld -shared -all build/temp.irix-6.3-2.0/Src/_numpymodule.o build/temp.irix-6.3-2.0/Src/arrayobject.o build/temp.irix-6.3-2.0/Src/ufuncobject.o -o build/lib.irix-6.3-2.0/_numpy.so ld: ERROR 48: Cannot access registry file ./so_locations (No locks available) - ignored. ld: FATAL 51: Can't assign virtual addresses for _numpy.so within specified range. Please check your registry file ./so_locations. error: command 'ld' failed with exit status 4 Has anybody else encountered this problem? Thanks a lot! Bernd -- Bernd Weyrauch Marie-Curie-Str. 9 D-60439 Frankfurt am Main Institute of Biophysical Chemistry Tel. +49-(0)69-798-296-72 Frankfurt J. W. Goethe University Fax +49-(0)69-798-296-32 Biocenter, N230 e-mail bernd at bpc.uni-frankfurt.de http://www.biozentrum.uni-frankfurt.de/~bernd http://www.cthulhu.onlinehome.de From jh at oobleck.tn.cornell.edu Tue Oct 31 12:34:44 2000 From: jh at oobleck.tn.cornell.edu (Joe Harrington) Date: Tue, 31 Oct 2000 12:34:44 -0500 Subject: [Numpy-discussion] Re: Legal Notice (Gerard Vermeulen (CRTBT)) In-Reply-To: <200010292025.e9TKPKu14427@lists.sourceforge.net> (numpy-discussion-request@lists.sourceforge.net) References: <200010292025.e9TKPKu14427@lists.sourceforge.net> Message-ID: <200010311734.MAA19660@oobleck.tn.cornell.edu> Gerard, Could you explain why you think that the phrase you quoted is restrictive? Lots of software comes with that phrase, and it certainly hasn't inhibited its wide promulgation. All it says is that you can't pass off this software as your own, which would be lying anyway. As far as I can tell (I'm not a lawyer, etc.), it's far less restrictive than, say, GPL. It seems very like the BSD license you suggest using instead. If you include the packages in a larger work, you can just say: This work includes the blah blah package, which bears the following license: "Permission to use, copy, modify, and distribute this software for any purpose without fee is hereby granted, provided that this entire notice is included in all copies of any software which is or includes a copy or modification of this software and in all copies of the supporting documentation for such software. " Note that the notice *doesn't* say you have to *copyright* the larger package under the terms of the notice or to the owner of the included package, it just says you have to include the notice, presumably so the recipient knows that the package is in there, who the owner of that component is, and that distributing that part is allowed. If you look at the manuals to most commercial Unices, you'll find several pages of such notices from the owners of the various packages included in the system. What's the problem? --jh-- From pauldubois at home.com Tue Oct 31 17:58:05 2000 From: pauldubois at home.com (Paul F. Dubois) Date: Tue, 31 Oct 2000 14:58:05 -0800 Subject: [Numpy-discussion] Windows zip of Numerical Python 17.1.1 available Message-ID: Numerical 17.1.1 is available in both source and prebuilt Windows versions at: http://sourceforge.net/projects/numpy Windows users, simply extract into your top level Python 2.0 directory, typically c:\python20. Thank you to Pete Shinners for putting the Windows file together. It is too late to change for the 17 series but in future I will make releases that have whole numbers only as names and add files to that release as they become available. That makes it a little clearer that you should take the most recent file of the desired type. From gball at cfa.harvard.edu Tue Oct 31 18:31:57 2000 From: gball at cfa.harvard.edu (Greg Ball) Date: Tue, 31 Oct 2000 18:31:57 -0500 (EST) Subject: [Numpy-discussion] Re: Legal Notice In-Reply-To: <200010312134.e9VLY5u23517@lists.sourceforge.net> Message-ID: I think the way Gerard is interpreting this passage > Permission to use, copy, modify, and distribute this software and its > documentation for any purpose and without fee is hereby granted, is that you can DISTRIBUTE the software but you can't CHARGE A FEE. However this appears in the normal python license and many others and I am sure the correct interpretation is that you can USE, DISTRIBUTE, etc the software without PAYING A FEE (to the copyright holders.) It is free software, a XFree86 style license according to RMS, which is BSD-like but with no advertising clause. Gerard, the license is fine for distribution and as Joe said, similar to many other free software packages. -Greg Ball