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:  sage7.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 )
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 followup: ↓ 4 Changed 3 years ago by
comment:2 Changed 3 years ago by
 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
 Dependencies set to pynac0.7.4
 Description modified (diff)
comment:4 in reply to: ↑ 1 ; followup: ↓ 5 Changed 3 years ago by
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
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
For completeness, I mention the sagedevel thread on gamma(QQbar(...))
comment:7 Changed 2 years ago by
 Branch set to u/dkrenn/t/22142
comment:8 Changed 2 years ago by
 Commit set to ce935868b2a537cd631d182008dc87ded02f6082
 Dependencies changed from pynac0.7.4 to #22219 pynac0.7.4
 Status changed from new to needs_review
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

comment:9 Changed 2 years ago by
 Commit changed from ce935868b2a537cd631d182008dc87ded02f6082 to c252b4d618c190c94acbc55a74bb3415a62fd7b6
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
c252b4d  doctests for #22142

comment:10 Changed 2 years ago by
 Reviewers set to Ralf Stephan
 Status changed from needs_review to positive_review
Is fine modulo the dependency.
comment:11 followup: ↓ 13 Changed 2 years ago by
 Status changed from positive_review to needs_work
The dependency needs to be a ticket number...
comment:12 Changed 2 years ago by
 Dependencies changed from #22219 pynac0.7.4 to #22219
 Status changed from needs_work to positive_review
comment:13 in reply to: ↑ 11 Changed 2 years ago by
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
 Branch changed from u/dkrenn/t/22142 to c252b4d618c190c94acbc55a74bb3415a62fd7b6
 Resolution set to fixed
 Status changed from positive_review to closed
I have a Pynac patch that does this:
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?