Opened 3 years ago

Closed 2 years ago

#22142 closed defect (fixed)

Inconsistent handling of exact function arguments

Reported by: dkrenn Owned by:
Priority: major Milestone: sage-7.5
Component: algebra Keywords: Pynac
Cc: behackl, cheuberg Merged in:
Authors: Daniel Krenn Reviewers: Ralf Stephan
Report Upstream: N/A Work issues:
Branch: c252b4d (Commits) Commit: c252b4d618c190c94acbc55a74bb3415a62fd7b6
Dependencies: #22219 Stopgaps:

Description (last modified by rws)

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.

Change History (14)

comment:1 follow-up: Changed 3 years ago by rws

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?

Last edited 3 years ago by rws (previous) (diff)

comment:2 Changed 3 years ago by rws

  • Description modified (diff)
  • Keywords Pynac added
  • Summary changed from log of algebraic number (QQbar element) gets inprecise to Inconsistent handling of exact function arguments

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

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

comment:3 Changed 3 years ago by rws

  • Dependencies set to pynac-0.7.4
  • Description modified (diff)

comment:4 in reply to: ↑ 1 ; follow-up: Changed 3 years ago by dkrenn

Replying to rws:

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?

comment:5 in reply to: ↑ 4 Changed 3 years ago by rws

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.

comment:6 Changed 3 years ago by cheuberg

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

comment:7 Changed 2 years ago by dkrenn

  • Branch set to u/dkrenn/t/22142

comment:8 Changed 2 years ago by dkrenn

  • Authors set to Daniel Krenn
  • Commit set to ce935868b2a537cd631d182008dc87ded02f6082
  • Dependencies changed from pynac-0.7.4 to #22219 pynac-0.7.4
  • Status changed from new to needs_review

New commits:

11951c822219: pkg version/chksum
91973f122219: giac usage is GO
a178a7522219: doctest fixes
c7eb7ffMerge branch 'develop' into t/22219/upgrade_to_pynac_0_7_4
57c7bce22219: giac dependency
3a3bcf2Merge branch 'u/rws/upgrade_to_pynac_0_7_4' of git://trac.sagemath.org/sage into HEAD
ce93586doctests for #22142

comment:9 Changed 2 years ago by git

  • Commit changed from ce935868b2a537cd631d182008dc87ded02f6082 to c252b4d618c190c94acbc55a74bb3415a62fd7b6

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

c252b4ddoctests for #22142

comment:10 Changed 2 years ago by rws

  • Reviewers set to Ralf Stephan
  • Status changed from needs_review to positive_review

Is fine modulo the dependency.

comment:11 follow-up: Changed 2 years ago by vbraun

  • Status changed from positive_review to needs_work

The dependency needs to be a ticket number...

comment:12 Changed 2 years ago by dkrenn

  • Dependencies changed from #22219 pynac-0.7.4 to #22219
  • Status changed from needs_work to positive_review

comment:13 in reply to: ↑ 11 Changed 2 years ago by dkrenn

Replying to vbraun:

The dependency needs to be a ticket number...

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

comment:14 Changed 2 years ago by vbraun

  • Branch changed from u/dkrenn/t/22142 to c252b4d618c190c94acbc55a74bb3415a62fd7b6
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.