numerical models and numpy
I'm a little worried that you all may be assuming that I'm keeping up with this flood of stuff on python-dev about the numerical model. I have tried but I just can't manage that much volume. My silence doesn't mean approval. Whatever "native" types you decide on there will be considerable pressure on us to include corresponding types in Numerical Python, but I don't think that can happen. At the moment there seem to be few people with any time to spare to help me. I won't be able to do such work myself as my job just has no use for decimals, rationals, etc. My community would like a native Python type corresponding to a C float (and a corresponding complex made out of two floats). Numpy already has those. I was considering just hacking the source file for the native Python type corresponding to a C double -- until I looked at it. What a complicated beast it is. I have room in my draft implementation of PEP 242 for the beast and I was going to do it in there. To those of you thinking about this that haven't read PEP 242, please do so. The Fortran committee thought hard about these issues and concluded that some numeric "types" are not really different types but different "kinds" of the same basic type. -- Paul
I'm a little worried that you all may be assuming that I'm keeping up with this flood of stuff on python-dev about the numerical model. I have tried but I just can't manage that much volume. My silence doesn't mean approval.
Whatever "native" types you decide on there will be considerable pressure on us to include corresponding types in Numerical Python, but I don't think that can happen. At the moment there seem to be few people with any time to spare to help me. I won't be able to do such work myself as my job just has no use for decimals, rationals, etc.
My community would like a native Python type corresponding to a C float (and a corresponding complex made out of two floats). Numpy already has those. I was considering just hacking the source file for the native Python type corresponding to a C double -- until I looked at it. What a complicated beast it is. I have room in my draft implementation of PEP 242 for the beast and I was going to do it in there.
I have read your PEP and see it as a way to provide control over very different aspects of numbers. I expect that most of it is motivated out of a desire to control the range, size and accuracy of floating point more precisely, *and* to have scalar types matching the NumPy types. I think we can give you what you want for float and complex, because I have no great plans to change those (a decimal type might be added, but we can't remove binary floats). I'm nor sure if you really need various width integer types once the native Python integer uses unbounded precision (the int/long unification).
To those of you thinking about this that haven't read PEP 242, please do so. The Fortran committee thought hard about these issues and concluded that some numeric "types" are not really different types but different "kinds" of the same basic type.
Yeah, but Python is not Fortran, and programmer needs do differ. I do like the terminological distinction, it allows us to talk with more clarity about these aspects of our numbers! --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (2)
-
Guido van Rossum
-
Paul F. Dubois