An abbreviation for lambda?

[Alasdair]

In some CAS's (Sage, Maxima), the "lambda" construct is used for an
anonymous function:

p=prime_range(30)
map(lambda x:x^2+1,p)

whereas in others, an arrow notation is used:

map(x->x^2+1,p) (Maple, MuPAD)
map(x+->x^2+1,p) (Axiom)

I'm very fond of the convenience of arrow notation. Would it be very
hard to incorporate such a notation into the Sage parser?

Thanks,
Alasdair

[Carlos Córdoba]

I don't think it would be so hard to do but this could break interoperability with Python, the language on which Sage is based. Besides it could make Sage like a dialect of python, something that sage devs don't want to do.

Unfortunately python is not a very friendly functional programming language, although it has some constructs that can help you if you like to do things in the functional style.

Hope this helps,

Carlos

2009/12/13 Alasdair <amc...@gmail.com>

--
To post to this group, send email to sage-s...@googlegroups.com
To unsubscribe from this group, send email to sage-support...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-support
URL: http://www.sagemath.org

[kcrisman]

On Dec 14, 9:19 am, Carlos Córdoba <ccordob...@gmail.com> wrote:
> I don't think it would be so hard to do but this could break
> interoperability with Python, the language on which Sage is based. Besides
> it could make Sage like a dialect of python, something that sage devs don't
> want to do.
>
> Unfortunately python is not a very friendly functional programming
> language, although it has some constructs that can help you if you like to
> do things in the functional style.
>
> Hope this helps,
> Carlos
>
> 2009/12/13 Alasdair <amc...@gmail.com>
>
>
>
> > In some CAS's (Sage, Maxima), the "lambda" construct is used for an
> > anonymous function:
>
> > p=prime_range(30)
> > map(lambda x:x^2+1,p)
>
> > whereas in others, an arrow notation is used:
>
> > map(x->x^2+1,p) (Maple, MuPAD)
> > map(x+->x^2+1,p) (Axiom)
>
> > I'm very fond of the convenience of arrow notation.  Would it be very
> > hard to incorporate such a notation into the Sage parser?

If this would cause a Python syntax error, then presumably foo -> bar
could be turned into lambda foo: bar, which would be completely
native. Perhaps someone who is quite familiar with the preparser will
comment. But this seems like a reasonable thing to add, particularly
for those coming from Maple. What does Mathematica do for such
anonymous functions (if anything)?

- kcrisman

[Jason Grout]

kcrisman wrote:

#^2+1 & (note the & is important; it says what comes before is an
anonymous function).

Or:

#1^2+#2^3 & (meaning lambda x,y: x^2+y^2). #n means the nth parameter.

See the bottom of
http://reference.wolfram.com/mathematica/tutorial/PureFunctions.html

Jason

[kcrisman]

Then that sounds like another Python syntax error we could make
available. Not sure we'd want to, though.

- kcrisman

[Jason Grout]

kcrisman wrote:

It looks like -> might cause a syntax error, at least in a trivial case:

sage: x -> x^2
------------------------------------------------------------
File "<ipython console>", line 1
x -> x**Integer(2)
^
SyntaxError: invalid syntax


We currently print out things in sort of functional notation:

sage: f(x)=x^2
sage: f
x |--> x^2

I don't know if it's a good idea to make this valid Sage syntax, though.
I'm on the fence, but leaning towards not favoring it just because
of the added complexity and the departure from true Python, and the
python version isn't all that bad.

Jason

[Dag Sverre Seljebotn]

Note that -> gets a meaning in Python 3, to annotate the result of a
function:

def foo(a: int) -> float:
...

I don't think this is a technical problem as one can rely on the
statement to start with "def", but at least -> already means something.

Dag Sverre

[Marshall Hampton]

I felt ambivalent about adding the "->" until this point. If "->" is
going to mean something else in python eventually, it seems like a bad
idea to overload it in a Sage-specific way.

-Marshall

On Dec 14, 10:01 am, Dag Sverre Seljebotn

[Carlos Córdoba]

I have to agree with Marshall, because it could be confusing for new sage users that come from python to see such a different syntax meaning.

But what about the Mathematica syntax? Could it be adopted by sage?

