Opened 10 years ago

Last modified 6 months ago

#8383 new enhancement

Make symbolic versions of moebius, sigma, and euler_phi functions

Reported by: zimmerma Owned by: burcin
Priority: minor Milestone: sage-6.4
Component: symbolics Keywords: beginner
Cc: leif, benjaminfjones, eviatarbach, slelievre Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description

I hit the following problem:

sage: f(x) = sigma(x)-x
...
TypeError: unable to convert x (=x) to an integer

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.

Change History (23)

comment:1 follow-up: Changed 10 years ago by kcrisman

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.

comment:2 in reply to: ↑ 1 Changed 10 years ago by zimmerma

Replying to kcrisman:

We'd have to produce a symbolic version of sigma somewhere. Do you want this for all arithmetic functions?

yes, in Maple for example numtheory[sigma](x) remains symbolic, and does not produce an error.

comment:3 Changed 10 years ago by kcrisman

  • Component changed from calculus to symbolics
  • Summary changed from should sigma(x) produce an error? to Make symbolic versions of arithmetic functions

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 (?).

comment:4 follow-up: Changed 10 years ago by burcin

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.

comment:5 Changed 10 years ago by kcrisman

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.

comment:6 in reply to: ↑ 4 Changed 10 years ago by zimmerma

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

comment:7 Changed 10 years ago by kcrisman

  • Summary changed from Make symbolic versions of arithmetic functions to Make symbolic versions of moebius, sigma, and euler_phi functions

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.

comment:8 Changed 10 years ago by leif

  • Cc leif added

comment:9 Changed 9 years ago by burcin

  • Keywords beginner added

comment:10 Changed 8 years ago by benjaminfjones

  • Cc benjaminfjones added

comment:11 Changed 7 years ago by afleckenstein

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.

comment:12 Changed 7 years ago by burcin

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.

comment:13 Changed 7 years ago by afleckenstein

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.

Last edited 7 years ago by afleckenstein (previous) (diff)

comment:14 Changed 7 years ago by benjaminfjones

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.

comment:15 Changed 7 years ago by eviatarbach

  • Cc eviatarbach added

comment:16 Changed 6 years ago by jdemeyer

  • Milestone changed from sage-5.11 to sage-5.12

comment:17 Changed 6 years ago by vbraun_spam

  • Milestone changed from sage-6.1 to sage-6.2

comment:18 Changed 6 years ago by vbraun_spam

  • Milestone changed from sage-6.2 to sage-6.3

comment:19 Changed 6 years ago by rws

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.

comment:20 follow-up: Changed 6 years ago by kcrisman

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.

Last edited 6 months ago by slelievre (previous) (diff)

comment:21 in reply to: ↑ 20 Changed 6 years ago by rws

Thanks. I copied your comment to create #16477.

comment:22 Changed 5 years ago by vbraun_spam

  • Milestone changed from sage-6.3 to sage-6.4

comment:23 Changed 3 years ago by slelievre

  • Cc slelievre added
Note: See TracTickets for help on using tickets.