Sorry for not answering before, I've being a bit busy. I'll try to give a
concrete example of what I'm trying to do so you can understand me better.
I have a list of real numbers, for example

[1,2,3]

I want to multiply by 2 to get

[2,4,6]

the to sum it to 3

[5,7,9]

then divide by the max number

[5/9, 7/9, 1]

then convert every point to a point in the circle with

[[cos(5/9), sin(5/9)], [cos(7/9), sin(7/9)], [cos(1), sin(1)]]

Finally graph this thing with list_plot.

To do this in Mathematica I just have to operate on the successive lists.
But to do this on Sage I would have to transform the initial list into a
vector or numpy array, do all the operations and finally transform the
result again into a list of lists so I can plot it.

I was hoping to avoid the transformation functions, which (in my humble
opinion) make the code more verbose and can probably misguide those who read
it later ("why does he used vectors if the data are frequencies?")

To do what I want I would have to modify the arithmetics methods of the list
python built-in, so I can do 2 + [1,2,3] to get [3,4,5] instead of getting
an error. Unfortunately that is forbidden by the language.

Another option (mentioned by Marshall before) is to subclass list, with a
MyList class for example, and then change the methods I want on it. But then
I would have to wrap every list I use with MyList, which makes the code
equally verbose.

So the last thing that occurred to me was to modify the parser (or something
like that) so that every list that I write in Sage be an instance of MyList
instead of list, in the same spirit as every number in Sage is an instance
of Integer or RealNumber and not of int and float.

I hope you understand that my motivation is mainly aesthetic. I know that my
problem can be easily solved in Sage. I just want to know if I can write
more succinct and simpler code with just one type (a list), instead of doing
several transformations and possibly writing more functions to do them.

Thanks,
Carlos

On Tue, Jul 14, 2009 at 1:45 PM, William Stein <[email protected]> wrote:

>
> On Tue, Jul 14, 2009 at 3:01 AM, Paul Sargent<[email protected]> wrote:
> >
> >
> > On 13 Jul 2009, at 17:13, Robert Bradshaw wrote:
> >
> >> In general, we try to avoid modifying the preparser as much as
> >> possible. Sometimes, we really have to
> >>
> >> sage: eval("1/2 + 3^2")
> >> 1
> >>
> >> is really not acceptable (IMHO) for a serious alternative to other
> >> systems out there
> >
> > I know what you're getting at, but that's a rather cheeky example. '^'
> > is the python XOR operator. '**' is the python exponent operator. To
> > be honest, I'm not sure why sage re-writes '^' as '**'. As long as
> > there's an operator that does the job, everything is good IMHO.
>
> Your perspective might change if you imagine giving colloquium talks
> to college teachers who have all used Mathematica + Latex for years,
> where "^" means exponent and "/" means divide (not floor divide).   In
> my experience (having given dozens of such talks), such an audience
> would consider ^ not working "right" to be a "deal breaker" for many
> of them, and would not consider switching to Sage.
>
> > The bigger point about the pre-parser is reasonable though. It should
> > only do what's unavoidable (for appropriate values of "unavoidable").
>
> +1
>
> William
>
>
> >
> > >
> >
>
>
>
> --
> William Stein
> Associate Professor of Mathematics
> University of Washington
> http://wstein.org
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
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
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

Reply via email to