The problem is that most CAS are functional in nature and the first thing one tries to do in Sage is to translate one's old Mathematica, Maple, etc, programs to python. For example, I was accustomed to write one-liners that did a lot of stuff with maps over lists. But the lambda keyword is somewhat discouraging because it makes your code look overwhelmed and ugly. I have seen that people use it in python to write very simple functions. Now most people use list comprehensions, which are nice but not so much if you want to compose to or three functions at a time.

Just my two cents,

Carlos

2009/12/14 Marshall Hampton <hamp...@gmail.com>

[Robert Bradshaw]

On Dec 14, 2009, at 8:01 AM, Dag Sverre Seljebotn wrote:

>> I don't know if it's a good idea to make this valid Sage syntax,
>> though.
>> I'm on the fence, but leaning towards not favoring it just because
>> of the added complexity and the departure from true Python, and the
>> python version isn't all that bad.
>>
> Note that -> gets a meaning in Python 3, to annotate the result of a
> function:
>
> def foo(a: int) -> float:
> ...
>
> I don't think this is a technical problem as one can rely on the
> statement to start with "def", but at least -> already means
> something.

That's a good point. In general, I'm against adding stuff to the
preparser unless there's a very strong case for departing from what
Python already offers.

- Robert

[John H Palmieri]

On Dec 14, 11:43 am, Carlos Córdoba <ccordob...@gmail.com> wrote:
> I have to agree with Marshall, because it could be confusing for new sage
> users that come from python to see such a different syntax meaning.
>
> But what about the Mathematica syntax? Could it be adopted by sage?
>
> The problem is that most CAS are functional in nature and the first thing
> one tries to do in Sage is to translate one's old Mathematica, Maple, etc,
> programs to python. For example, I was accustomed to write one-liners that
> did a lot of stuff with maps over lists. But the lambda keyword is somewhat
> discouraging because it makes your code look overwhelmed and ugly. I have
> seen that people use it in python to write very simple functions. Now most
> people use list comprehensions, which are nice but not so much if you want
> to compose to or three functions at a time.

Rather than adopt the Mathematica (or Maple) syntax, how feasible
would it be to have translation functions, so you could plug in your
old Maple (or Mathematica) code and it would attempt to produce valid
Sage code? This might be a good project for a team of undergraduates.

John

[Robert Bradshaw]

On Dec 14, 2009, at 11:43 AM, Carlos Córdoba wrote:

> I have to agree with Marshall, because it could be confusing for new
> sage users that come from python to see such a different syntax
> meaning.
>
> But what about the Mathematica syntax? Could it be adopted by sage?

The Mathematica syntax is (in my opinion) much less Pythonic than
using "->" in this context, even if the latter will have another
meaning in Python 3.

[Dag Sverre Seljebotn]

Robert Bradshaw wrote:

> On Dec 14, 2009, at 11:43 AM, Carlos C�rdoba wrote:
>
>> I have to agree with Marshall, because it could be confusing for new
>> sage users that come from python to see such a different syntax
>> meaning.
>>
>> But what about the Mathematica syntax? Could it be adopted by sage?
>
> The Mathematica syntax is (in my opinion) much less Pythonic than
> using "->" in this context, even if the latter will have another
> meaning in Python 3.

Does the CAS syntax really mean Python "lambda" though? I would think
that using -> in Maple would define something symbolic which one could
manipulate...more like an anonymous

f(x) = x**2

than "lambda x: x**2". For the latter one cannot find symbolic
derivatives and so on.

--
Dag Sverre

[Robert Bradshaw]

On Dec 14, 2009, at 12:15 PM, Dag Sverre Seljebotn wrote:

> Robert Bradshaw wrote:

>> On Dec 14, 2009, at 11:43 AM, Carlos Córdoba wrote:
>>
>>> I have to agree with Marshall, because it could be confusing for new
>>> sage users that come from python to see such a different syntax
>>> meaning.
>>>
>>> But what about the Mathematica syntax? Could it be adopted by sage?
>>
>> The Mathematica syntax is (in my opinion) much less Pythonic than
>> using "->" in this context, even if the latter will have another
>> meaning in Python 3.
>
> Does the CAS syntax really mean Python "lambda" though?

Thanks for bringing up this point. No it doesn't, and shouldn't if we
adopt this syntax.

- Robert

[Carlos Córdoba]

2009/12/14 Robert Bradshaw <robe...@math.washington.edu>

