Open zimmermann6 opened 14 years ago
We'd have to produce a symbolic version of sigma somewhere. Do you want this for all arithmetic functions? We really should have an arithmetic function class anyway, but it's probably more trouble than it's worth to actually do it.
Okay, then I think I will update the summary of this. Also changing component since it's more at symbolics than calculus.
We would need to have a uniform error message as well, and hopefully use plot_step_function as a unified plotting method (?).
Can you either provide a list of "arithmetic functions" which should be made symbolic, or just make this ticket about sigma()
?
Tickets with blanket statements about symbolic functions (see #4102, #1158, #4229) are hard to attack since nobody takes on the task of making a list of functions which need to be fixed.
Well, at the very least the ones in rings/arith.py which have 'standard' representations should be, so Moebius, Euler_Phi, Sigma. Someday we will hopefully also implement things like the Mertens function (not to be confused with the constant), and those should also be able to remain symbolic. If Paul has others which we have and Maple leaves symbolic, that would be great.
Replying to @burcin:
Can you either provide a list of "arithmetic functions" which should be made symbolic, or just make this ticket about
sigma()
?
doesn't Sage provide such a list? It would then be easy to do a loop over all functions and determine those which don't work with symbolic arguments.
Paul
But I don't think we want ALL such functions (if you are referring to all functions in rings/arith.py). I don't think we have a keyword otherwise, and it certainly isn't worth the time to do four_squares or primitive_root (which just gives the smallest one) as a symbolic function before we have even implemented some of these other functions. Anyway, I'll change the summary again to make my preference clear :)
Interestingly, these three functions all give different errors upon giving them 'x' as an argument. That's probably irrelevant, but still fun to point out.
Is the best way to do this by just making all of the functions BuiltinFunctions? I'm trying to import BuiltinFunction in rings/arith.py, but when I do:
from sage.symbolic.function import BuiltinFunction
in rings/arith.py, I get the error:
ImportError: cannot import name QuotientRing
Error importing ipy_profile_sage - perhaps you should run %upgrade?
WARNING: Loading of ipy_profile_sage failed.
You're running into circular imports. Symbolic functions are considerably slower compared to the current implementations in sage/rings/arith.py
. Since these are used in many places in the Sage library, it would make sense to keep those and introduce symbolic versions in a new file (sage/functions/arith.py
say). Then you need to make sure that the functions imported at the Sage command line are the symbolic ones.
Thanks for looking into this.
As I'm writing the symbolic version of sigma, it appears that a symbolic function created using BuiltinFunction has to have an explicit number of arguments. It is a little more work to write
sage: sigma(5, 1)
than just
sage: sigma(5)
but I'm not sure if there's a way around it.
Hi, thanks for working on this!
One solution (this is one I'm using on #4102), is to write a wrapper function sigma
that will take either one or two arguments and return the general symbolic function of two arguments accordingly:
sage: sigma(5)
symbolic_sigma(5, 1)
sage: sigma(x, 2)
symbolic_sigma(x, 2)
The symbolic function symbolic_sigma
would inherit from BuiltinFunction
and have two arguments. It's printed name could be just sigma
instead of symbolic_sigma
to lessen confusion.
But all functions mentioned so far are expressible using Dirichlet generating functions, and it would make much more sense to make them just wrappers around that (nonexisting) functionality. The same applies to C-finite "functions" like fibonacci
, lucas_number1
, lucas_number2
, which are generalized with #15714.
Did somebody say defining Dirichlet series? Here is an implementation that I haven't had time to try out but which might be a good basis for that. This sage-support thread may also be relevant, though I don't know how advanced that psage code is.
Thanks. I copied your comment to create #16477.
Removing the "beginner" tag from old tickets. Some could be returned to beginner-friendly status by adding a comment about what needs to be done. Some others might be easy for an experienced developer to finish.
I hit the following problem:
Wouldn't it better to keep sigma(x) unevaluated for x not an integer? Note that
f = lambda(x):sigma(x)-x
works but it less nice.CC: @nexttime @benjaminfjones @eviatarbach @slel
Component: symbolics
Issue created by migration from https://trac.sagemath.org/ticket/8383