Mailman 3 November 2000 - Python-Dev

Revamping Python's Numeric Model
by Martin v. Loewis Nov. 6, 2000

Nov. 6, 2000

> Is there some API for it in C? In C99, you have access to the floating-point environment: #include <fenv.h> /* ... */ { #pragma STDC FENV_ACCESS ON int set_excepts; feclearexcept(FE_INEXACT | FE_OVERFLOW); // maybe raise exceptions set_excepts = fetestexcept(FE_INEXACT | FE_OVERFLOW); if (set_excepts &… [View More]

1 0

Re: [Python-Dev] Revamping Python's Numeric Model
by Moshe Zadka Nov. 6, 2000

Nov. 6, 2000

[GvR] > So I go offline for a couple of days to entertain guests and have my > body kicked around in a dance class, and I have 25 messages discussing > Python's numeric model waiting for me... I think the solution is obvious -- stop going offline to entertain guests. [GvR] > I was hoping that Tim would chime in Me too. I even tried to drag him in by mentioning 754. [GvR] > I like the idea of a PEP to rework the numeric model. I think that > Moshe, being a mathematician by … [View More]training, will make a good editor. I > think that this has a snowball's chance in hell to make it into Python > 2.1 however -- there are many deep issues, and it's a bad idea to > experiment too much in the released version of the language. The reason the PEP was written now was because you started making sounds of causing 1/2 to be 0.5, which is dangerous. I tried to outline the PEP to show a less dangerous (and less innovative) way of getting similar usability. [GvR] > (1) As long as the internal representation is not the same as what is > commonly printed, there will be surprises -- with rationals just > as much as with floating point. There are issues with decimal > floating point too, but they are only the issues having to do with > loss of precision in the calculation (e.g. 1.0 - 1e-20 yielding > 1.0) and not with loss of precision in the printing, where most of > the "bug reports" we get seem to concentrate. My PEP does not yet deal with either written or inputted representation. [GvR] > (2) Rational numbers have the unpleasant property of growing > unboundedly during many innocent calculations, thereby using up > exorbitant amounts of memory and slowing down the calculation -- > often mysteriously, because what is displayed is truncated. Those calculations, if performed with floating points, would often build up inaccuracy. I prefer to go slow+memory hog (which the user feels), then to be wildly inaccurate. [GvR] > Another issue that I might bring up is that there are no inexact > numbers (each floating point number is perfectly exact and rational) You'll note that my PEP does not mention floating point explicitly -- and once again I mention that my PEP does not yet deal with number literals. All it allows (not requires) is for things like math.sqrt() to return inexact results. Naive implementations (which we might use) would make math.sqrt(1) an *inexact* 1, tentatively called 1.0. Of course, good implementations of math.sqrt() would realize that 1 has an exact root, but that might be too hard to do for not enough gain. [GvR] > If we take its meaning literally, the isreal() function should only > return true for numbers for which isrational() is also true: Correct -- in my current model. If you later add things like constructive reals, that is no longer true: if I have a constructive Pi, it's not rational. [GvR] > mathematically speaking, real numbers that aren't also rational don't > have an easy finite representation, since they are numbers like > sqrt(2) or pi. But numbers don't have to have a finite (periodic really) representation to be representable in the computer: what about infinite continued fractions, for example? [GvR] > Finally, the PEP doesn't talk about how the numeric model can be > extended That's because its rich enough not to need it. Let me explain exactly what I mean: as long as all field operations between Python numbers give honest to god Python numbers, then everything else can be solved with Python's current model of coercions, and can be solved well when the coercion PEP will be written. [GvR] > I've > heard of wild floating point representations that make multiplication > and division really cheap but addition a pain, rather than the other > way around; Well, no problems: write wild.inexact() and wildmath.{sqrt,...} and use that instead of inexact() and math.{...}. How these numbers interact with builtin Python numbers is your responsibility -- and that's what the coercions are for. Same goes for gmp: as long as you're not expecting to be able to change 10000000000+10000000000 to be a gmp long rather then a Python long, then there shouldn't be a problem. -- Moshe Zadka <sig(a)zadka.site.co.il> [View Less]

3 3

cgi.py and huge uploads problem
by Christian Tismer Nov. 6, 2000

Nov. 6, 2000

Howdy, there is a problem with the cgi.py implementation of Python 1.5.2 and uploading of huge files. (found out by Joachim Rudolph, Virtual Photonics) Class FieldStorage of cgi.py has a couple of methods which add accumulated lines to a self.lines array. This array fills and fills until the whole upload is done, with the side effect of loading the whole file into memory. The memory is freed after the whole upload is done. This is no problem, until a company like VPI uses cgi.py to upload … [View More]

3 3

Re: [Python-checkins] CVS: python/nondist/peps pep-0228.txt,NONE,1.1 pep-0000.txt,1.44,1.45
by Thomas Wouters Nov. 6, 2000

Nov. 6, 2000

On Sun, Nov 05, 2000 at 08:55:27AM -0800, Moshe Zadka wrote: > Added Files: > pep-0228.txt > Log Message: > Added first revision of numerical model pep. > ***** Error reading new file: (2, 'No such file or directory') > ***** file: pep-0228.txt cwd: /tmp/cvs-serv13461 Thank you, Moshe ;) Now to figure out why it does work for some people, or in some cases ;P I'm guessing it's a race condition of some sort, but damned if I know what triggers it. -- Thomas Wouters <… [View More]

