Name symbolic expressions

[Aidan]

I wrote some code I would like to contribute, but I don't know the most appropriate place to put it.

It works like this right now

        sage: g(x,y) = x + sin(y)
        (x, y) |--> x + sin(y)
        sage: g = name('g', g)
        sage: g
        g(x, y) == x + sin(y)

I would say it is naming an expression or unnamed function to a function, but if it is actually doing something else, please let me know.

I am trying to discern where to put it in the code base (assuming people want it)

Somewhere like here made sense to me, but that might be my horrible understanding of programming.

This would be as function, so it would return the value like in the example above.

But I also was thinking of putting it in as a method in sage.symbolic.expression as a method that mutates an expression object.
I don't know if this is allowed.

I don't think I can call this name() because symbolic.function already has a name()

What would be some good names, I want to be short as the whole idea of this function is to be a short cut from

sage: g = f; f = function('f')(x) == g

to something more like

sage: f.set_name('f')

I've thought of:

• set_name()
• set_func()
• assign()
  
• name()
• give_name()
  

I'd love constructive feedback.

• Does this have a place in Sage?
• Where?
• What do you think of the code?
• What would be a good name?
  

[Nils Bruin]

On Sunday, March 19, 2017 at 12:54:34 AM UTC-7, Aidan wrote:

I wrote some code I would like to contribute, but I don't know the most appropriate place to put it.

It works like this right now

        sage: g(x,y) = x + sin(y)
        (x, y) |--> x + sin(y)
        sage: g = name('g', g)
        sage: g
        g(x, y) == x + sin(y)

I would say it is naming an expression or unnamed function to a function, but if it is actually doing something else, please let me know.

It's doing the work of this one-liner:

sage.symbolic.function_factory.function('g')(*(parent(g).arguments()))==g(*(parent(g).arguments()))

In order to untangle the different meanings of the symbols, let's set:

g=(x+sin(y)).function(x,y)
G=sage.symbolic.function_factory.function('G')
H=G(*(parent(g).arguments()))==g(*(parent(g).arguments()))

Here, g,H are python variables that are bound to python objects: g is bound to a "callable symbolic expression" and H is bound to a symbolic equality expression.
H.lhs() is a "sage symbolic function" (with print name "G") evaluated in x,y and H.rhs() is a symbolic expression.

The equation bound to H mathematically expresses the definition of g in the sense that

H.substitute_function(G,g)

gives a true expression.

Three objects are in play here:

(a) "callable symbolic expressions" (the value of g)

(b) "sage symbolic functions" (the value of G)

(c) python identifiers (the things you use to write g,G,H )

python identifiers (c) can be bound to (a) or (b) or any python object. That's how you use them, but the names g,G,H are not intrinsic properties of those objects. If I set

 a = 1
 b = a

I have two python identifiers bound to the same value (the integer 1), but the names a,b are not properties of the integer 1.

Callable expressions (a) can be used to symbolize mathematical functions with a known definition. do not have a "name" among their properties. That's because we can do:

g=(x+sin(y)).function(x,y)
f=g

then what would the name of that function be? is it f or g? It's neither.

Symbolic functions (b) are used to signify "abstract" functions: functions you don't know the definition ("value") of. Just as symbolic variables are used for "unknowns".
Their *main property* is having a print name so that they can be told apart. If they are bound to a python identifier, their names need not agree though:

sage: G=sage.symbolic.function_factory.function('G')
sage: F=G
sage: F,G
(G, G)

So, "naming" a callable expression doesn't really make sense in the current design of sage. There doesn't seem to be a need for a "name" property on (callable) symbolic expressions, and having it would probably be confusing because "names" in the form of python identifiers can already be bound to them.

Given that the expression you are producing is already available via a (convoluted) one-liner, I doubt much is to gain by adding it to sage. However, if, with continued use, you find good tools to make such one-liners less convoluted, that might be included.

In any case, you don't have to be held back by what gets included in sage or not. You can build your own private library of functions that are useful for you. If you find there are particularly useful constructs in there that you find you are using frequently across several projects (say 2 years or so), it may be worth looking if they can be incorporated. By then you'll have a good body of examples showing why they're useful and how they are used.

[Aidan]

Thank-you so much for the response.
As you can imagine, everything made sense to me before posting, but I can kind of see the other side of the coin.
It's nice to get feedback from someone who understands what they are talking about - unlike me.

I already understood that the code was a shortcut, and your "one-liner" was extremely helpful as it fixed one of the issues I was having.
I have no idea why

sage.symbolic.function_factory.function

worked better than

function

I thought they were the same, but I guess not.
Just a side not though, the "one-liner" doesn't work for functions with unnamed arguments like:

