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. On Sunday, March 19, 2017 at 7:52:21 AM UTC-7, Nils Bruin wrote: > > On Sunday, March 19, 2017 at 12:54:34 AM UTC-7, Aidan wrote: >> >> >> I wrote some code >> <https://gist.github.com/aijony/8675b9b348a7c510d634f768d5ad7e8e> 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. > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
