Simon King wrote: > Hi Burcin, > > On Sep 8, 11:21 am, Burcin Erocal <bur...@erocal.org> 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 sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
