On Sun, Mar 16, 2014 at 2:27 PM, Matthew Rocklin <mrock...@gmail.com> wrote:
> S.Integers._contains(self, other) just calls ask(Q.integer(other))
It should raise an exception when ask() returns None.
>
> S.Reals is actually just Interval(-oo, oo). Interval._contains depends on
> the < and > operators. It returns true because the following return true
> In [9]: x < oo
> Out[9]: True
>
> In [10]: x > -oo
> Out[10]: True
It would be better to use ask and Q.real. The inequalities let you put
complex variables in them, because otherwise it would be annoying to
have to always use x = Symbol('x', real=True). But it leads to
incorrect results in this case.
By the way, I didn't know that the sets use exclusively the new
assumptions (assuming that is indeed what you are saying here). Given
what I've seen in the new assumptions, I'm not so sure this is such a
hot idea (namely, the handlers have a ton of mathematical
inaccuracies), but it's nice that they actually are used anywhere
nonetheless.
Aaron Meurer
>
>
>
> On Sun, Mar 16, 2014 at 11:14 AM, Aaron Meurer <asmeu...@gmail.com> wrote:
>>
>> On Sun, Mar 16, 2014 at 3:06 AM, Harsh Gupta <gupta.hars...@gmail.com>
>> wrote:
>> >> - Your example
>> >>
>> >> In[]: soln = solve(sin(x)*sin(y), (x, y), input_set = Interval(0,
>> >> 4)*Interval(0, 4))
>> >>
>> >> is a bit confusing to me. The input_set argument gives a 2-dimensional
>> >> set, but how are you to know which axis is x and which is y?
>> >
>> > The axis is determined by the order of variables in which they appear in
>> > the
>> > argument of solve. Defining the input set in this way will give us
>> > special
>> > advantage of being able to take values from the sets which are
>> > traditionally
>> > hard to define. For example if we want the variable to come from a
>> > circle we
>> > can do it like.
>> >
>> > In[]: solve(f(x, y), (x, y), input_set = imageset((x, y), x**2 + y**2 <
>> > 1,
>> > S.Reals*S.Reals))
>> >
>> > For a L shape domain we can do
>> >
>> > In[]: solve(f(x, y), (x, y), input_set = Intersection(Interval(0,
>> > 2)*Interval(0, 3), Interval(1, 2)*Interval(1, 3))
>> >
>> > I cannot be sure that sets will be able to seamlessly handle such sets,
>> > but
>> > I really think this API will scale.
>> >
>> >> What about the input API?
>> >>
>> >> solve(f, *symbols, dict=False, set=False, exclude=(), check=True,
>> >> numerical=True, minimal=False, warning=False, simplify=True,
>> >> force=False, rational=True, manual=False, implicit=False,
>> >> minimal=False, quick=False)
>> >
>> > I think most of the flags are not needed. The flags like `dict` and
>> > `set`,
>> > won't be need as we
>> > are unifying the output to set. Do we have any estimate of how many of
>> > these
>> > flags are actually used by users?
>>
>> Quite a few people use dict=True, as that's the recommended format to
>> get a consistent result. As with any public API, we'd have to
>> deprecate it before removing it.
>>
>> What about the other flags? And what about the dozen linear solvers? I
>> don't expect you to have the right answers now these things this (I'm
>> not even sure myself what should be done about them), but you should
>> be thinking about them.
>>
>> >
>> >> - You talk a lot about using sets, which I think is a good idea. But
>> >> you should think about how you can also use the assumptions. Maybe
>> >> there is a clean way that we can go back and forth between assumptions
>> >> and sets that requires minimal code duplication, and also allows each
>> >> to take advantage of the algorithms implemented in the other (by the
>> >> way, when I say assumptions, you should probably only worry about the
>> >> new assumptions, i.e., the stuff in the Q object).
>> >
>> > As mentioned in the comment by Matthew
>> > https://github.com/sympy/sympy/pull/2948#issuecomment-36592347
>> > Assumptions can answer questions like if k is in N, is k*(k+1)/2 in N?
>> > This
>> > will
>> > clearly help in resolving some of the set operations. btw I think
>> > assumptions
>> > is wrong in this result.
>> >
>> > In [20]: with assuming(Q.integer(k/2)):
>> > ...: print(k in S.Integers)
>> > ...:
>> > False
>>
>> The problem is that we always return an answer with __contains__. This
>> has nothing to do with the assumptions, but rather the sets module.
>> __contains__ should raise an exception if it can't determine (note
>> that Python forces "in" to always return a boolean, so we can't return
>> anything symbolic).
>>
>> But beyond that, I don't think the sets use the new assumptions at all
>> (correct me if I am wrong).
>>
>> I also noticed this:
>>
>> In [32]: S.Reals.contains(x)
>> Out[32]: True
>>
>> (x is just Symbol('x')).
>>
>> >
>> >> - How will we handle that situation (finding all solutions)? What if
>> >> we can't say anything? Can we still represent objects in such a way
>> >> that it is not wrong (basically by somehow saying, "here are 'some' of
>> >> the solutions, but maybe not all of them", and ditto for anything that
>> >> uses solve, like singularities)? Maybe Piecewise is sufficient
>> >> somehow?
>> >
>> > We will return a set as a solution if and only if we have found all the
>> > solutions in the given domain. For every other case we will be using the
>> > unevaluated Solve object. We will have a attribute in the unevaluated
>> > solve
>> > named "know_solutions" to say "here are some solutions". Yes Picewise
>> > might
>> > be
>> > helpful, but for now I can't think of a clear way to say "assuming this
>> > parameter 'a' is positive
>> > the solutions are ..."
>>
>> I guess one idea would be to union the set with some "additional
>> solutions" set, for which not much is known about. So the result, in
>> the case where we don't know if we have all the solutions, would be
>>
>> SolutionSet U NotFoundSolutions
>>
>> Then things that use the solutions like discontinuities would
>> propagate the union (discontinuities should return a Set object too
>> btw).
>>
>> The unknown solutions set may have properties known, even if its exact
>> cardinality isn't. For instance, the zero set of a continuous function
>> is always closed.
>>
>> >
>> >
>> >> Do the radical denesting algorithms
>> >> work with symbolic entries as well?
>> >
>> > I don't think so.
>>
>> So in that case, one should try to improve the solvers themselves to
>> return simpler answers in the first place, if possible.
>>
>> >
>> >
>> >> - Did you plan to add any new solvers? I think there are still quite a
>> >> few cases that we can't solve. Some higher degree irreducible
>> >> polynomials for instance (not all higher degree polynomials are
>> >> solvable by radicals but some are). There will also be a lot to
>> >> implement once we are able to even represent the solutions to
>> >> sin(x)=0.
>> >
>> > There was one algorithm
>> > I discussed on the discussion
>> > https://github.com/sympy/sympy/pull/2948#issuecomment-36970134.
>> > By that algo we will be able to solve some special cases like
>> > `sin(x) == x`. I will implement that and we might come up with new
>> > algorithm
>> > in the
>> > process of rewriting current solvers. If time permits I'll surely try to
>> > implement new solvers.
>>
>> As I noted before, algorithms that just extend what is already there
>> should go at the end of the timeline. But algorithms that will provide
>> motivating examples for the solve API should be implemented sooner, at
>> least in part.
>>
>> (p.s. don't forget to be updating your proposal with ideas from this
>> discussion)
>>
>> Aaron Meurer
>>
>> >
>> >
>> > --
>> > 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 post to this group, send email to sympy@googlegroups.com.
>> > 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/CADN8iuq9aVesJzFFE0wpG9_eJd6C7RW-7Lb%2BRZ3OHA4AXP1yXA%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 sympy+unsubscr...@googlegroups.com.
>> To post to this group, send email to sympy@googlegroups.com.
>> 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%3D6JtpThrtt7TVqJ162gNO0qepP_hf%3DKcARRaGdCEST%3Dkww%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 sympy+unsubscr...@googlegroups.com.
> To post to this group, send email to sympy@googlegroups.com.
> 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-E9B1uFoqw2_FTRxkJcm7jNk%3DM8NdKkco8bzsx3tYae5A%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 sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
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%3D6Kw671B%2B4XKcyV%2BeMLY3gffy%3DGqiAKrqVwjOEswXnRS6A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
