Indeed if you do this:
mpmath.findroot(lambda xi: p.subs(x, Expr._from_mpmath(xi,
mpmath.mp.prec)), 1.0)
[That is, you manually construct sympy objects which reflect the
precision required by mpmath.]
On 27.05.2011 05:57, Mateusz Paprocki wrote:
Hi,
On 27 May 2011 06:31, Aaron S. Meurer m
I should have finished my sentence ... the way I show works.
On 27.05.2011 09:28, Tom Bachmann wrote:
Indeed if you do this:
mpmath.findroot(lambda xi: p.subs(x, Expr._from_mpmath(xi,
mpmath.mp.prec)), 1.0)
[That is, you manually construct sympy objects which reflect the
precision required by
Hi,
On 27 Mai, 03:21, Matthew Emmett wrote:
> I am having trouble combining mpmath's findroot function with sympy.
nsolve() is sympy's interface to mpmath's findroot(), it basically
does all the conversion stuff for you.
> I think that manipulation of mp.dps (or .prec) doesn't affect evalf (the
Does anyone have a better idea for how to canonicalize the args for
Add (perhaps Mul, too).
>>> from sympy.abc import *
>>> from sympy import *
>>> 3*x+6*y
3*x + 6*y
>>> _.args
(3*x, 6*y)
>>> (x+2*y).args
(2*y, x)
>>> (2*x+2*y+z).args
(2*y, z, 2*x)
>>>
On 27 Mai, 08:43, Chris Smith wrote:
> I think that with igcd, ilcm, igcdex, ifib, and ifac there is precedence for
> using these simple names.
This is a good point. However the less verbose names are cryptic to
me, whereas the current ones are easy to understand intuitively. What
about having bo
That's ok with me. Let's see if anyone else has an opinion.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, send email to
sympy+unsubscr...@googlegroups.com.
On 26 Mai, 21:18, "krastanov.ste...@gmail.com"
wrote:
> Also a small question: the pull request contains to many commits. Should I
> group them in bigger commits? Be aware that for some reason GitHub is not
> listing them chronological (at least to me).
Using git rebase it should be possible to c
It's not the same order. git log and
https://github.com/sympy/sympy/pull/186#commits-pushed-e60b5d0 are most
definitely showing different orders and the one in git hub is not
chronological. I have rebased it a number of times, but I have never tried
to change the order of commits.
But this is just
On Fri, May 27, 2011 at 7:57 AM, Chris Smith wrote:
> That's ok with me. Let's see if anyone else has an opinion.
I for myself prefer the longer names. I don't think this is used so
often, so that you should shorten it. But I am ok either way.
Ondrej
--
You received this message because you ar
I know (or I think I know) that eval(srepr(thing)) == thing in sympy.
Should this be also true for repr (the python build-in)? Why are there two
different functions that should be doing the same thing? Is repr hard do
modify?
Regards
Stefan
--
You received this message because you are subscribe
Hi,
On 27 May 2011 20:33, krastanov.ste...@gmail.com wrote:
> I know (or I think I know) that eval(srepr(thing)) == thing in sympy.
>
Yes, that should hold (otherwise it's a bug).
>
> Should this be also true for repr (the python build-in)? Why are there two
> different functions that should
https://github.com/sympy/sympy/pull/186
I've just finished adding the repr tests. All works well and after adding
the tests no bugs were found.
So as a recap:
-the printing methods are more straightforward (at least I hope so ;)
-the printing of InnerProduct and Spin looks better
-many test were
Le vendredi 27 mai 2011 à 20:39 +0200, Mateusz Paprocki a écrit :
> Hi,
>
> On 27 May 2011 20:33, krastanov.ste...@gmail.com
> wrote:
> I know (or I think I know) that eval(srepr(thing)) == thing in
> sympy.
>
>
> Yes, that should hold (otherwise it's a bug).
>
>
>
Speed needs to be considered too.
Aaron Meurer
On Fri, May 27, 2011 at 6:22 AM, smichr wrote:
> Does anyone have a better idea for how to canonicalize the args for
> Add (perhaps Mul, too).
>
> >>> from sympy.abc import *
> >>> from sympy import *
> >>> 3*x+6*y
> 3*x + 6*y
> >>> _
There are two questions, really:
1) why does gcd(2/3, 4/9) give 2/9 instead of (the greater) 2/3? I
know what the code is doing...but should it be doing that? I read
that
> This definition is consistent with the idea that `a / gcd(a,x)' should yield
> an integer for any `a' and `x'.
But why s
I opened an issue for this.
As noted by Mateusz, Tom and Vinzent, there are ways around this.
However, from an end users perspective, it would be nice if it worked
as I had originally tried.
Thanks again for the quick reply,
Matt
On Thu, May 26, 2011 at 10:31:02PM -0600, Aaron S. Meurer wrote:
The reason for the apparent arbitrariness is that Add uses key=hash (for
speed) while Mul uses Basic.compare.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to sympy@googlegroups.com.
To unsubscribe from this group, s
I'm +1 for linalg over matrix/matrices. Having a Matrix file and
putting all the linear algebra routines in it violates modularity and
extensibility. Also it makes the library unclear as to where other
linear algebraic operators actually fit. While the name "linear"
might not be the best fit for
Shouldn't it return 1?
Aaron Meurer
On May 27, 2011, at 3:14 PM, smichr wrote:
> There are two questions, really:
>
> 1) why does gcd(2/3, 4/9) give 2/9 instead of (the greater) 2/3? I
> know what the code is doing...but should it be doing that? I read
> that
>
>> This definition is consistent
Aaron S. Meurer wrote:
>> Shouldn't it return 1?
The quote I posted takes the approach that the divisor is the number that
divides both and still gives an integer, so our gcd and current primitive
method (soon to be changed) is consistent with that notion.
>>> R=Rational;gcd(R(2,3),R(4,9))
Hi,
On 27 May 2011 23:27, Chris Smith wrote:
> The reason for the apparent arbitrariness is that Add uses key=hash (for
> speed) while Mul uses Basic.compare.
It seems we just overlooked Basic.compare in Mul. I git blame
sympy/core/mul.py and the line with Basic.compare didn't change since the
Hi,
On 27 May 2011 14:22, smichr wrote:
> Does anyone have a better idea for how to canonicalize the args for
> Add (perhaps Mul, too).
>
>>>> from sympy.abc import *
>>>> from sympy import *
>>>> 3*x+6*y
>3*x + 6*y
>>>> _.args
>(3*x, 6*y)
>>>> (x+2*y).args
>(2*y,
22 matches
Mail list logo