f = x

I was already planning on continuing to use this for personal use. I guess my use case is just a little to specific.
Thanks again for your time.

[Paul Masson]

Nils, this is a most excellent answer. Coming to Sage from Mathematica, I continue to be puzzled by the various ways functions are handled in Sage, so thanks!

This is a topic that has not yet been well documented. The only thing I have found close to it is a description of problems that can occur with functions (http://doc.sagemath.org/html/en/tutorial/tour_functions.html), but that document doesn't really go into any detail on what's happening like you just did here.

Could you be persuaded to turn this into the beginnings of a standalone document detailing the inner workings of symbolic functions? I think that would be a great addition to the documentation.

Thanks again!

On Sunday, March 19, 2017 at 7:52:21 AM UTC-7, Nils Bruin wrote:

[Eric Gourgoulhon]

This is not what you are proposing but somehow related to it: provided you consider (x,y) as coordinates on a manifold, you may define g as a named function as follows:

sage: M = Manifold(2, 'M')
sage: X.<x,y> = M.chart()  # declares the chart X on M,  with coordinates (x,y)
sage: g = M.scalar_field(x+sin(y), name='g')
sage: g.display()
g: M --> R
   (x, y) |--> x + sin(y)

Then you may use the function set_name to change the name of g:

sage: g.set_name('G')
sage: g.display()
G: M --> R
   (x, y) |--> x + sin(y)

You can also set the LaTeX display of g:

sage: g.set_name('G', latex_name=r'\mathcal{G}')

A difference with callable symbolic expressions is that you cannot call directly g on a pair of coordinates, i.e. write g(1,2), but have to go through the manifold point corresponding to these coordinates, i.e. M((1,2)) (in the present case, there is no need to specify the chart to which the coordinates belong, since only one chart has been declared; otherwise, one should declare the point as M((1,2), chart=X)). Hence

sage: g(M((1,2)))
sin(2) + 1

Another difference regards derivatives: the scalar function g has no diff() method, but it has a differential:

sage: g.differential().display()
dG = dx + cos(y) dy

and you can get the two partial derivatives via

sage: g.differential()[:]
[1, cos(y)]

Best wishes,

Eric.

PS: a big +1 to Paul's suggestion of turning the very nice answer of Nils into a proper documentation.

[mforets]

Dear Aidan,

Do you have a trac account? I didn't find you there. 

Your interesting question has triggered a very detailed answer by Nils, and other have suggested to turn it into proper documentation. As someone who is in the process of learning the internals of Sage too, I also think that explaining further about name usage in Python / Sage is a very useful contribution. I look forward to following up this thread in trac!

Cheers,

Marcelo.-

[Aidan]

Marcelo,

Could you be persuaded to turn this into the beginnings of a standalone document detailing the inner workings of symbolic functions? I think that would be a great addition to the documentation.

I didn't realize Paul was talking about me, and for some reason missed Eric's quote.

It was probably due to me being a bit discouraged, so I wasn't thinking clearly and was mildly distancing myself from this. That is no ones fualt but my own, and seeing this gave me a chance to look back and see that people still wanted my contributution so thank you.

I'm ready now,
I recently got an account. However, I have no clue where to start, but I'll see what I can do.

Thanks for the bump,
Aidan

[mforets]

El lunes, 17 de abril de 2017, 7:17:38 (UTC+2), Aidan escribió:

Marcelo,

Could you be persuaded to turn this into the beginnings of a standalone document detailing the inner workings of symbolic functions? I think that would be a great addition to the documentation.

I didn't realize Paul was talking about me, and for some reason missed Eric's quote.

Hehe :) Paul was most probably referring to Nils, indeed! But it is legal if someone else takes initiatives if he/she is motivated and has some time (making a bit of noise around to avoid double work is good too). Moreover if what we produce is crap (probably, but that's normal), then experts will just say so, and we'll iterate to improve it.

It was probably due to me being a bit discouraged, so I wasn't thinking clearly and was mildly distancing myself from this. That is no ones fualt but my own, and seeing this gave me a chance to look back and see that people still wanted my contributution so thank you.

well..  some people would argue that (for your own projects, for team work, and so on..), the notion of self-esteem explains a lot of things.. old stuff to psychologists, but usually unexplored terrain for technical people like us. so keep it up!

 

I'm ready now,
I recently got an account. However, I have no clue where to start, but I'll see what I can do.

In general you should read: http://doc.sagemath.org/html/en/developer/
But if you are familiar with git then you are some steps ahead.

 
This week i don't have time to do it myself, but the task would be to create a ticket with the appropriate fields and description, and CC people (always checking for similar tickets).

Cheers,
Marcelo.-