I am not sure if I get a vote, but I wanted to say my opinion as more
of a Sage user than developer.
Since n() is type conversion of sorts, I would expect it to behave
similar to python's int() function. Which means just give error if you
pass it a list (to remind you to use map). "explicit is better than
implicit" ;)
>>> int(['3','3','4532'])
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: int() argument must be a string or a number, not 'list'
Mathematica behaves very differently as tons of its functions take
lists (even without reference in the help files).
In[1]:= FactorInteger[{3, 5342, 345, 4, 2654, 43}]
Out[1]= {{{3, 1}}, {{2, 1}, {2671, 1}}, {{3, 1}, {5, 1}, {23,
1}}, {{2, 2}}, {{2, 1}, {1327, 1}}, {{43, 1}}}
So if Sage wants to act like mathematica a lot of functions need to be
rewritten. But i think it should stay true to the python way.
Rado
On Sep 24, 12:29 am, Craig Citro <craigci...@gmail.com> wrote:
> >>> 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)
>
> I'm -1 on this idea, for one reason: I find it wildly confusing to
> have n(*my_list) do something very different based on the length of
> the input. If we do this, we have to explain that "The n() function
> can take any number of arguments, and if you give it more than 2, or
> any iterable with more than 2 entries, it will iterate over them, but
> with less than two, it will coerce into a real or complex number." I
> think this will lead to an endless number of bugs -- you have a
> perfectly valid and doctested program that happens to use this
> behavior for n(), but then you happen to pass it a slightly shorter
> list, and now you're getting the wrong datatype back. Of course, z[0]
> and z[1] do return the two inputs -- but I still don't think this
> makes it okay, because an element of CDF is *not* a list of length
> two. (And x[0] fails for x a real number.)
>
> In a perfect world, I'd say that we should make n(a,b) not return a
> complex number -- and then I'm +0 on the idea. In principle I agree
> with Simon -- this is what map and list comprehensions are for -- but
> I also see that it's convenient. That said, map(n, ls) isn't really
> that much longer than n(ls) -- and it's way, way clearer IMHO.
>
> > Note that min, max, and other functions work something like this, in
> > that they accept a variable number of arguments.
>
> I don't think this is the same thing -- these are operations that go
> from (List of comparable objects) -> (a single object). So in the case
> of max, we're just adding a convenient calling convention, not
> actually changing the function signature. For n, though, I think it's
> a different story.
>
> -cc
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
