On Sep 8, 2009, at 3:38 AM, Jason Grout wrote: > 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.
For sure. +1 - Robert --~--~---------~--~----~------------~-------~--~----~ 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 URL: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
