On Apr 22, 2009, at 5:13 PM, root wrote:
>
>>> It's on our list too, so it will happen eventually. We definitely
>>> still need to improve our algorithms a lot, see e.g.:
>>>
>>> http://groups.google.com/group/sympy/browse_thread/thread/58916fb31e1ff1ea
>>>
>>> but a nice thing is that it's in P
> > It's on our list too, so it will happen eventually. We definitely
> > still need to improve our algorithms a lot, see e.g.:
> >
> > http://groups.google.com/group/sympy/browse_thread/thread/58916fb31e1ff1ea
> >
> > but a nice thing is that it's in Python, so it's easy to work with.
> >
> > Ond
On Wed, Apr 22, 2009 at 7:03 PM, Carl Witty wrote:
>
>
> Couldn't you just pick random values for all of the symbolic constants, as
> well?
Yes, but over what range? If you do that, you've just ensured that it
is correct for
those points. It also could get expensive if you have multiple
constan
On Wed, Apr 22, 2009 at 3:59 PM, Tim Lahey wrote:
>
> On Wed, Apr 22, 2009 at 6:54 PM, Carl Witty wrote:
>>
>>
>> Would it be better to test the results numerically? (For instance,
>> evaluate the integral returned and the desired result at 100 random
>> points to high precision, and ensure tha
On Wed, Apr 22, 2009 at 6:54 PM, Carl Witty wrote:
>
>
> Would it be better to test the results numerically? (For instance,
> evaluate the integral returned and the desired result at 100 random
> points to high precision, and ensure that the relative error between
> the answers at each point is
On Wed, Apr 22, 2009 at 3:35 PM, Tim Lahey wrote:
> The problem arises with all the different integration systems. Usually some
> kind of simplification is needed on the integral returned, even if there
> aren't
> multiple solutions. This complicates the testing procedure since the steps to
> pe
On Wed, Apr 22, 2009 at 3:35 PM, Tim Lahey wrote:
>
> On Wed, Apr 22, 2009 at 6:31 PM, Ondrej Certik wrote:
>>
>>
>> I think sympy will do very poorly if the assumptions are needed, we
>> are still working on the assumptions.
>>
>> So if it turns out too difficult, just skip sympy for the time b
On Wed, Apr 22, 2009 at 6:31 PM, Ondrej Certik wrote:
>
>
> I think sympy will do very poorly if the assumptions are needed, we
> are still working on the assumptions.
>
> So if it turns out too difficult, just skip sympy for the time being,
> we'll get back to it later.
>
The problem arises wit
On Wed, Apr 22, 2009 at 3:27 PM, Tim Lahey wrote:
>
> On Wed, Apr 22, 2009 at 6:11 PM, Ondrej Certik wrote:
>>
>>
>> We use py.test/nosetest compatible tests, but if you prefer Sage like
>> doctests, that's fine too.
>
> Good to know. I'm not actually using any unit test classes at the moment
>
On Wed, Apr 22, 2009 at 6:11 PM, Ondrej Certik wrote:
>
>
> We use py.test/nosetest compatible tests, but if you prefer Sage like
> doctests, that's fine too.
Good to know. I'm not actually using any unit test classes at the moment
since I have the difficulty that each test has different steps t
On Wed, Apr 22, 2009 at 1:12 PM, Tim Lahey wrote:
>
> On Wed, Apr 22, 2009 at 4:10 PM, Ondrej Certik wrote:
>>
>>
>> It's on our list too, so it will happen eventually. We definitely
>> still need to improve our algorithms a lot, see e.g.:
>>
>> http://groups.google.com/group/sympy/browse_thread
On Wed, Apr 22, 2009 at 4:10 PM, Ondrej Certik wrote:
>
>
> It's on our list too, so it will happen eventually. We definitely
> still need to improve our algorithms a lot, see e.g.:
>
> http://groups.google.com/group/sympy/browse_thread/thread/58916fb31e1ff1ea
>
> but a nice thing is that it's in
On Wed, Apr 22, 2009 at 12:43 PM, Tim Lahey wrote:
>
> On Wed, Apr 22, 2009 at 1:29 PM, root wrote:
>>
>>
>> There is an integration test suite at:
>> http://axiom-developer.org/axiom-website/CATS
>> which has the Schaums integral series along with examples.
>> Each integral result is subtracted
On Wed, Apr 22, 2009 at 1:29 PM, root wrote:
>
>
> There is an integration test suite at:
> http://axiom-developer.org/axiom-website/CATS
> which has the Schaums integral series along with examples.
> Each integral result is subtracted from the Schaums answer
> and then simplified, hopefully to a
> >>> Kudos to SymPy!
> >>>
> >>> I'm wondering why the python integration algorithms implemented there
> >>> aren't in the short term adopted by SAGE.
> >>
> >> They are --- you can use them from sympy inside Sage. It's my goal
> >> that all sympy features are nicely integrated in Sage. I work on
On Tue, Apr 21, 2009 at 3:48 PM, Ondrej Certik wrote:
>
> On Tue, Apr 21, 2009 at 2:33 PM, Maurizio wrote:
>>
>> thank you for clarifying this, I didn't know that sympy was already
>> pretty well working with the new symbolics
>>
>> I hope this has at least given some information to the communit
On Tue, Apr 21, 2009 at 2:33 PM, Maurizio wrote:
>
> thank you for clarifying this, I didn't know that sympy was already
> pretty well working with the new symbolics
>
> I hope this has at least given some information to the community as
> well! I always learn a lot from these discussions
Excell
thank you for clarifying this, I didn't know that sympy was already
pretty well working with the new symbolics
I hope this has at least given some information to the community as
well! I always learn a lot from these discussions
Regards
Maurizio
On 21 Apr, 22:58, Jason Grout wrote:
> Ondrej C
Ondrej Certik wrote:
> On Tue, Apr 21, 2009 at 1:10 PM, William Stein wrote:
>> On Tue, Apr 21, 2009 at 1:06 PM, Ondrej Certik wrote:
>>> On Mon, Apr 20, 2009 at 5:31 AM, Maurizio
>>> wrote:
Kudos to SymPy!
I'm wondering why the python integration algorithms implemented there
>>
On Tue, Apr 21, 2009 at 1:10 PM, William Stein wrote:
>
> On Tue, Apr 21, 2009 at 1:06 PM, Ondrej Certik wrote:
>>
>> On Mon, Apr 20, 2009 at 5:31 AM, Maurizio wrote:
>>>
>>> Kudos to SymPy!
>>>
>>> I'm wondering why the python integration algorithms implemented there
>>> aren't in the short te
On Tue, Apr 21, 2009 at 1:06 PM, Ondrej Certik wrote:
>
> On Mon, Apr 20, 2009 at 5:31 AM, Maurizio wrote:
>>
>> Kudos to SymPy!
>>
>> I'm wondering why the python integration algorithms implemented there
>> aren't in the short term adopted by SAGE.
>
> They are --- you can use them from sympy i
On Mon, Apr 20, 2009 at 5:31 AM, Maurizio wrote:
>
> Kudos to SymPy!
>
> I'm wondering why the python integration algorithms implemented there
> aren't in the short term adopted by SAGE.
They are --- you can use them from sympy inside Sage. It's my goal
that all sympy features are nicely integra
On Apr 20, 2009, at 12:53 PM, Jason Grout wrote:
> Burcin Erocal wrote:
>> On Sun, 19 Apr 2009 10:34:21 -0700
>> Carl Witty wrote:
>>
>>> On Sun, Apr 19, 2009 at 7:44 AM, Maurizio
>>> wrote:
Carl, I took advantage of your suggestion, even though I assume I
can't still go through the w
Burcin Erocal wrote:
> On Sun, 19 Apr 2009 10:34:21 -0700
> Carl Witty wrote:
>
>> On Sun, Apr 19, 2009 at 7:44 AM, Maurizio
>> wrote:
>>> Carl, I took advantage of your suggestion, even though I assume I
>>> can't still go through the whole process with the current gcd
>>> capabilities in Pyna
On Sun, 19 Apr 2009 10:34:21 -0700
Carl Witty wrote:
>
> On Sun, Apr 19, 2009 at 7:44 AM, Maurizio
> wrote:
> > Carl, I took advantage of your suggestion, even though I assume I
> > can't still go through the whole process with the current gcd
> > capabilities in Pynac. But before than that, I
Kudos to SymPy!
I'm wondering why the python integration algorithms implemented there
aren't in the short term adopted by SAGE.
At least, they are already aware of their shortcomings (ie: cannot
compute the integral of log(x)/x ).
I'm sure SAGE people could give big contribute to those, send pat
On Sun, Apr 19, 2009 at 3:28 PM, William Stein wrote:
> Ondrej,
>
> How does sympy compute the integral of
>
> (x^2 + 2*x + 1 +
> (3*x+1)*sqrt(x+log(x)))/(x*sqrt(x+log(x))*(x+sqrt(x+log(x?
See this thread in our list:
http://groups.google.com/group/sympy/browse_thread/thread/9a61d681e6f96
On Sun, Apr 19, 2009 at 4:20 PM, root wrote:
>
>> So we have a good start to implement the Risch algorithm in sympy already.
>
> Ondrej, what result do you get for:
>
> integrate(sqrt(x+log(x)),x)
In [1]: integrate(sqrt(x+log(x)),x)
Out[1]:
⌠
⎮
⎮ ╲╱ x + log(x) dx
⌡
So we can't
> > A much shorter example is:
> >
> > integrate(sqrt(x+log(x)),x)
> >
> > to which Axiom replies:
> >
> > integrate: implementation incomplete (constant residues)
> >
>
> What is f(x) = sqrt(x+log(x)) supposed to be an example of? Does f
> has an antiderivative that can be expressed in terms of
> So we have a good start to implement the Risch algorithm in sympy already.
Ondrej, what result do you get for:
integrate(sqrt(x+log(x)),x)
Tim
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this grou
On Sun, Apr 19, 2009 at 3:25 PM, Ondrej Certik wrote:
>
> On Sun, Apr 19, 2009 at 1:23 PM, Fredrik Johansson
> wrote:
>>
>> On Sun, Apr 19, 2009 at 10:14 PM, William Stein wrote:
>>> Wikipedia also has a few interesting remarks, e.g., that the Risch
>>> algorithm isn't an algorithm, because it
On Sun, Apr 19, 2009 at 1:23 PM, Fredrik Johansson
wrote:
>
> On Sun, Apr 19, 2009 at 10:14 PM, William Stein wrote:
>> Wikipedia also has a few interesting remarks, e.g., that the Risch
>> algorithm isn't an algorithm, because it depends on being able to
>> check equality of general elementary
On Sun, Apr 19, 2009 at 3:33 PM, root wrote:
>
>> > Wikipedia also has a few interesting remarks, e.g., that the Risch
>> > algorithm isn't an algorithm, because it depends on being able to
>> > check equality of general elementary functions, which is evidently an
>> > open problem in general (so
> > Wikipedia also has a few interesting remarks, e.g., that the Risch
> > algorithm isn't an algorithm, because it depends on being able to
> > check equality of general elementary functions, which is evidently an
> > open problem in general (so in practice you just fake it by evaluating
> > nume
> > Wikipedia also has a few interesting remarks, e.g., that the Risch
> > algorithm isn't an algorithm, because it depends on being able to
> > check equality of general elementary functions, which is evidently an
> > open problem in general (so in practice you just fake it by evaluating
> > nume
On Sun, Apr 19, 2009 at 10:14 PM, William Stein wrote:
> Wikipedia also has a few interesting remarks, e.g., that the Risch
> algorithm isn't an algorithm, because it depends on being able to
> check equality of general elementary functions, which is evidently an
> open problem in general (so in
On Sun, Apr 19, 2009 at 10:34 AM, Carl Witty wrote:
>
> On Sun, Apr 19, 2009 at 7:44 AM, Maurizio wrote:
>> Carl, I took advantage of your suggestion, even though I assume I
>> can't still go through the whole process with the current gcd
>> capabilities in Pynac. But before than that, I'd like
On Sun, Apr 19, 2009 at 7:44 AM, Maurizio wrote:
> Carl, I took advantage of your suggestion, even though I assume I
> can't still go through the whole process with the current gcd
> capabilities in Pynac. But before than that, I'd like to point out
> something strange I did notice, and maybe als
Challenging? Just because about the problem of integration in finite
terms Hardy in 1916 stated that “there is reason to suppose that no
such method can be given” ? :)
I want to add to this discussion that I found a lot of useful
information in this thread from SymPy list:
http://groups.google.co
Aha! Quite the challenge is it not?
On Sun, Apr 19, 2009 at 7:44 AM, Maurizio wrote:
>
> Hi all
>
> > Well, we just need a resultant algorithm that doesn't go through
> > Singular. I'm planning to write such a thing as part of my
> > cylindrical algebraic decomposition implementation sometime in
Hi all
> Well, we just need a resultant algorithm that doesn't go through
> Singular. I'm planning to write such a thing as part of my
> cylindrical algebraic decomposition implementation sometime in the
> next few months.
>
> Carl
yes, I agree with that.
William, unfortunately I can't underst
On Sat, Apr 18, 2009 at 6:55 PM, William Stein wrote:
>>> First problem with QQbar: it seems that resultant() doesn't like it,
>>> because it is not able to convert it to a Singular ring (this is the
>>> error, I'm not attaching all the output, tell me if you need it)
>>>
>>> TypeError: no conver
On Sat, Apr 18, 2009 at 5:27 PM, Carl Witty wrote:
>
> On Sat, Apr 18, 2009 at 2:46 PM, Maurizio wrote:
>> Could you be clearer? As I told, I'm not familiar with rings. I don't
>> even know the meaning of the argument of GF (I took the number 5 from
>> an example I see in sage-support group, I t
On Sat, Apr 18, 2009 at 6:04 PM, Maurizio wrote:
>> QQ is the rational numbers (fractions). QQbar is the algebraic
>> closure of QQ; this means it includes every complex number which is
>> the root of a polynomial with rational coefficients. So it includes
>> things like sqrt(2) (which is a roo
Thanks for the answer.
As the time goes, I get more understanding of the complexity of the
problem (much more than I expected at first).
On 19 Apr, 02:27, Carl Witty wrote:
> On Sat, Apr 18, 2009 at 2:46 PM, Maurizio wrote:
> > Could you be clearer? As I told, I'm not familiar with rings. I do
On Sat, Apr 18, 2009 at 2:46 PM, Maurizio wrote:
> Could you be clearer? As I told, I'm not familiar with rings. I don't
> even know the meaning of the argument of GF (I took the number 5 from
> an example I see in sage-support group, I think). Do you think that QQ
> [] could fit in this case? Mo
Carl, Burcin,
thank you very much for your support.
Burcin, I'm sorry for the trivial mistake. Thank you for pointing it
out.
Unfortunately, I don't understand this:
"
The theory only works over characteristic 0, i.e., your fields should
contain QQ. Also note that,
sage: P. = GF(5)[]
sage: (x+x
On Thu, Apr 16, 2009 at 3:43 PM, Maurizio wrote:
> Finally, even assuming that I can get the right answer from this,
> which is the recommended way to get the roots of an equation given by
> a "univariate polynomials == 0"? This is supposed to be the next step
> of the algorithm.
Taking a quick
On Thu, 16 Apr 2009 15:43:41 -0700 (PDT)
Maurizio wrote:
>
> > For people interested in helping out, a few words about integration is
> > in order. As we discussed on this list before, many problems in
> > integration can be handled with heuristics before calling more advanced
> > algorithms. T
> For people interested in helping out, a few words about integration is
> in order. As we discussed on this list before, many problems in
> integration can be handled with heuristics before calling more advanced
> algorithms. The heuristics also give more user friendly answers in most
> cases.
>
On Apr 15, 1:58 am, Burcin Erocal wrote:
> Hi Michael,
Hi Burcin,
> > I checked old backups and the directory I keep spam pages around and I
> > cannot find it. So either the conversion a while ago caused the
> > trouble or something went terribly wrong. Sorry.
>
> No problem. We didn't los
Hi Michael,
On Wed, 15 Apr 2009 01:39:15 -0700 (PDT)
mabshoff wrote:
> On Apr 15, 1:32 am, Burcin Erocal wrote:
>
>
>
> Hi Burcin,
>
> > There was also some effort to
> > get Sage on the list of software in the DLMF, but the wiki page for
> > this seems to be deleted. (mabshoff?)
>
> I ch
On Apr 15, 1:32 am, Burcin Erocal wrote:
Hi Burcin,
> There was also some effort to
> get Sage on the list of software in the DLMF, but the wiki page for
> this seems to be deleted. (mabshoff?)
I checked old backups and the directory I keep spam pages around and I
cannot find it. So either
Hi Maurizio,
On Tue, 14 Apr 2009 14:35:37 -0700 (PDT)
Maurizio wrote:
>
> Hi all.
>
> I'm willing to invest some of my time to understand if I can be able
> to do a step ahead with symbolic functions.
Great to hear that.
> How are special symbolic functions supposed to be defined?
They wil
54 matches
Mail list logo
