> input_set = imageset((x, y), x**2 + y**2 < 1, S.Reals*S.Reals))
Note that sets doesn't work this way, we don't take booleans. I'm actually
pretty sure you know this already, I just want to show off how sets works
to others.
Instead you could do the following
In [4]: unit_disk = imageset(Lambda((r, theta), (r * cos(theta), r *
sin(theta))), Interval(0, 1) * Interval(0, 2*pi))
In [5]: unit_disk
Out[5]: {(r⋅cos(θ), r⋅sin(θ)) | r, θ ∊ [0, 1] × [0, 2⋅π]}
In [6]: (0.5, 0.5) in unit_disk
Out[6]: True
In [7]: (0.5, 2) in unit_disk
Out[7]: False
On Sun, Mar 16, 2014 at 1: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?
>
> > - 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
>
> > - 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 ..."
>
>
> > Do the radical denesting algorithms
> > work with symbolic entries as well?
>
> I don't think so.
>
>
> > - 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.
>
>
> --
> 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<https://groups.google.com/d/msgid/sympy/CADN8iuq9aVesJzFFE0wpG9_eJd6C7RW-7Lb%2BRZ3OHA4AXP1yXA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> 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-HTS06kmDxZORpv8nNQP2mVZ2-phnjSyK1Rjik%2BVaa_ZQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
