Hmm, that's too bad. I added a note about the naming of inverse trig
functions as acos instead of acrcos to the new tutorial near the section on
trig simplification, but it seems out of place without any actual examples
using them.
Is this planned?
Aaron Meurer
On Thu, May 16, 2013 at 10:23 PM,
no
On Fri, May 17, 2013 at 10:04 AM, Aaron Meurer wrote:
> Does the new Fu trigsimp algorithm implement any algorithms to simplify
> inverse trig functions?
>
> Aaron Meurer
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To unsubscribe from
Does the new Fu trigsimp algorithm implement any algorithms to simplify
inverse trig functions?
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+unsu
Many times in books or documents, there are little boxes in the margin that
repeat some important fact from the text, to emphasize it, and to ensure
that even if the reader is skimming through the text that he sees that
note.
Does anyone know if there is a similar construct in Sphinx, and if not,
On Thu, May 16, 2013 at 9:46 PM, Ondřej Čertík wrote:
> On Thu, May 16, 2013 at 9:13 PM, Ondřej Čertík
> wrote:
> > Hi,
> >
> > I came late to this discussion. I have a few questions. It seems that
> > the consensus is to use global assumptions together with the
> > "assuming" context manager.
>
On Thu, May 16, 2013 at 9:13 PM, Ondřej Čertík wrote:
> Hi,
>
> I came late to this discussion. I have a few questions. It seems that
> the consensus is to use global assumptions together with the
> "assuming" context manager.
> Let's take Pow as an example. In the Pow.__new__(), resp in
> Pow._ev
Hi,
I came late to this discussion. I have a few questions. It seems that
the consensus is to use global assumptions together with the
"assuming" context manager.
Let's take Pow as an example. In the Pow.__new__(), resp in
Pow._eval_power() it currently uses code like:
b_nneg = b.is_nonne
I'm with aaron.I have plenty of free time till august.I can spend some for
sympy.
On Fri, May 17, 2013 at 7:10 AM, Aaron Meurer wrote:
> Is anyone willing to commit some time over the next few weeks or so to
> help get a release out?
>
> If so, then I think we should do it. It will make things
I sure will.
The differential geometry package looks great for my purposes, it looks
likes it's the stats module that I will have trouble with.
Lucas
On Friday, 17 May 2013 02:25:08 UTC+1, Aaron Meurer wrote:
>
> That's great.
>
> No one I know of is working on such a think. Definitely no one
Is anyone willing to commit some time over the next few weeks or so to
help get a release out?
If so, then I think we should do it. It will make things easier for
Ondrej and I for our SciPy tutorial. But if no one is willing to do
some serious helping, then it will have to wait.
Aaron Meurer
-
That's great.
No one I know of is working on such a think. Definitely no one is
working on anything like that inside of SymPy.
Let us know how the diffgeom and stats modules work for what you are
doing. There are also some ideas about tensors at
https://github.com/sympy/sympy/pull/2041 (I don't
Hello Everybody!
I've been thinking about making some CAS tools for information geometry for
a long time now.
I've been using Mathematica for my information geometry stuff, but the task
of making a concrete Mathematica module depressed me, firstly because I
don't like the language so much, and
https://github.com/sympy/sympy/pull/2115
It's unfortunate that Travis didn't fail with these errors. I guess
you'll need to test locally to really make sure this fixes the issue
(though a grep of "statistics") reveals that these should be the only
places outside the statistics module that it is im
Oh, never mind. It does it even without -k. The issue is that it's the
printing tests, not the statistics tests. I think the solution is to
just move those tests to the statistics module.
Aaron Meurer
On Thu, May 16, 2013 at 2:26 PM, Aaron Meurer wrote:
> OK, I can reproduce this. It only happe
OK, I can reproduce this. It only happens when the -k flag is passed to test.
There is another issue here too, which is that this error should not
kill the test runner. That might be harder to fix, though. I'll look
into it.
Aaron Meurer
On Thu, May 16, 2013 at 3:33 AM, Chris Smith wrote:
> It
refine + simplify is needed. If you can take a look at
https://github.com/sympy/sympy/pull/2111 sympy will be able to reduce your
c1 or -c1 to its simplest form.
On Thu, May 16, 2013 at 9:21 PM, Ondřej Čertík wrote:
> On Wed, May 15, 2013 at 9:58 PM, Chris Smith wrote:
> > Ahhh...I didn't see t
On Wed, May 15, 2013 at 9:58 PM, Chris Smith wrote:
> Ahhh...I didn't see the "1/" part. `x*sqrt(1/x)` is not, in general, equal
> to `sqrt(x)` as can be verified with `x=-3` since `sqrt(1/x) != 1/sqrt(x)`
>
> ```
sqrt(1/x).subs(x,-3.)
> 0.577350269189626*I
(1/sqrt(x)).subs(x,-3.)
> -0.5
Tomo,
That's good to know. Hopefully I'll be able to discuss things with Sean and
get things set-up. It's good to see that you are around. I wasn't sure if
the TO-DO on the pull request is recent, but based on what you said, it is.
That clarifies things immensely.
Cheers,
~ Luke
On Wednes
It happens in master, e.g.
chriss@CHRIS-LT ~/sympy (master)
$ bin/test -k linear_co
= test process starts
=
executable: c:\Python26\python.exe (2.6.6-final-0) [CPython]
architecture: 32-bit
cache: yes
ground types:
19 matches
Mail list logo
