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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4