Hi, I am trying to solve a inequality as is demonstrated at
http://code.google.com/p/sympy/issues/detail?id=1646#c22. Aaron's
output was
In [3]: x = Symbol('x', real=True)
In [4]: e = Le(x**2, 2)
In [5]: solve(e, x)
Out[5]:
⎡⎡ ⎽⎽⎽⎽⎽⎽⎤⎤
⎣⎣-╲╱ 2 , ╲╱ 2 ⎦⎦
However, I am not able to get this ni
Thank you, this version works. (Now I have to find out to which extent
the inequalities can be solved; it seems to me that many functions
have to be converted to MacLaurin series before. Moreover, it would be
handy to convert inequalities to an interval.)
--
You received this message because you
On Nov 18, 7:02 pm, Mateusz Paprocki wrote:
> it can be easily extended
> to support rational functions and absolute values (somewhere I have
> preliminary code for this).
Cool. Right now I am using sympy to solve some calculations for
geometrical optics. These problems boiled down to a system
I observe following behavior:
In [113]: solve([Le((-1 + x),(-2 + x+x**3)), Assume(x,Q.real)], x,
relational=False)
Out[113]: [[1, ∞)]
In [114]: solve([Le((-1 + x)/(-2 + x+x**3),1), Assume(x,Q.real)], x,
relational=False)
NotImplementedError (...)
But there is a workaround: one must put th
fraction using together().
Btw: maybe the function should behave as if relational was set to
False by default; what do you think?
On Nov 18, 9:15 pm, Mateusz Paprocki wrote:
> Hi,
>
>
>
>
>
>
>
>
>
> On Thu, Nov 18, 2010 at 11:51:59AM -0800, Filip Dominec wrote:
I am working on a new solve() routine to fix the issue discussed in my
previous post.
However, I observed a bug (?) that sticks deep in the code. I am using
the "git clone https://matt...@github.com/mattpap/sympy-polys.git; cd
sympy-polys ; git checkout polys11" version.
In [388]: solve([Le(3,
Now it is possible to calculate for example this:
In [451]: SolveFractionIeq((2*x-1)/(x-1), (2*x-1)/x, x)
Out[451]: [[1/2, 1], (-∞, 0]]
... which is almost correct if we omit the closedness of intervals
(somebody fixes?).
Note that the aforementioned UnboundLocalError in inequalities.py
prevents
gt; Aaron Meurer
>
>
>
>
>
>
>
> On Wed, Nov 24, 2010 at 3:12 AM, Filip Dominec
> wrote:
> > I am working on a new solve() routine to fix the issue discussed in my
> > previous post.
>
> > However, I observed a bug (?) that sticks deep in the code.
This issue makes me to think about renaming the simpify function to
something more different from simplify. Possible candidates could be
parse_expression, str2sympy, str2expr etc.
The similarity between "simpify" and "simplify" is misleading.
On 6 pro, 12:45, prem kiran wrote:
> ya go it.THANKS
> After thinking about it for a while, I think you are right, we should
> probably keep both.
It is a good idea, and then we shall state it explicitly that S() is
just an alias. Remember the words of prophet:
Explicit
is better than implicit,
there should be one
and preferably only one
Alternatively we may leave sympify untouched and use 'simple()'
instead of 'simplify()'. I write this function quite often and every
byte counts.
Filip
On 6 pro, 22:05, Ondrej Certik wrote:
> On Mon, Dec 6, 2010 at 11:29 AM, smichr wrote:
> >> The similarity between "simpify" and "simplify" is m
You may also add the function for solving inequalities, which I posted
here: http://groups.google.com/group/sympy/msg/614f244c8e46fb03
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sy...@googlegroups.com.
To unsub
In my opinion the best way would be if some branch-maintainer reviewed
the contributions and added them in one branch manually.
I admit that this needs somebody to spend some time testing, but I
consider it the only way to keep the codes clean and to encourage
people to contribute. It is important
13 matches
Mail list logo