3 4

Revamping Python's Numeric Model
by Moshe Zadka Nov. 6, 2000

Nov. 6, 2000

Here's a draft PEP. Have I already mentioned how much it irks me to cater for other editors in the PEP text itself? PEP: Unassigned Title: Reworking Python's Numeric Model Version: $Revision$ Author: pep(a)zadka.site.co.il (Moshe Zadka) Status: Draft Type: Standards Track Created: 4-Nov-2000 Post-History: Abstract Today, Python's numerical model is similar to the C numeric model: there are several unrelated numerical types, and when operations between numerical types are … [View More]requested, coercions happen. While the C rational for the numerical model is that it is very similar to what happens on the hardware level, that rational does not apply to Python. So, while it is acceptable to C programmers that 2/3 == 0, it is very surprising to Python programmers. Rationale In usability studies, one of Python hardest to learn features was the fact integer division returns the floor of the division. This makes it hard to program correctly, requiring casts to float() in various parts through the code. Python numerical model stems from C, while an easier numerical model would stem from the mathematical understanding of numbers. Other Numerical Models Perl's numerical model is that there is one type of numbers -- floating point numbers. While it is consistent and superficially non-suprising, it tends to have subtle gotchas. One of these is that printing numbers is very tricky, and requires correct rounding. In Perl, there is also a mode where all numbers are integers. This mode also has its share of problems, which arise from the fact that there is not even an approximate way of dividing numbers and getting meaningful answers. Suggested Interface For Python Numerical Model While coercion rules will remain for add-on types and classes, the built in type system will have exactly one Python type -- a number. There are several things which can be considered "number methods": 1. isnatural() 2. isintegral() 3. isrational() 4. isreal() 5. iscomplex() a. isexact() Obviously, a number which answers m as true, also answers m+k as true. If "isexact()" is not true, then any answer might be wrong. (But not horribly wrong: it's close the truth). Now, there is two thing the models promises for the field operations (+, -, /, *): If both operands satisfy isexact(), the result satisfies isexact() All field rules are true, except that for not-isexact() numbers, they might be only approximately true. There is one important operation, inexact() which takes a number and returns an inexact number which is a good approximation. Several of the classical Python operations will return exact numbers when given inexact numbers: e.g, int(). Inexact Operations The functions in the "math" module will be allowed to return inexact results for exact values. However, they will never return a non-real number. The functions in the "cmath" module will return the correct mathematicl result. Numerical Python Issues People using Numerical Python do that for high-performance vector operations. Therefore, NumPy should keep it's hardware based numeric model. Copyright This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil End: -- Moshe Zadka <sig(a)zadka.site.co.il> [View Less]

6 5

Re: Revamping Python's Numeric Model
by Moshe Zadka Nov. 6, 2000

Nov. 6, 2000

[Martin v. Loewis] > Remind you that your model has no notion of floating-point numbers - > then what the heck are floating-point literals? The numbers that you > can write in a base-10 notation are all rational numbers, and the > point doesn't really float in them... Well, of course they are rational numbers. The only question is whether 1.0 should be inexact or exact. While that is not specified in the PEP (which was meant for Barry to assign me a PEP number primarily...), I … [View More]

4 3

Three argument slices.
by bckfnn＠worldonline.dk Nov. 6, 2000

Nov. 6, 2000

Hi, While updating the difference page in the Jython documentation, I came across this: - JPython sequences support three argument slices. i.e. range(3)[::-1] == [2,1,0]. CPython should be fixed. Is this actually true? Should (and will cpython) change in this respect? regards, finn

2 1

Re: Revamping Python's Numeric Model
by Moshe Zadka Nov. 5, 2000

Nov. 5, 2000

[Martin v. Loewis] > It's not inherently wrong. It just points out an omission in the PEP: > it doesn't talk about the meaning of number literals. That's right -- but I did mean that floating-point literals will be inexact. > Since the new > model is going to follow algebraic principles more closely, I had > expected that > > 0.333333333 == 333333333 / 1000000000 > > where, as I understand the proposal, the right-hand side is an exact > number (so 0.333333333*… [View More]

2 1

Re: [Python-Dev] Revamping Python's Numeric Model
by Moshe Zadka Nov. 4, 2000

Nov. 4, 2000

> Hmm, I like almost everything about your proposal. The above point > bothers me slightly. Are you saying (1.0).isexact() == 0? Yes. 1.0 is not an exact number. What's wrong with that? (Consider stuff like 0.333333333*3: this shouldn't be exact!) > Also, how about long integers? Will they, under your new proposal, be > indistinguisable from regular ints? Yes. > While this has some appeal to it > it would be problematic for C extension modules. I haven't mentioned … [View More]

1 0

Accessing RH 7.0 on SF?
by Skip Montanaro Nov. 4, 2000

Nov. 4, 2000

Someone posted a bug about the bsddb config stuff related to RH7.0, which I don't have direct access to. I've seen others access different Linux dialects on the SF site. Can someone explain how I can access RH7.0 there? All I really need to do at the moment is peruse the /usr/include/db3 stuff. Thx, Skip

2 1