>> At a minimum, this inconsistency needs to be cleared up. My >> preference >> would be that the programmer should have to explicitly downcast from >> complex to float, and that if he/she fails to do this, that an >> exception be >> triggered. > > That would most likely break a *lot* of deployed code that depends on > the implicit downcast behaviour. A less harmful solution (if a > solution is warranted, which is for the Council of the Elders to > decide) would be to treat the Python complex type as a special case, > so that the .real attribute is accessed instead of trying to cast to > float.
Except that the exception raised on downcast is the behavior we really want. We don't need python complex types introducing subtle bugs as well. I understand why we have the silent downcast from complex to float, but I consider it a wart, not a feature. I've lost hours tracking down bugs where I'm putting complex data from some routine into a new array (without specifying a dtype) ends up with the complex downcast silently to float64. The only reason you even notice it is because at the end you have incorrect answers. I know to look for it now, but for inexperienced users, it's a pain. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion