Better eval for beta

[oscargus]

References to other Issues or PRs

Brief description of what is fixed or changed

Added a few more cases for evaluating beta.

Other comments

Release Notes

• functions
  • beta evaluates directly for more cases.

[sympy-bot]

✅

Hi, I am the SymPy bot (v167). I'm here to help you write a release notes entry. Please read the guide on how to write release notes.

Your release notes are in good order.

Here is what the release notes will look like:

• functions
  • beta evaluates directly for more cases. (#23934 by @oscargus)

This will be added to https://github.com/sympy/sympy/wiki/Release-Notes-for-1.12.

Click here to see the pull request description that was parsed.

<!-- Your title above should be a short description of what
was changed. Do not include the issue number in the title. -->

#### References to other Issues or PRs
<!-- If this pull request fixes an issue, write "Fixes #NNNN" in that exact
format, e.g. "Fixes #1234" (see
https://tinyurl.com/auto-closing for more information). Also, please
write a comment on that issue linking back to this pull request once it is
open. -->


#### Brief description of what is fixed or changed

Added a few more cases for evaluating `beta`.

#### Other comments


#### Release Notes

<!-- Write the release notes for this release below between the BEGIN and END
statements. The basic format is a bulleted list with the name of the subpackage
and the release note for this PR. For example:

* solvers
  * Added a new solver for logarithmic equations.

* functions
  * Fixed a bug with log of integers.

or if no release note(s) should be included use:

NO ENTRY

See https://github.com/sympy/sympy/wiki/Writing-Release-Notes for more
information on how to write release notes. The bot will check your release
notes automatically to see if they are formatted correctly. -->

<!-- BEGIN RELEASE NOTES -->
* functions
   * `beta` evaluates directly for more cases.
<!-- END RELEASE NOTES -->

Update

The release notes on the wiki have been updated.

[asmeurer]

I'd like to think more about avoiding automatic evaluation based on assumptions and symbolic identities, preferring to have those in doit and other simplification methods instead (see the discussion here https://docs.sympy.org/dev/guides/custom-functions.html#best-practices-for-eval). I know this is something that we aren't doing a good job of right now, but we should try to move in that direction.

So how do you feel about only evaluating these cases when they are explicit numbers (which are the only things you added tests for anyway), and moving the more fully symbolic cases to doit (I'm referring specifically to the last two cases you added here)?

[oscargus]

Sure!

I'm actually thinking that in general one may not always want automatic evaluation for numbers either, only for "trivial" (however that is defined...). There are e.g. the often very useful trigonometric evaluation tables that one may not always want. So going in the direction of moving more time-consuming and/or symbolic evaluation to doit surely makes sense.

[oscargus]

This opens up some questions about how to deal with this in general, especially when evaluate=False to start with. Once we use _eval_doit one should probably do an eval first in that?

Also found a printing issue with LaTeX (didn't check the other printers though...).

[oscargus]

pprint works, but code generation relying on rewriting doesn't, with evaluate=False and single argument. Not sure it is a problem though.

[asmeurer]

Ideally there should be so little automatic evaluation that evaluate=False isn't even necessary. But for things like this, you typically have the same identity in eval and doit, where the eval version applies only for Rational and doit applies it to any symbolic input. So maybe a good pattern is to just implement the general case in doit, and have eval call doit when the inputs are Rational. Or otherwise split it out into a separate helper method so it isn't duplicated.

[oscargus]

I used this pattern now, having all the actual eval in doit and calling it if both arguments are Numbers. This changes so that direct evaluation of e.g. beta(1, y) does not automatically evaluate to 1/y. Easily changed to just put an or instead of and in eval.

This particular function becomes a bit messy as it must support one or two arguments, but apart from that I believe that this is probably a quite good pattern.

[oscargus]

For some functions, such as lerchphi one would probably also want to involve expand_func in doit. For numerical arguments, expand_func, gives a plain numerical output for lerchphi.

[asmeurer]

Maybe we should think of ways to make this pattern easier in the Function superclass, like having a special eval method that only evaluates on Rational inputs and isn't even called on symbolic inputs. See also #23701.

[github-actions]

Benchmark results from GitHub Actions

Lower numbers are good, higher numbers are bad. A ratio less than 1
means a speed up and greater than 1 means a slowdown. Green lines
beginning with + are slowdowns (the PR is slower then master or
master is slower than the previous release). Red lines beginning
with - are speedups.

Significantly changed benchmark results (PR vs master)

Significantly changed benchmark results (master vs previous release)

       before           after         ratio
     [41d90958]       [7135ae37]
     <sympy-1.11.1^0>                 
-         959±2μs          614±1μs     0.64  solve.TimeSparseSystem.time_linear_eq_to_matrix(10)
-     2.80±0.01ms         1.15±0ms     0.41  solve.TimeSparseSystem.time_linear_eq_to_matrix(20)
-     5.64±0.01ms         1.68±0ms     0.30  solve.TimeSparseSystem.time_linear_eq_to_matrix(30)

Full benchmark results can be found as artifacts in GitHub Actions
(click on checks at the top of the PR).

[oscargus]

I rebased.