Hmm, have there been API changes recently? With your branch, I'm not able
to check an Equality expression for the attribute is_Relational:
* from sympy import **
* from sympy.abc import x, y*
* Eq(x, y).is_Relational*
*Traceback (most recent call last):*
* File stdin, line 1, in module*
Bah, thank you. I had checked out Chris' repository, but had forgotten to
change branches.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To view this discussion on the web visit
https://groups.google.com/d/msg/sympy/-/C-_1H8aPEDUJ.
To post to this
Can you expand on why? To me the former reads better, and elides the need
to specifically import the Relational class:
* x.is_Relational*
*True*
vs
* from sympy.core.relational import Relational*
* isinstance(x, Relational)' reads better to me than 'isinstance(x,
Relational)*
Further, the
Excellent! For my simple test case, this now no longer goes over the 1000
recursion limit.
As an FYI, with your change, my models using Sympy now only use 45 levels
of recursion. (As tested by the if it broke test binary test.)
I really appreciate your work on this. Cheers!
--
You
Hullo List,
I have a fairly small expression (~500 variables). When I create a
Relation with it, Python informs me that Sympy has exceeded the max
recursion depth. Is there an intentional limit to expression sizes in
Sympy?
Please find attached a mini-script that highlights the issue I'm
:-( Bummer. In this context, I regularly work with expressions with
thousands (sometimes tens of thousands) of variables. They aren't highly
nested, with most terms having less than 5 levels, but there are lots of
them.
Thanks for letting me know.
--
You received this message because you
Having done a little debugging, I now can't produce a simple example like I
could so easily last night. Potentially a false alarm as I now suspect I
may have polluted SymPy's namespace somehow. (The same code in two
different instances of SymPy works and doesn't work.) I'll post when I
have
Okay, this is my fault, but I'm wondering if there's a way around it while
still using SymPy. Specifically, I want the ability to create an equation
with Python's == syntax. (I.e., I don't want to be forced to use the Eq()
method.)
At one point in my code, I have done this:
*from sympy
Heh, I appreciate your apparent faith in my coding skill. I'll take the
suggestion under advisement, but I'm more of an optimization feller than I
am an algebraic wiz. There would be a lot of learning I'd have to do of
the Sympy internals ...
--
You received this message because you are
Thank you for your pointers. I'll take them under advisement as I move
forward with my project.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To view this discussion on the web visit
https://groups.google.com/d/msg/sympy/-/8UeD91pTYGAJ.
To post to
Thanks for the heads up. I'll star the issue, as this would be good to be
aware of when it's fixed.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To view this discussion on the web visit
https://groups.google.com/d/msg/sympy/-/xwXw2u8H5b0J.
To post
Hullo Sympy Group,
I have a series of relations that I am receiving from an outside object and
code base. These equations are in no particular format, and I want to
convert them to one. At the moment, the end format I need is
format: lhs_expression [op] constant
example: 3x + 4y = 7
I
Mea culpa. I see now the difference you were trying to impart: Symbol (the
class) vs symbols (the function). Pardon me as I misstep more than a few
times while learning Sympy.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To view this discussion
Hullo Sympy Group,
How can I get Sympy to recognize 2+ inequalities in the same expression?
In mathematical optimization it is common to see (and often very
convenient to use) constraint expressions like these:
*3*x = 2*y +10 = 3*z*
*10*x = 15*y = 20*z = t*
Which are actually 2 and 3
Hmm, so I have some example code that I just threw together that implements
a multiple inequality. It isn't pretty in that I spent 5 minutes working
it, and it uses a global, etc., but it's a proof of concept:
-
*In [1]: a, b, c, d = test('A'), test('B'), test('C'), test('D')*
*
*
*In [2]:
Hullo Sympy Group,
In my code, I'd like to be able to specify symbols with a binary type,
something akin to:
* b = symbols('b', binary=True)*
This would let *b* assume only values from the set *{0, 1}*. I see the *
Boolean* class from which the *Symbol* class derives, but I believe that's
For this project, my end goal is to interface a series of Sympy equations
that I've built to an optimization solver. In the context of optimization,
binary variables usually represent a decision, and in the context of
solving, they represent a branch point. Branch points make it expensive
to
Hullo Sympy Group,
I'm wrapping some Sympy variables into a group via a class object. The
object is attached to another object, and from here, I'm able to collect
the name of the group (via *__setattr__*). Thus, I can have constructs
like this:
-
*M.X = Var()# Var is the wrapper
Err, is this perhaps a bug that has been fixed since the 0.7.1 release?
When I do that, vname can't have commas, else it creates multiple
variables:
-
*# For a mnemonic, here is an example variable from a model with which I'm*
*# working. The variable format is VarName[year, tech,
At 4:54pm -0600 Tue, 06 Jul 2010, Aaron S. Meurer wrote:
Or 3. Dump Python 2.4 and get rid of that function. :)
Right on.
I'm in the middle of trying to resurrect support for Python 2.4 right
now for a project. It's a pain, and frankly, I think my boss is on the
wrong track. Python 2.4 was
My previous post notwithstanding, you could also use the inspect
class, available since Python v2.1: http://docs.python.org/library/inspect.html
. I believe isfunction is what you want.
--
You received this message because you are subscribed to the Google Groups
sympy group.
To post to this
I tested with python 2.4 and 2.7rc2 (with -3).
FYI, 2.7 was released on Saturday! Yay!
--
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 unsubscribe from this group, send email to
Bastian,
Please start new threads, rather than hitting Reply in your mail
client and just changing the subject line. The message ids and
history information are still in the reply which messes up threading
for folks who read online, or for surfers after the fact. Reference
this very thread as a
Mathematically speaking, another way to think about it is this:
sqrt(x**2) != x (same reasoning, try x 0)
A little more generically:
sqrt(x**2) == norm(x) (2 norm of x)
You may (not) be interested in this wikipedia article:
http://en.wikipedia.org/wiki/Norm_(mathematics)
--
You received
Man, I'm late to this convo as I'm getting these emails all out of
thread order and at random times ... corporate filters rock.
On Jun 22, 12:25 am, William Ratcliff wrote:
I would go with multiprocessing rather than multithreading--processes are
weightier but there are no side effects
To
If you haven't programmed a multi-execution style algorithm before,
it's a bit of a mental leap. However, the thought process involved
with multi-threading vs multi-processing vs multi-machine scales.
There is a growing movement to teach college students and younger
folks to think in parallel
26 matches
Mail list logo
