http://www.sagemath.org:9002/sage_trac/ticket/1235 should be faster.
--Mike
On Dec 8, 2007 12:50 PM, Ted Kosan <[EMAIL PROTECTED]> wrote:
>
> William wrote:
>
> > As a start I've implemented find_root (and some minizing and
> > maximizing functions)
> > and posted a patch here:
> > http://tr
William wrote:
> As a start I've implemented find_root (and some minizing and
> maximizing functions)
> and posted a patch here:
> http://trac.sagemath.org/sage_trac/ticket/1235
This is great :-) I will try the code as soon as the slashdot traffic
subsides from the server.
Ted
--~--~
> By the way, we'll definitely want to create an arbitrary precision find_root
> using MPFR etc. at some point -- that will be very exciting. (The above is
> just supposed to do some wimpy machine precision root finding.)
a possible starting point is http://komite.net/laurent/pro/these-20070228
On Dec 8, 2007 1:39 AM, Paul Zimmermann <[EMAIL PROTECTED]> wrote:
>
> > One interesting thing is that I made it so that
> >
> > f.find_root(a,b)
> >
> > works even if the sign of f(a) and f(b) are the same. In that case,
> > it will find a min or max of f on the interval, and use that as a
> One interesting thing is that I made it so that
>
> f.find_root(a,b)
>
> works even if the sign of f(a) and f(b) are the same. In that case,
> it will find a min or max of f on the interval, and use that as a new
> endpoint as input to the root finding algorithm. The root finder
> itsel
On Nov 27, 2007 9:25 AM, Ted Kosan <[EMAIL PROTECTED]> wrote:
>
> Ondrej wrote:
>
> > > Could you please clarify, what exact functionality in solve you expect
> > > in order for 1235 to be solved?
> > >
> > > Should it just run the iterative numerical solver if it cannot find
> > > the solution an
Ted Kosan wrote:
> Ondrej wrote:
>
>>> Could you please clarify, what exact functionality in solve you expect
>>> in order for 1235 to be solved?
>>>
>>> Should it just run the iterative numerical solver if it cannot find
>>> the solution analytically?
>
>
> And William wrote:
>
>> I don't kno
Ondrej wrote:
> > Could you please clarify, what exact functionality in solve you expect
> > in order for 1235 to be solved?
> >
> > Should it just run the iterative numerical solver if it cannot find
> > the solution analytically?
And William wrote:
> I don't know. However, Ted, what do you
On Nov 26, 2007 2:54 PM, Ondrej Certik <[EMAIL PROTECTED]> wrote:
>
> > I just received permission from my University to spend $1000 to have
> > the SAGE project fix the following bug:
> >
> > http://trac.sagemath.org/sage_trac/ticket/1235
> >
>
> Could you please clarify, what exact functionality
> I just received permission from my University to spend $1000 to have
> the SAGE project fix the following bug:
>
> http://trac.sagemath.org/sage_trac/ticket/1235
>
Could you please clarify, what exact functionality in solve you expect
in order for 1235 to be solved?
Should it just run the iter
Hello,
I've posted a patch for # -- http://sagetrac.org/sage_trac/ticket/
--Mike
On Nov 26, 2007 3:34 PM, Ted Kosan <[EMAIL PROTECTED]> wrote:
>
> William wrote:
>
> > I think one student working for two weeks could greatly enhance solve,
> > but making it:
> >
> >(1) try the maxima
William wrote:
> I think one student working for two weeks could greatly enhance solve,
> but making it:
>
>(1) try the maxima solve, and
>(2) if the maxima solve returns no solutions, do something further that
> involves numerics, e.g., calling to scipy's iterative solver.
>
> In pa
On Nov 21, 2007 10:04 AM, Ted Kosan <[EMAIL PROTECTED]> wrote:
>
> William wrote:
>
> > But this might be pretty hard to fix soon. Making sure we
> > are well aware of it, though, is critically important if we
> > are to push Sage to be truly professional level in
> > non-algebraic areas...
>
>
> I don't like that meaning for solve, since it is misleading to me, and
> is inconsistent. e.g., what about:
>
> sage: solve(x^5 + x^3 + 1, x)
> [0 == x^5 + x^3 + 1]
>
> When there is no explicit solution, maxima usually returns something
> to explicitly indicate this.
>
> Also, as a data point,
William wrote:
> But this might be pretty hard to fix soon. Making sure we
> are well aware of it, though, is critically important if we
> are to push Sage to be truly professional level in
> non-algebraic areas...
Do you have a rough estimate of how much it might cost to fix this bug
(either
On Nov 21, 2007 8:24 AM, Ondrej Certik <[EMAIL PROTECTED]> wrote:
>
> > I think in the long-run Sage will have to completely implement its own solve
> > function, which is better than Maxima's. Thoughts from Ondrej-sympy would
> > be
> > appreciated here.
>
>
> Isn't solve supposed to return an
> I think in the long-run Sage will have to completely implement its own solve
> function, which is better than Maxima's. Thoughts from Ondrej-sympy would be
> appreciated here.
Isn't solve supposed to return an analylic solution only? Is there an
analytic solution to this equation? It doesn't
On Nov 20, 2007 12:28 PM, Ted Kosan <[EMAIL PROTECTED]> wrote:
> Does anyone have any thoughts on why the solve() function this program
> returns an empty list?:
>
> sage: var('t')
> sage: a = .004*(8*e^(-(300*t)) - 8*e^(-(1200*t)))*(72*e^(-(300*t))
> - 1152*e^(-(1200*t))) +.004*(9600*e^(-
No, but
sage: t = var("t")
sage: a = lambda t: 0.004*(8*exp(-300*t) -
8*exp(-1200*t))*72*exp(-300*t) - 0.1
sage: attach
'/home/wdj/sagestuff/sage-2.8.9.rc1/examples/calculus/newton_raphson.sage'
sage: newton_raphson(a,0.01,0.01,0.1)
0.0205789829857519
works okay. (This newton_raphso
19 matches
Mail list logo
