Opened 11 years ago

# Make symbolic versions of moebius, sigma, and euler_phi functions

Reported by: Owned by: zimmerma burcin minor sage-6.4 symbolics leif, benjaminfjones, eviatarbach, slelievre N/A

### 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.

### comment:1 follow-up: ↓ 2 Changed 11 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 11 years ago by zimmerma

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 11 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: ↓ 6 Changed 11 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 11 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 11 years ago by zimmerma

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 11 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:11 Changed 8 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?
```

### comment:12 Changed 8 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 8 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 8 years ago by afleckenstein (previous) (diff)

### comment:14 Changed 8 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:16 Changed 7 years ago by jdemeyer

• Milestone changed from sage-5.11 to sage-5.12

### comment:17 Changed 7 years ago by vbraun_spam

• Milestone changed from sage-6.1 to sage-6.2

### comment:18 Changed 7 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: ↓ 21 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 17 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 6 years ago by vbraun_spam

• Milestone changed from sage-6.3 to sage-6.4