✅

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:

• parsing

  • Latex parser supports \lg as base 10 log defined in ISO 80000-2:2019 (#23618 by @eagleoflqj)

  • BREAKING: \log is parsed as base E to be consistent with printer default (#23618 by @eagleoflqj)

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

<!-- 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

Simply add \lg.
#### 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 -->
* parsing
  * Latex parser supports \lg as base 10 log defined in ISO 80000-2:2019
  * BREAKING: \log is parsed as base E to be consistent with printer default
<!-- END RELEASE NOTES -->

Update

The release notes on the wiki have been updated.

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
     [77f1d79c]       [7b38d1d8]
     <sympy-1.10.1^0>                 
+         110±1ms          199±3ms     1.81  sum.TimeSum.time_doit

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

Doesn't lg usually mean the base 2 logarithm?

There seems to be an ISO standard https://en.m.wiktionary.org/wiki/lg#Usage_notes but it’s not widely used in English-language literature. I learned it to be base 10 in China.

I also find this confusing

as our latex printer uses log as base E

log can mean either base-10 or base-e depending on the context. We should probably default to e since SymPy does. I've honestly never seen anyone actually use lg.

I think we can provide some config like log_base and lg_base to parse_latex.

Ideally we'd be using a parser that is way more user customizable an runtime extensible than the current one, to the point that having specific options like that would be unnecessary.

For instance, could we have a parser where the flag can be something along the lines of parse_latex(funcs={r'\lg': lambda x: log(x, 2)}), where funcs is a mapping that lets you define or redefine any latex name.

parse_latex(funcs={r'\lg': lambda x: log(x, 2)})

If the purpose is restricted to "for FUNCTION patterns that are already defined in LaTeX.g4, use a mapping to control the parser", then I believe it's doable.

My point is just that we shouldn't lock ourselves into any public customization APIs for parse_latex if we are likely to switch to another parser in the future which would have much more general customizability.

If a new parser can't handle simple configuration, I doubt whether it's worth to switch.
I think ANTLR is good enough, as it is easy to use. It has a simple DSL and the API is not confusing. I didn't read any its documentation to be able to work on it.

Can the ANTLR parser be extended at runtime?

I'm also not a fan of the way the ANTLR parser pins to a specific version of the runtime. That makes it harder for people to install it in an environment where something also also depends on the runtime.

I think that the change is OK, but that the release note probably can be expanded to clarify what the different options are, i.e., which "log"-command is using what base.

Does this support providing a base? Yes, it does.

Can the ANTLR parser be extended at runtime?

I don't think so.
What I understand the biggest problem of our latex parser is it doesn't have a way to handle ambiguity like a(b+c). Maybe there's a way to fix it in without changing the parser, but a new candidate should be able to solve that in a more elegant way.