Inconsistent handling of exact function arguments

[dkrenn]

At the moment we have

sage: polylog(QQbar(sqrt(2)),3)
polylog(1.414213562373095?, 3)

and

sage: log(QQbar(sqrt(2)))
0.346573590279973
sage: type(_)
<type 'sage.rings.real_mpfr.RealNumber'>

So the logarithm of an exact value loses the exactness.

I would expect a symbolic expression

sage: log(QQbar(sqrt(2)))
log(1.414213562373095?)

where the argument is the symbolic encapsulation of QQbar(sqrt(2)) (for the same reason why the logarithm of the integer 2 becomes the symbolic log(2).

This is fixed for all GinacFunctions in Pynac git master. The ticket should doctest them in the resp. files under sage/functions.

Depends on #22219

CC: @behackl @cheuberg

Component: algebra

Keywords: Pynac

Author: Daniel Krenn

Branch/Commit: c252b4d

Reviewer: Ralf Stephan

Issue created by migration from https://trac.sagemath.org/ticket/22142

[rwst]

comment:1

I have a Pynac patch that does this:

sage: log(QQbar(sqrt(2)))
log(1.414213562373095?)
sage: log(QQbar(sqrt(2))*1.)
0.346573590279973

However, the question is raised if you don't want this for all functions, and if you do, if we want to hold all functions with exact arguments (except where we have a simplified representation, i.e., a closed form that is simpler than the function expression).

EDIT: or if not all functions, then which?

[rwst]

comment:2

BTW polylog does it already, so this is clearly an inconsistency within Pynac:

sage: polylog(QQbar(sqrt(2)),3)
polylog(1.414213562373095?, 3)

[rwst]

Changed keywords from none to Pynac

[rwst]

Dependencies: pynac-0.7.4

[dkrenn]

comment:4

Replying to @rwst:

I have a Pynac patch that does this:

sage: log(QQbar(sqrt(2)))
log(1.414213562373095?)
sage: log(QQbar(sqrt(2))*1.)
0.346573590279973

Good. Thanks :)

However, the question is raised if you don't want this for all functions, and if you do, if we want to hold all functions with exact arguments (except where we have a simplified representation, i.e., a closed form that is simpler than the function expression).

EDIT: or if not all functions, then which?

IMHO yes, we want this for all symbolic functions, as no exact value should get inexact. What would be the drawbacks?

[rwst]

comment:5

Replying to @dkrenn:

IMHO yes, we want this for all symbolic functions, as no exact value should get inexact. What would be the drawbacks?

No drawbacks. I just needed confirmation.

[cheuberg]

comment:6

For completeness, I mention the sage-devel thread on gamma(QQbar(...))

[dkrenn]

Branch: u/dkrenn/t/22142

[dkrenn]

Author: Daniel Krenn

[dkrenn]

Commit: ce93586

[dkrenn]

Changed dependencies from pynac-0.7.4 to #22219 pynac-0.7.4

[dkrenn]

New commits:

11951c8	22219: pkg version/chksum
91973f1	22219: giac usage is GO
a178a75	22219: doctest fixes
c7eb7ff	Merge branch 'develop' into t/22219/upgrade_to_pynac_0_7_4
57c7bce	22219: giac dependency
3a3bcf2	Merge branch 'u/rws/upgrade_to_pynac_0_7_4' of git://trac.sagemath.org/sage into HEAD
ce93586	doctests for #22142

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

c252b4d

doctests for #22142

[sagetrac-git]

Changed commit from ce93586 to c252b4d

[rwst]

comment:10

Is fine modulo the dependency.

[rwst]

Reviewer: Ralf Stephan

[vbraun]

comment:11

The dependency needs to be a ticket number...

[dkrenn]

Changed dependencies from #22219 pynac-0.7.4 to #22219

[dkrenn]

comment:13

Replying to @vbraun:

The dependency needs to be a ticket number...

Ticket number was already there; just the "pynac..." has not been removed.

[vbraun]

Changed branch from u/dkrenn/t/22142 to c252b4d