> > The lack of commutativity wasn't in precision, it was in the typecodes, and > was there from the beginning. That caused confusion. A current cause of > confusion is the many to one relation of, say, int32 and long, longlong which > varies platform to platform. I think that confusion is a more significant > problem. Having some types derived from Python types, a correspondence that > also varies platform to platform is another source of inconsistent behavior > that can be > confusing. So there are still plenty of issues to deal with
I didn't think it was in the precision. I knew what you meant. However, I'm still hoping for an example of what you mean by "lack of commutativity in the typecodes". The confusion of long and longlong varying from platform to platform comes from C. The whole point of having long and longlong is to ensure that you can specify the same types in Python that you would in C. They should not be used if you don't care about that. Deriving from Python types for some array-scalars is an issue. I don't like that either. However, Python itself special-cases it's scalars in ways that necessitated it to have some use-cases not fall-over. This shows a limitation of Python. I would prefer that all array-scalars were recognized appropriately by the Python type system. Most of the concerns that you mention here are mis-understandings. Maybe there are solutions that "fix" the problem without just educating people. I am open to them. I do think that it was a mistake to have the intp and uintp dtypes as *separate* dtypes. They should have just mapped to the right one. I think it was also a mistake to have dtypes for all the C-spellings instead of just a dtype for each different bit-length with an alias for the C-spellings. We should change that in NumPy 2.0. -Travis > > I'd like to point out that the addition of float16 necessitated a certain > amount of rewriting, as well as the addition of datetime. It was only through > Mark's work that we were able to include the latter in the 1.* series at all. > Before, we always had to remove datetime before a release, a royal PITA, > while waiting on the ever receding 2.0. So there were very good reasons to > deal with the type system. > > That isn't to say that typecasting can't use some tweaks here and there, I > think we are all open to discussion along those lines. But it should about > specific cases. > > Chuck > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
