Opened 3 years ago

Last modified 3 years ago

#25527 new defect

missing wrappers in ComplexBallField

Reported by: zimmerma Owned by:
Priority: major Milestone: sage-8.3
Component: basic arithmetic Keywords:
Cc: ​fredrik.johansson, mmezzarobba Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description

With Sage 8.2:

sage: C=ComplexBallField(100)
sage: C.integral(lambda x,_:cosh(x),0,1)
...
TypeError: no canonical coercion from Real Field with 53 bits of precision to Complex ball field with 100 bits of precision

Same with sqrt and constants:

sage: C.integral(lambda x,_:sqrt(2),0,1)
...
TypeError: no canonical coercion from Symbolic Ring to Complex ball field with 100 bits of precision

Change History (7)

comment:1 Changed 3 years ago by fredrik.johansson

  • Cc mmezzarobba added

comment:2 Changed 3 years ago by fredrik.johansson

It looks like all the ordinary (cosh, sinh, tanh, coth) hyperbolic functions are missing.

Here is also a list of some other unwrapped functions, copied from an old email (this list is maybe slightly out of date):

  • arb_sec, arb_csc, arb_sech, arb_csch, acb_sec, acb_csc, acb_sech, acb_csch
  • acb_expm1, arb_sinc, arb_sinc_pi, acb_sinc, acb_sinc_pi
  • arb_sgn, acb_sgn, acb_csgn
  • Lambert W function
  • Everything in the acb_elliptic module
  • Everything in the arb_hypgeom module
  • can_round methods
  • Fresnel integrals
  • Different versions of incomplete gamma functions
  • Incomplete beta function
  • arb_bernoulli_poly_ui, acb_bernoulli_poly_ui + bernoulli/euler/partition numbers
  • Real matrices (I didn't see if there was an issue for this already)
  • FFT
  • A lot of power series methods
  • Maybe _acb_vec_unit_roots
  • Dirichlet L-functions
  • Interface to hypergeometric 2F1 for parameters differing by integers

Also:

  • acb_real_abs, acb_real_sgn, acb_real_heaviside, acb_real_floor, acb_real_ceil, acb_real_max, acb_real_min, acb_real_sqrtpos

comment:3 in reply to: ↑ description Changed 3 years ago by mmezzarobba

Yes, there are still a number of functions missing—but I'm not sure it makes sense to open tickets about that unless you are planning to add the necessary wrappers.

However, this:

Replying to zimmerma:

Same with sqrt and constants:

sage: C.integral(lambda x,_:sqrt(2),0,1)
...
TypeError: no canonical coercion from Symbolic Ring to Complex ball field with 100 bits of precision

is intentional. What you should be doing is:

sage: CBF.integral(lambda x, _: CBF(2).sqrt(), 0, 1)
[1.414213562373095 +/- 2.99e-16]

of if you really want to use the global sqrt() function:

sage: CBF.integral(lambda x, _: sqrt(CBF(2)), 0, 1)
[1.414213562373095 +/- 2.99e-16]

comment:4 follow-up: Changed 3 years ago by zimmerma

Marc, please could you explain why it is intentional? And for example why the constant 2 does not need to be explicitly converted to CBF in the following?

sage: CBF.integral(lambda x, _: sqrt(x+2), 0, 1)
[1.57849254104856 +/- 2.25e-15]

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

Replying to zimmerma:

Marc, please could you explain why it is intentional? And for example why the constant 2 does not need to be explicitly converted to CBF in the following?

sage: CBF.integral(lambda x, _: sqrt(x+2), 0, 1)
[1.57849254104856 +/- 2.25e-15]

Because 2 is an element of ZZ, which coerces into CBF, so that x + 2 returns an element of CBF, and then sqrt() of an element of CBF returns an element of CBF. Whereas sqrt(2) returns an element of SR, which does not (and should not) coerce into CBF.

comment:6 follow-up: Changed 3 years ago by fredrik.johansson

That also goes for I (it would be so much nicer if such constants by default lived in QQbar or something like it instead of SymbolicRing...).

comment:7 in reply to: ↑ 6 Changed 3 years ago by mmezzarobba

Replying to fredrik.johansson:

That also goes for I (it would be so much nicer if such constants by default lived in QQbar or something like it instead of SymbolicRing...).

It has been a plan for a long time to bind the global I to an element of ℚ[i] (see #18036), but there were backward compatibility concerns and perhaps other issues... I'll probably try reviving that ticket one day, though.

Note: See TracTickets for help on using tickets.