I think it would be great if n() and other functions mapped to a list. I don't see the downside, but maybe I am missing something.
-Marshall On Sep 8, 5:38 am, Jason Grout <[email protected]> wrote: > Simon King wrote: > > Hi Burcin, > > > On Sep 8, 11:21 am, Burcin Erocal <[email protected]> wrote: > >> I would call it a bug, a side effect of trying to convert the argument > >> to a complex number as a last resort. > > > No, it is documented, at least implicitly. From the doc string of n: > > INPUT: > > - ``x`` - an object that has a numerical_approx > > method, or can be coerced into a real or complex field > > - ``prec (optional)`` - an integer (bits of > > precision) > > - ``digits (optional)`` - an integer (digits of > > precision) > > > But we have > > sage: CC([1,2]) > > 1.00000000000000 + 2.00000000000000*I > > and thus it is natural that we get > > sage: n([1.0001,2.000000001],prec=3) > > 1.0 + 2.0*I > > >> We also have: > > >> sage: n([1]) > >> <boom> > >> sage: n([1,2,3]) > >> <boom> > > > ... since there is no reasonable way to coerce a list of 1 or 3 > > numbers to a real or complex number. (RR([1]) goes boom). > > >> The question is, do we want this case to also raise an error, or the > >> function n() to iterate over the argument when it's iterable? > > > Why is there list comprehension in Python? I am "-1" concerning > > iteration over the argument. > > Would it be pythonic enough to have n(pi/2,pi,2*pi) return a list of > three values? That way we could do: > > n(*my_list) > > Note that min, max, and other functions work something like this, in > that they accept a variable number of arguments. > > Jason > > -- > Jason Grout --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
