We had put off consideration of PEP 242 Numeric kinds until June 2002 when a meeting of some interested parties was to occur but the meeting didn't occur. I have a draft implementation and users of it but my feeling is that although correct and useful the PEP is not useful enough to put it in the standard library. Since it really only interests scientific programmers I propose simply making it a separate deliverable on the Numeric site and withdrawing the PEP.
On Thu, Dec 05, 2002 at 05:02:26PM -0800, Paul F Dubois wrote:
Since it really only interests scientific programmers I propose simply making it a separate deliverable on the Numeric site and withdrawing the PEP.
I'm not fully aware about the advantages/implications of puting Numeric in Python standard library, but to say that the manipulation of numeric arrays is only of interest to scientific programmers is the same of when in the early computing days engineers saing that computers would only be good for crunching numbers, and that the concept of personal computers was just non-sense...
For a non-scientic usage of Numeric see the examples in http://www.pygame.org/pcr/repository.php, but I can imagine the usefullness of Numeric in many more non-scientific applications: imaging, sound visualization plugins, 3D graphics, and probably much more.
The use of Numeric can speed up alot of algorithms which would be otherwise very slow in pure Python, and therefore forcing one to write C extensions. That's why IMHO something with the Numeric functionality should exist in the Python standard library.
Note that this is not the same that saying that Numeric should be included as is - perhaps it's better to have it seperately to let it mature more, perhaps not - but still, there is much more than a niche interest around it.
José Fonseca __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
José Fonseca wrote:
to say that the manipulation of numeric arrays is only of interest to scientific programmers is the same of when in the early computing days engineers saing that computers would only be good for crunching numbers, and that the concept of personal computers was just non-sense...
I absolutely concur.
For a non-scientic usage of Numeric see the examples in http://www.pygame.org/pcr/repository.php, but I can imagine the usefullness of Numeric in many more non-scientific applications: imaging, sound visualization plugins, 3D graphics, and probably much more.
It goes MUCH farther than this. All these examples are what I would call serious number crunching. Perhaps not strictly scientific, but certainly the realm of numeric programming, and all places where the "kinds" concept would be useful.
However, there is a great deal of usefulness in Numeric for applications that are not doing a lot of number crunching. Performance is only one reason to use Numeric. The other reason is much cleaner and easier syntax for manipulating arrays of numbers, especially ones of more than one dimension. Being able to slice across multiple dimensions, array oriented arithmetic, overloaded comparisons, etc. I use Numeric for virtually every program I write, whether performance is an issue or not. Not having to write all those ugly, confusing and error prone loops is a godsend.
All that being said, the "kinds" concept is probably mostly of concern to the Number crunching community. However, it is also sort of a low level concept, and having it part of core language makes sense, just like it makes sense to have complex number and long integers in the core language.
-Chris
I have a draft implementation and users of it but my feeling is that although correct and useful the PEP is not useful enough to put it in the standard library. Since it really only interests scientific programmers I propose simply making it a separate deliverable on the Numeric site and withdrawing the PEP.
As the PEP author, your feeling is probably the most accurate. And, it is true that Kinds will, in general, appeal to the same crowd as Numeric.
OTOH, "import kinds" is entirely unobtrusive and general purpose. The interface is simple; and may help some code become less platform sensitive (in the way the Metafont writes its own portable routines to create consistent lettering); and it has some educational value (making it easy to demonstrate the effects of truncation and floating point round-off).
Also, I think accounting applications can benefit from having some positive assurance that multi-billion dollar calculations don't lose their pennies and that the books will still balance.
So, the only downside is having an additional block of code to maintain. My vote is for adding it to the standard library. Control over precision is more of a core capability than it is an extension, but, as the PEP author and principal user, you probably know best.
'nuff said,
Raymond Hettinger
################################################################# ################################################################# ################################################################# ##### ##### ##### ################################################################# ################################################################# #################################################################
[Paul F Dubois]
We had put off consideration of PEP 242 Numeric kinds until June 2002 when a meeting of some interested parties was to occur but the meeting didn't occur. I have a draft implementation and users of it but my feeling is that although correct and useful the PEP is not useful enough to put it in the standard library. Since it really only interests scientific programmers I propose simply making it a separate deliverable on the Numeric site and withdrawing the PEP.
I say add it. If there are already users out there then that demonstrates as least some form of a demand.
Besides, if rationals can get into the library (that module was finally accepted to be added to the library, right?) then a module to help do consistent decimal math should at least be included at least until the Python core can move to C99 (if I am remembering a comment from Tim saying that C99 adds more explicit numeric types, e.g., exactly 2 byte float).
I just want to be able to add up a bunch of money values and not have a few pennies disappear in the end; usually I am the one who has to eat the loss and I am an poor college graduate who can't afford the rounding. =)
-Brett
On Friday 06 December 2002 02:12 am, Brett Cannon wrote:
[Paul F Dubois]
We had put off consideration of PEP 242 Numeric kinds until June 2002 when a meeting of some interested parties was to occur but the meeting didn't occur.
[...]
I just want to be able to add up a bunch of money values and not have a few pennies disappear in the end; usually I am the one who has to eat the loss and I am an poor college graduate who can't afford the rounding. =)
Does the kinds implementation work with binary floats and decimal numbers?
From a quick scan of the PEP it looks like it is only binary floats. If it
only applies to binary numbers then the kinds capability will not eliminate decimal number rounding errors. That problem will require extending Python to include a decimal number type.
The abstract mentions a clarification of decimal literals, but I suspect Paul was not suggesting that the numbers defined by kinds will use decimal arithmetic instead of binary arithmetic.
Hi all,
I just stumbled upon this paper by William Kahan, a Professor at Berkeley that is well known for his work on the first Intel math co-processor, and the development of IEE 754 (plus a lot of other stuff). I took a course with him at Berkeley, and the man is brilliant. So brilliant that is is very hard to follow him, as a student, if you are not so sharp. I'm not, and I just squeeked by and missed a great deal of what he tried to teach. I did gain a good appreciation of the complexity of floating point arithmetic, however. Here is the paper as a PDF:
http://www.cs.berkeley.edu/%7ewkahan/MgtkMath.pdf
There's a lot of other good stuff on his web page at:
http://www.cs.berkeley.edu/%7ewkahan/
THe paper is entitled "Marketing versus Mathematics". In particular, take a look at the section on Quattro Pro on Page 13, for a nice discussion of binary arithmetic displayed as decimal, which is an often brought up subject in the Python newsgroups. He discusses how you'd really have to display more than the 15 digits that Quattro displayed, to avoid confusion.
""" But no such cure can be liberated from little annoyances: 0.8 entered would display as 0.80000000000000004 to 17 sig. dec.; """ At the Python prompt:
0.8
0.80000000000000004
More evidence that the current Python way is "best", if confusing to newbies. This would be another good paper to point people towards that ask about floating point on the newsgroups.
-Chris
Hi all,
Does anyone here use Konrad Hinsen's NetCDF module? I'm having a problem with it.
I opened an existing NetCDF file and examine one of it's variables:
file = NetCDF.NetCDFFile("test.cdf")
file.variables['water_u'].typecode()
'f'
The variable appears to contain float data (which I think it does). However, when I try to get a slice of that data:
array([3199453293L, 3198428385L], 'u')
Numeric appears to think it's an unsigned 32 bit integer variable. I get the same result if I use file.getValue() as well.
Could this be a Numeric version mismatch? I couldn't find a recommended version of Numeric on the Scientific site.
RedHat Linux 7.2 Python2.2.1 Numeric 22.0
I've enclosed my test.cdf file, if you want to test it yourself.
Anyone have any ideas?
-Chris
participants (6)
-
Brett Cannon -
Chris Barker -
José Fonseca -
Michael McLay -
Paul F Dubois -
Raymond Hettinger