On Tue, May 18, 2021 at 6:28 AM Oscar Benjamin
wrote:
> > > and more difficult error analysis.
> >
> > I don't understand what you mean by "error analysis", unless you're
> > referring to performance degradation due to Fraction propagation.
>
> The error analysis for arithmetic with Fraction is
Christopher Barker writes:
> sure -- but the error analysis is harder for computations that use a
> mixture of Fraction and float, and it's not obvious where which is
> used.
I don't understand what the problem is. Fractions are just a field of
computer numbers where all the computations give
Martin Teichmann writes:
> Also in this case my proposal would give SymPy the chance to
> understand what the user actually entered, and act accordingly.
But *only* in this case. It seems to me that what SymPy would really
like is for arithmetic expressions in certain contexts to be returned
a
Matt del Valle writes:
> Fully agreed on the sentiment that we shouldn't treat compile-time
> literals differently from runtime operations.
But as you just pointed out, we do. Literals are evaluated at compile
time, operations at runtime. "This" and f"This" generate very
different code! Ther
Martin Teichmann writes:
>
> > Also in this case my proposal would give SymPy the chance to
> > understand what the user actually entered, and act accordingly.
>
I am sorry, but could you point out an open issue or discussion by
developers on SymPy repository or a forum where such a feature has b
