If you compare H.factor() and H1.factor(), you will see that there are
factors in the numerator and denominator that should cancel out. The
issue is that SymPy has issues doing polynomial division with floating
point coefficients. Due to their inexact nature, SymPy has to guess if
a polynomial expression should cancel or not when they are present,
and the logic for doing this isn't as good as it should be. With
rational coefficients, this problem doesn't exist because the
arithmetic is all exact.
To be clear, I do think SymPy should be able to do a better job here,
but this isn't an easy problem to solve.
Aaron Meurer
On Fri, Jul 31, 2020 at 12:46 PM Oscar Benjamin
<oscar.j.benja...@gmail.com> wrote:
>
> On Fri, 31 Jul 2020 at 17:26, Mikhael Myara
> <mikhael.my...@umontpellier.fr> wrote:
> >
> > Thanks for your answer.
> >
> > I don’t do it « for sport » ;-) My example is a reduced example coming from
> > a practical situation I encountered.
>
> I understand that you have reduced this but it is a lot better if the
> reduction is self-contained so that others can literally copy-paste
> the code to test what is happening with an expression that
> demonstrates the issue. I could probably tell you exactly what the
> problem is in a given example if you provided minimal code for that
> example.
>
> > Here it is :
> > I developed a small software that solves the voltages and currents of an
> > electronic circuit described by means of a standard format (« netlist »).
> > This file is parsed, equations are solved. In this netlist file, the values
> > of the components are given.
>
> How exactly are they given in the file (e.g. to how many digits)?
>
> If the file has something like 0.12 then you can read that in directly
> as Rational('0.12') rather than converting the string to a float. Then
> you will have an object that represents the value from the file
> exactly with no rounding error. Alternatively you can use nsimplify to
> convert the floats to an approximate rational representation (direct
> string to Rational is better though).
>
> > I imagined that I could mix symbolic and numerical values in the
> > description of the circuit (for example we want to study de variations of a
> > single component, not of all), and it seems to be a bad idea because mixed
> > expressions seem to be really difficult to handle for Sympy.
>
> Generally speaking simplification will work better with numbers rather
> than symbols. However this is only true if you give numbers in exact
> form. When you pass a float to sympy it will be treated as an
> inherently imprecise object. As a result many simplifications will be
> refused and also any arithmetic will be computed in floating point.
> The kind of simplification needed here is most likely factorisation
> and cancellation of polynomials which is poorly conditioned in
> floating point.
>
> > So I will have to make 100% symbolic treatment and then only replace the
> > values of the components. It was to explore the possibilities for my ?
> > students : this kind of question will help me giving to them good
> > orientations during classroom work.
>
> If the class work involves using sympy then good orientation would be
> to avoid the use of floats in symbolic computation.
>
> --
> Oscar
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sympy+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAHVvXxSYoquYGqOCdavwGnafPEb%3DnqWU-L8fK%3DYkYKSs8UR%3DrA%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAKgW%3D6%2BdpW_AJFoYZxGxrOBR0nV_WCTWQZiGC_Gg-7jo-G-qSA%40mail.gmail.com.
