From: Travis O. <oli...@ie...> - 2006-10-12 04:01:45
|
Greg Willden wrote: > On 10/11/06, *Travis Oliphant* <oli...@ee... > <mailto:oli...@ee...>> wrote: > > Stefan van der Walt wrote: > >Further, if I understand correctly, changing sqrt and power to give > >the right answer by default will slow things down somewhat. But > is it > >worth sacrificing intuitive usage for speed? > > > For NumPy, yes. > > This is one reason that NumPy by itself is not a MATLAB replacement. > > > This is not about being a Matlab replacement. > This is about correctness. I disagree. NumPy does the "correct" thing when you realize that sqrt is a function that returns the same type as it's input. The field over-which the operation takes place is defined by the input data-type and not the input "values". Either way can be considered correct mathematically. As Paul said it was a design decision not to go searching through the array to determine whether or not there are negative numbers in the array. Of course you can do that if you want and that's what scipy.sqrt does. > Numpy purports to handle complex numbers. > Mathematically, sqrt(-1) is a complex number. Or, maybe it's undefined if you are in the field of real numbers. It all depends. > Therefore Numpy *must* return a complex number. Only if the input is complex. That is a reasonable alternative to your specification. > > If Numpy doesn't return a complex number then it shouldn't pretend to > support complex numbers. Of course it supports complex numbers, it just doesn't support automatic conversion to complex numbers. It supports complex numbers the same way Python supports them (i.e. you have to use cmath to get sqrt(-1) == 1j) People can look at this many ways without calling the other way of looking at it unreasonable. I don't see a pressing need to change this in NumPy, and in fact see many reasons to leave it the way it is. This discussion should move to the scipy list because that is the only place where a change could occur. -Travis. |