We will have to be "very" careful while rewriting the solvers. I just came
across another of Professor Fateman's paper which describes why the
solution of z**w == y for z isn't simply y**(1/w).

http://www.cs.berkeley.edu/~fateman/papers/y=z2w.pdf

Sadly we doing it wrong.

We are also wrongly simplifying y - (y**(1/(1 + I)))**(1 + I) as 0.

In [58]: f

Out[58]: y - (y**(1/(1 + I)))**(1 + I)


In [59]: simplify(f)

Out[59]: 0




On 17 March 2014 16:39, Harsh Gupta <[email protected]> wrote:

> >> We won't be able to support such output with our new output API
> >> assert solve(x - exp(x), x, implicit=True) == [exp(x)]
>
> > How is this implemented?
>
> I read the code and it appears.
> Things like exp(x) are replaced by dummy symbols and then solve is allowed
> to run on it. After the solution is obtained the dummy symbols are replaced
> back with their original values.
>
>
>
> On 17 March 2014 05:53, Aaron Meurer <[email protected]> wrote:
>
>> Looking through my notes
>> (https://github.com/sympy/sympy/wiki/assumptions_handlers, pardon the
>> formatting; it looks better in emacs), I see that most of the wrong
>> results I saw were not in the "core" facts, like positive or real
>> (other than the ones you probably already knew about with infinities
>> https://github.com/sympy/sympy/issues/5976). It looks like most of the
>> blatant wrong results that I found were in ntheory (and yes, I am
>> guilty of not ever opening issues for these things)
>>
>> In [2]: ask(Q.prime(x*y), Q.integer(x)&Q.integer(y))
>> Out[2]: False
>>
>> In [3]: ask(Q.prime(x**y), Q.integer(x)&Q.integer(y))
>> Out[3]: False
>>
>> In [6]: ask(Q.integer(abs(x)), ~Q.integer(x))
>> Out[6]: False
>>
>> I leave it as an exercise to the reader why each of the above is
>> incorrect.
>>
>> But more to the point, as I noted in at the bottom of that wiki page,
>> the new assumptions handlers code is very fragile. If you accidentally
>> use the wrong kind of Python logic instead of fuzzy logic, you can
>> return False instead of None. In the best case, you just end up not
>> implementing as much as you thought you were, but in the worst case,
>> you get a wrong result.
>>
>> There are subtle issues that can come up (similar to the
>> https://github.com/sympy/sympy/issues/5976 one) with the new
>> assumptions not being consistant in how it defines assumptions. It
>> doesn't help that it quite often calls out to some external routine to
>> calculate something, which may or may not use the same definition of
>> the assumption that it does. It also uses evalf on most assumptions
>> relating to numbers, which can have its own issues.
>>
>> Aaron Meurer
>>
>> On Sun, Mar 16, 2014 at 5:32 PM, Matthew Rocklin <[email protected]>
>> wrote:
>> > Recall that sets mostly lives in the core.  In particular I think that
>> > Interval and maybe Union have been used in the core for some time and
>> > FiniteSet has made itself useful in the last couple years.
>> >
>> >
>> > On Sun, Mar 16, 2014 at 3:31 PM, Matthew Rocklin <[email protected]>
>> wrote:
>> >>
>> >> > By the way, I didn't know that the sets use exclusively the new
>> >> > assumptions (assuming that is indeed what you are saying here).
>> >>
>> >> That is not what I'm saying.  S.Integers and S.Naturals use new
>> >> assumptions.  Most of the logic behind core sets doesn't explicitly
>> think
>> >> about assumptions at all.  So, perhaps worse, sets implicitly uses some
>> >> combination of the two.
>> >>
>> >>
>> >> On Sun, Mar 16, 2014 at 2:16 PM, Harsh Gupta <[email protected]>
>> >> wrote:
>> >>>
>> >>> Sorry I accidently pushed Send, ( I was unconsciously entering some
>> vim
>> >>> commands). Ignore the "For" after the example.
>> >>>
>> >>> --
>> >>> Harsh
>> >>>
>> >>> --
>> >>> 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 [email protected].
>> >>> To post to this group, send email to [email protected].
>> >>> Visit this group at http://groups.google.com/group/sympy.
>> >>> To view this discussion on the web visit
>> >>>
>> https://groups.google.com/d/msgid/sympy/CADN8iupYZiJoBNQxCiAtg0Y-bXF1fNs2PbQtdh9qvYd765L7Sw%40mail.gmail.com
>> .
>> >>>
>> >>> For more options, visit https://groups.google.com/d/optout.
>> >>
>> >>
>> >
>> > --
>> > 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 [email protected].
>> > To post to this group, send email to [email protected].
>> > Visit this group at http://groups.google.com/group/sympy.
>> > To view this discussion on the web visit
>> >
>> https://groups.google.com/d/msgid/sympy/CAJ8oX-FnZjs4vfBFh%3D2WtMvRdaEM-ndNW%2BqL-rNk5EYQhQ3hVQ%40mail.gmail.com
>> .
>> >
>> > For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> 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 [email protected].
>> To post to this group, send email to [email protected].
>> Visit this group at http://groups.google.com/group/sympy.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/sympy/CAKgW%3D6L5k4Lvep%3DjVvLPbU6JW%3DMrwsrLsV%2Bq3hAFBQr7XDFdoA%40mail.gmail.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Harsh
>



-- 
Harsh

-- 
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CADN8iuocY12bhYgSFkYZCK82jaw1%3D5FGAHFTNoR86ZBuQ9cR9Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to