fast_callable improvements (followup for #5093)

[robertwb]

The code at #5093 is very good and ready to go in, but there are several improvements that have been suggested and agreed work on at a later date. They are posted here so we can merge and close the other ticket.

Specifically, this ticket addresses these issues:

• fast_callable on list, tuple, vector, matrix arguments

• fast_callable on constant arguments

• fast_callable of a zero multivariate polynomial returns a zero of the base ring, without paying attention to the types of the arguments

• in general replaces calls to fast_float with calls to fast_callable.

• Carries out the deprecation in deprecate substitution via __call__ w/ unnamed arguments #5413 (removes the functionality deprecated there)

• fast_float sometimes returns symbolic values instead of floating-point values (see density_plot() is broken with functions involving symbolic expressions #17684, which patches density_plot to work around this bug)

Because of some of the far-reaching changes, this should probably not be merged in a point-point release.

What is not fixed:

• Robert's suggestion: an option that uses a fast domain, if it's there, but ignores the domain parameter if it's not (I don't mind the idea, and the implementation is easy; what should the syntax be? Part of my problem picking a syntax is that I don't want to promise that a specialized interpreter is always faster than the Python-object interpreter, so I don't particularly want to use the word "fast" in any option names.)

The work on this ticket:

• Makes intermediate complex expression in real functions make many plot functions fail #8450 easy, probably
• Makes fast_callable should respect the variable order in callable symbolic expressions (treating them like lambda functions rather than like expressions) #7512 invalid, probably

See also

• bug with fast_float, imag and sqrt : NotANumber isn't fine. #10087
• sage fails to plot a quarter circle when it should #7165
• fast_callable always segfaults when input is a polynomial of large degree #11766 -- rewrite some of fast_callable to have its own recursion stack

CC: @robertwb @TimDumol @eviatarbach @novoselt @orlitzky

Component: basic arithmetic

Author: Jason Grout

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

[jasongrout]

comment:2

More fast_callable improvements:

• domain=float is the same as domain=RDF, but domain=complex is not the same as domain=CDF. Make domain=complex use the same interpreter as domain=CDF

• if g is a callable expression, then fast_callable(g) should use g.args() for the variables, not g.variables(). Hmm...or maybe return an error if g.args() is not equal to g.variables(), since every variable really does have to be satisfied.

[robertwb]

comment:3

Both good points. At least g.variables() should be a subset of g.args().

[jasongrout]

comment:4

Replying to @jasongrout:

• if g is a callable expression, then fast_callable(g) should use g.args() for the variables, not g.variables(). Hmm...or maybe return an error if g.args() is not equal to g.variables(), since every variable really does have to be satisfied.

#7512 may take care of this.

[jasongrout]

comment:5

Attachment: improve_fast_callable.patch.gz

This is a big patch to fast_callable which

• makes it work for lists/tuples like fast_float does
• adds lots of _fast_callable_ methods to make it work on a lot of different constant objects (integers/rationals/RDF/RR/CDF/CC)
• refactors the code a bit
• in general replaces calls to fast_float with calls to fast_callable.

The patch also breaks some things---it's still a work in progress.

[jasongrout]

Attachment: fast_callable_complex.patch.gz

apply on top of previous patch

[jasongrout]

comment:6

The second patch is a broken attempt at streamlining the complex support since Cython now supports C99 complex numbers.

[jasongrout]

comment:8

CCing: robertwb since fast_float was his idea originally

timdumol since he's expressed interest in working on this sort of thing.

The two patches need work at this point. In particular, the improvements patch needs docs added/changed, and ptestlong needs to be run to check for breakage.

The complex number patch needs an overhaul, as I think it's completely broken at this point. The complex number patch is not necessary for resolving the issues on this ticket.

[jasongrout]

comment:9

#8450 would be a good ticket to (trivially) fix after this ticket moves plotting solely over to fast_callable.

[jasongrout]

rebase to 4.4.1