That's nice to hear, thanks Will.

acer

It looks to me like a (2dim flattened to 1dim) sequence of text fields, with hard-coded 5x5 dimensions.

To view some of the source, try,

kernelopts(opaquemodules=false):
eval(Student:-LinearAlgebra:-MatrixBuilder:-ModuleApply);
eval(Student:-LinearAlgebra:-MatrixBuilder:-GetMatrix);

There's a local procedure named GetMatrix which tries this,

Raw := [Maplets:-Tools:-Get(
    seq(seq("TF" || i || j, j = 1 .. cols), i = 1  .. rows))];
M := Matrix(rows, cols, [seq([seq(CheckTextField(
    Raw[(i - 1)*cols + j], 'algebraic',
    `_MessageCatalogue/GetMessage`("an algebraic expression",
    "Maplets"), 0), j = 1 .. cols)], i = 1 .. rows)])

And those text fields appear to get set up in the ModuleApply with this,

seq(
    seq(Maplets:-Elements:-TextField["TF" || i || j](
    'value' = eval(initM[i, j]), 'width' = 10, mapletLightColor,
    'tooltip' =
    `_MessageCatalogue/GetMessage`("Enter a value", "Maplets"),
    'enabled' = true), j = 1 .. max), i = 1 .. max)

acer

This site has momentum. But some amount of energy still has to be put into the system, or it will slow down.

Having the site be down for 60 hours straight every few weeks can't be helping.

acer

Is it possible to start maple11.02 Classic GUI under Windows with the mtserver.exe multi-threaded kernel, and see whether that too is a problem alongside AVG 8?

acer

Aren't the Optimization, GlobalOptimization, and evalf/Int external processes already interruptible during callbacks to Maple proper? They make "eval" and "evalhf" callbacks to evaluate objectives and integrands.

Isn't external software precision LinearAlgebra interruptible during garbage collection?

acer

RootFinding:-Analytic is often not an efficient tool for find a sequence of roots on the real axis. Simply by the way that it works it will do a lot of complex contour work, trying to separate the roots, that is not necessary to solve the problem. (And that's on top of the potential problems with nonreal roots and the question of how fine to make the complex bounding box -- not a problem here but true in general).

On the other hand, RootFinding:-NextZero, while not perfect, is designed for precisely this purpose, finding an ordered set of zeros on the real axis starting from a given initial left-most point.

But of course Robert's answer to use BesselJZeros is best. (I had forgotten that the routine existed!)

acer

RootFinding:-Analytic is often not an efficient tool for find a sequence of roots on the real axis. Simply by the way that it works it will do a lot of complex contour work, trying to separate the roots, that is not necessary to solve the problem. (And that's on top of the potential problems with nonreal roots and the question of how fine to make the complex bounding box -- not a problem here but true in general).

On the other hand, RootFinding:-NextZero, while not perfect, is designed for precisely this purpose, finding an ordered set of zeros on the real axis starting from a given initial left-most point.

But of course Robert's answer to use BesselJZeros is best. (I had forgotten that the routine existed!)

acer

The result from the first of those looks nice. Wouldn't it be nicer still, though, if int() could return that under conditions on a and b. Let's call it a "weakness".

acer

The result from the first of those looks nice. Wouldn't it be nicer still, though, if int() could return that under conditions on a and b. Let's call it a "weakness".

acer

Something like this works, I think, to get a result for a and b as posints greater than or equal to 2. But I did it by hand.

> sol := Sum((-1)^i*binomial(b-1,i)*t^(a-1+i+1)/(a-1+i+1),i = 0 .. b):

> value(eval(sol,[a=3,b=4,t=2]));
                                     -4/5

acer

Something like this works, I think, to get a result for a and b as posints greater than or equal to 2. But I did it by hand.

> sol := Sum((-1)^i*binomial(b-1,i)*t^(a-1+i+1)/(a-1+i+1),i = 0 .. b):

> value(eval(sol,[a=3,b=4,t=2]));
                                     -4/5

acer

If only the floating point result is wanted, then evalf(f(x,a,b)) could also be OK, provided that f creates the inert Int() instead of int() , like John has done above.

Now, to the question about it being a bug. Would it not be better if int() could return a conditional result here?

I wasn't able to get anything out of int() under the following assumptions. Maybe someone else can see how. (Is there not a closed form answer in terms of binomials to expand (t-1)^(b-1)?)

> restart:
> _EnvAllSolutions:=true:

> f := Int( t^(a-1) * (1-t)^(b-1), t=0..x ):

> value(simplify(expand(f)))
>   assuming a::AndProp(integer,RealRange(2,infinity)),
>            b::AndProp(integer,RealRange(2,infinity)), x>0;

                              x
                             /
                         b  |    (a - 1)         (b - 1)
                    -(-1)   |   t        (-1 + t)        dt
                            |
                           /
                             0

acer

If only the floating point result is wanted, then evalf(f(x,a,b)) could also be OK, provided that f creates the inert Int() instead of int() , like John has done above.

Now, to the question about it being a bug. Would it not be better if int() could return a conditional result here?

I wasn't able to get anything out of int() under the following assumptions. Maybe someone else can see how. (Is there not a closed form answer in terms of binomials to expand (t-1)^(b-1)?)

> restart:
> _EnvAllSolutions:=true:

> f := Int( t^(a-1) * (1-t)^(b-1), t=0..x ):

> value(simplify(expand(f)))
>   assuming a::AndProp(integer,RealRange(2,infinity)),
>            b::AndProp(integer,RealRange(2,infinity)), x>0;

                              x
                             /
                         b  |    (a - 1)         (b - 1)
                    -(-1)   |   t        (-1 + t)        dt
                            |
                           /
                             0

acer

What Axel's trying to show is that LambertW(1) is an exact symbolic representation of the value that satisfies the equation.

The 0.56.. floating-point result is only an approximation accurate to a finite number of digits. The evalf() command can be used to approximate the exact symbolic quantity to however many decimal digits you wish.

You could also use fsolve instead of solve, if you wanted only the floating-point result.

Maple is a computer algebra system (CAS) and it is able to do lots of exact computation involving such exact symbolic quantities, which is why `solve` doesn't just return the approximate result.

acer

What Axel's trying to show is that LambertW(1) is an exact symbolic representation of the value that satisfies the equation.

The 0.56.. floating-point result is only an approximation accurate to a finite number of digits. The evalf() command can be used to approximate the exact symbolic quantity to however many decimal digits you wish.

You could also use fsolve instead of solve, if you wanted only the floating-point result.

Maple is a computer algebra system (CAS) and it is able to do lots of exact computation involving such exact symbolic quantities, which is why `solve` doesn't just return the approximate result.

acer