On Dec 14, 2009, at 12:15 PM, Dag Sverre Seljebotn wrote:

> Robert Bradshaw wrote:
>> On Dec 14, 2009, at 11:43 AM, Carlos Córdoba wrote:
>>
>>> I have to agree with Marshall, because it could be confusing for new
>>> sage users that come from python to see such a different syntax
>>> meaning.
>>>
>>> But what about the Mathematica syntax? Could it be adopted by sage?
>>
>> The Mathematica syntax is (in my opinion) much less Pythonic than
>> using "->" in this context, even if the latter will have another
>> meaning in Python 3.
>
> Does the CAS syntax really mean Python "lambda" though?

Thanks for bringing up this point. No it doesn't, and shouldn't if we
adopt this syntax.

- Robert

Correct me if I'm wrong but I believed that the definition f(x) = x^2 as a symbolic function it's only possible in sage.

Anyway, the use of anonymous functions is mostly useful on constructs that operate over lists, like map and reduce. In 10 years of using Mathematica I've ever needed to derive this kind functions, but nevertheless I've checked if it's possible, and indeed it is, for example

D[(#^2)&[x], x]

gives 2*x.

 

> I would think
> that using -> in Maple would define something symbolic which one could
> manipulate...more like an anonymous
>
> f(x) = x**2
>
> than "lambda x: x**2". For the latter one cannot find symbolic
> derivatives and so on.

--

[Martin Rubey]

Carlos Córdoba <ccord...@gmail.com> writes:

> Anyway, the use of anonymous functions is mostly useful on constructs
> that operate over lists, like map and reduce. In 10 years of using
> Mathematica I've ever needed to derive this kind functions, but
> nevertheless I've checked if it's possible, and indeed it is, for
> example
>
> D[(#^2)&[x], x]
>
> gives 2*x.

I don't think that this implies that anonymous functions are symbolic,
since (#^2)&[x] gives already x^2. MMA's evaluation rules are tricky
though, I do not know whether D evaluates all it's arguments before
calling.

Martin

[Jaap Spies]

I truly hope this 'hocus pocus' will never make it in Sage!

Jaap



> Martin
>

[Marshall Hampton]

Mathematica's syntax can be quite dense, which has the same
disadvantage as Perl code in my opinion - it can be hard to read. But
sometimes it is nice to be able to do so much concisely. I miss it
sometimes.

-Marshall

[Alex Ghitza]

On Mon, Dec 14, 2009 at 10:31:14PM +0100, Jaap Spies wrote:
> Martin Rubey wrote:

The whole discussion started with a suggestion for making the lambda
notation more mathematician-friendly (by making it closer to
mathematical notation). Based on this, two comments:

1. I agree with Jaap that Mathematica's notation is by far less
human-friendly than the Python lambda. It's really obscure. Maybe it
makes sense when viewed as part of Mathematica's syntax, but it would
look really ugly and weird in Sage. So, please no!

2. Going back to the original suggestion, which was to use ->: that's
not actually correct mathematical notation. The right one is closer
to what Sage outputs (as Jason pointed out), i.e.

x |-> x^2

So if we're going to do anything in this direction, I would much
prefer this to x -> x^2 which is just plain wrong.



Best,
Alex


--
Alex Ghitza -- Lecturer in Mathematics -- The University of Melbourne
-- Australia -- http://www.ms.unimelb.edu.au/~aghitza/

[Christopher Olah]

I think that having a way to make anonymous functions is very
important. While, as someone relatively new to sage, I haven't used in
sage, I use it all the time in math (For example, my prefered
definition of the Mandlebrot set is {x|x ∊ ℂ; lim_(n->∞)
(λz:z^2+x)ⁿ(0)≠∞} )...

I quite like the idea of using "|->" but some other possibilities are:
- 'l' instead of the full lambda...
- or some other substring of lambda like "la", "lam", etc...

Another possibility, though I suspect just about everyone will scream
at me for it, and even I'm not sure I like it... is using unicode (ie
λ x : ...).

While on this topic, it would be neat if we could support recursive
anonymous functions...

Christopher Olah

[Jaap Spies]

Marshall Hampton wrote:
>
> Mathematica's syntax can be quite dense, which has the same
> disadvantage as Perl code in my opinion - it can be hard to read. But
> sometimes it is nice to be able to do so much concisely. I miss it
> sometimes.
>

Maybe you are also a lisp lover. But please, let Sage be as close to
Python as possible!

Jaap

[Jason Grout]

Christopher Olah wrote:
> I think that having a way to make anonymous functions is very
> important. While, as someone relatively new to sage, I haven't used in
> sage, I use it all the time in math (For example, my prefered
> definition of the Mandlebrot set is {x|x ∊ ℂ; lim_(n->∞)
> (λz:z^2+x)ⁿ(0)≠∞} )...
>
> I quite like the idea of using "|->" but some other possibilities are:
> - 'l' instead of the full lambda...
> - or some other substring of lambda like "la", "lam", etc...

Neither of these possibilities get any closer to mathematical notation.
The difference I see between lam x: x^2 and lambda x:x^2 is that I
have to explain to everyone what "lam" means, whereas a lot of people
(with CS backgrounds) will already know what sorts of things "lambda"
deals with.

>
> Another possibility, though I suspect just about everyone will scream
> at me for it, and even I'm not sure I like it... is using unicode (ie
> λ x : ...).

Yep, unicode is right out. I can't wait for Fortress to come out,
though! http://en.wikipedia.org/wiki/Fortress_%28programming_language%29

Thanks,

Jason

[Jason Grout]

Robert Bradshaw wrote:
> On Dec 14, 2009, at 12:15 PM, Dag Sverre Seljebotn wrote:
>
>> Robert Bradshaw wrote:

>>> On Dec 14, 2009, at 11:43 AM, Carlos C�rdoba wrote:
>>>
>>>> I have to agree with Marshall, because it could be confusing for new
>>>> sage users that come from python to see such a different syntax
>>>> meaning.
>>>>
>>>> But what about the Mathematica syntax? Could it be adopted by sage?
>>> The Mathematica syntax is (in my opinion) much less Pythonic than
>>> using "->" in this context, even if the latter will have another
>>> meaning in Python 3.
>> Does the CAS syntax really mean Python "lambda" though?
>
> Thanks for bringing up this point. No it doesn't, and shouldn't if we
> adopt this syntax.
>
> - Robert

This also makes the case that maybe using something like |-> isn't that
far out for us, since we *already* have a preparser rule that converts

f(x)=x^2

to

__tmp__=var("x"); f = symbolic_expression(x**Integer(2)).function(x)

So

(variable list) |-> expression

translated to:

symbolic_expression(expression).function(variable list)

is sort of a natural extension of this. Of course, we need to worry
about creating variables and introducing them into the namespace.

Jason

[Marshall Hampton]

On Dec 14, 5:23 pm, Jaap Spies <j.sp...@hccnet.nl> wrote:

> Maybe you are also a lisp lover. But please, let Sage be as close to
> Python as possible!
>
> Jaap

Lisp lover! Now those are fightin' words!

-Marshall

[Christopher Olah]

>> I think that having a way to make anonymous functions is very
>> important. While, as someone relatively new to sage, I haven't used in
>> sage, I use it all the time in math (For example, my prefered
>> definition of the Mandlebrot set is {x|x ∊ ℂ; lim_(n->∞)
>> (λz:z^2+x)ⁿ(0)≠∞} )...
>>
>> I quite like the idea of using "|->" but some other possibilities are:
>> - 'l' instead of the full lambda...
>> - or some other substring of lambda like "la", "lam", etc...
>
> Neither of these possibilities get any closer to mathematical notation.
>  The difference I see between lam x: x^2 and lambda x:x^2 is that I
> have to explain to everyone what "lam" means, whereas a lot of people
> (with CS backgrounds) will already know what sorts of things "lambda"
> deals with.

The difference is brevity. Don't doubt the capacity of effort to use
in changing usage patterns.

>> Another possibility, though I suspect just about everyone will scream
>> at me for it, and even I'm not sure I like it... is using unicode (ie
>> λ x : ...).
>
> Yep, unicode is right out.  I can't wait for Fortress to come out,
> though!  http://en.wikipedia.org/wiki/Fortress_%28programming_language%29

Indeed!

[Harald Schilly]

I'm a bit against the preparser idea and adding stuff to it, too. I'm
curious if there will be a way to define a custom operator in python
some time in the future. I think these sorts of ideas will be solved
if there is a clear way how to define one without running into
troubles anytime in the future.

H