> I'm completely unable to get the scipy special functions module to > work. In addition, it seems to cause chaos on my system once imported > > > sage: import scipy > sage: from scipy.special import * > sage: scipy.special.lpn(1,1)
I'd avoid your second line in Sage, which pulls everything in scipy.special into the local namespace. The *-import means that a lot of Sage functions are replaced by (num/sci)py identically-named functions, which will cause no end of trouble. (E.g. the standard Sage symbolic cos is replaced by the numpy cos.) I'm guessing that's the chaos you're referring to. I'd recommend using import scipy.special especially if you're going to be writing scipy.special.lpn(1,1) anyway. As for the problem itself, this is a known issue, due to an unfortunate design decision in the numpy/scipy isscalar function. It which doesn't duck type, and so objects to types it doesn't know such as those used by Sage (or even Python-native types not in its list). http://trac.sagemath.org/sage_trac/ticket/10928 Lots of the scipy.special functions _do_ work, but any that use isscalar will probably fail. A workaround is to make sure that what lpn is passed is a Python object: sage: scipy.special.lpn(int(1), float(2)) (array([ 1., 2.]), array([ 0., 1.])) sage: scipy.special.lpn(1r, 2r) (array([ 1., 2.]), array([ 0., 1.])) > 597 if not (isscalar(n) and isscalar(z)): > --> 598 raise ValueError, "arguments must be scalars." > 599 if (n!= floor(n)) or (n<0): > 600 raise ValueError, "n must be a non-negative integer." > > ValueError: arguments must be scalars. > sage: n > <function numerical_approx at 0x2dc1668> Just for the record, this "n" isn't the n in the code fragment, which is the first argument to lpn. Doug -- Department of Earth Sciences University of Hong Kong -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
