Actually, solve returns really quickly when solving for all the variables of the original equation too.  I understood the original question to be about solving for eta, which would mean solving for y in your transformed equation: solve(eq1,y);

That still runs my machine out of memory.

Actually, solve returns really quickly when solving for all the variables of the original equation too.  I understood the original question to be about solving for eta, which would mean solving for y in your transformed equation: solve(eq1,y);

That still runs my machine out of memory.

The speed with which Maple 12 uses up all my RAM and crashes on this problem is pretty impressive.

The speed with which Maple 12 uses up all my RAM and crashes on this problem is pretty impressive.

I'd like to be able to program document components like you can program Maplets. It is really hard to build anything complicated when you have to use the build-in editor for each button.

<obligitory windows bash>

Why would anyone waste a "massive" PC by installing windows on it?

</obligitory windows bash>

I thought convert(...,`+`) might be more efficient than add() but I guess that SUM dag is not just a list with a different label, so convert is probably doing nearly the same computation as 'add' (though it does it without needing a local variable).

I thought convert(...,`+`) might be more efficient than add() but I guess that SUM dag is not just a list with a different label, so convert is probably doing nearly the same computation as 'add' (though it does it without needing a local variable).

From what I have read, base64 is what is typically used to embed images in xml documents.  Perhaps Maple is reencoding images embedded in a document (which seems like a bad idea, but perhaps the worksheet expects them all to be jpegs or some such).

Have you tried base64 unencoding what gets embedded instead?

I didn't read the OP carefully enough. If one really wants to do something like this with a do loop, one should build up a mutable object in the loop, then convert it to a sum afterwards. Here it is using an Array, but you could use a table instead.

rsum_array := proc(L::list)
local A, i, x;
    A := Array(1..nops(L));     # this will store the summands    
    i := 1;
    for x in L do
        A[i] := 1/x;       
        i := i + 1;
    end do;

    return convert(A,`+`); 
end proc:

time(rsum_array(L));

                                     0.080

Using a table is not as straight forward but almost as fast:

rsum_table := proc(L::list)
local T, i, x;
    T := table();     # this will store the summands    
    i := 1;
    for x in L do
        T[i] := 1/x;       
        i := i + 1;
    end do;

    return convert(map(op,[entries(T)]), `+`);
end proc:

time(rsum_table(L));                                
                                     0.088

I didn't read the OP carefully enough. If one really wants to do something like this with a do loop, one should build up a mutable object in the loop, then convert it to a sum afterwards. Here it is using an Array, but you could use a table instead.

rsum_array := proc(L::list)
local A, i, x;
    A := Array(1..nops(L));     # this will store the summands    
    i := 1;
    for x in L do
        A[i] := 1/x;       
        i := i + 1;
    end do;

    return convert(A,`+`); 
end proc:

time(rsum_array(L));

                                     0.080

Using a table is not as straight forward but almost as fast:

rsum_table := proc(L::list)
local T, i, x;
    T := table();     # this will store the summands    
    i := 1;
    for x in L do
        T[i] := 1/x;       
        i := i + 1;
    end do;

    return convert(map(op,[entries(T)]), `+`);
end proc:

time(rsum_table(L));                                
                                     0.088

I wonder if this creates a lot of sums that will need to be garbage collected, like trying to build up a list in a loop. 

I would probably use a one-liner to avoid creating garbage:

rsumshort := proc(L)
option inline;
    `+`(op(map(`/`,L)));
end proc;

L:=[seq(cat(`a`,i), i=1..10000)]:

time(rsumshort(L));                 
                                     0.044
time(rsum(L));                  
                                    10.064

 

I wonder if this creates a lot of sums that will need to be garbage collected, like trying to build up a list in a loop. 

I would probably use a one-liner to avoid creating garbage:

rsumshort := proc(L)
option inline;
    `+`(op(map(`/`,L)));
end proc;

L:=[seq(cat(`a`,i), i=1..10000)]:

time(rsumshort(L));                 
                                     0.044
time(rsum(L));                  
                                    10.064

 

A couple suggestions:

1.  As Joe said, If you are solving several equations for several variables, do them together:

eqn1:=.6907*x3+.3336*y3+.6415*z3-2.203 = 0;
eqn2:=cos(theta)*x3+sin(theta)*y3-1. = 0;
solve({eqn1,eqn2}, {x3,y3});

Maple has more sophisticated strategies than just solving for a variable and substituting into an equation.

2. If you are going to solve the equations one as a time, use eval instead of assigning to a variable:

eqn := x+y;
eqn:=eval(eqn, x=1);
is generally much safer than:
eqn := x+y;
x:=1;

solve using sets around the variables gives nice outputs for doing this:

ans1:=solve({eqn2}, {x3});
eqn1a := eval(eqn1, ans1);
solve({eqn1a}, {y3});

3. Don't send floating point numbers into solve.

(In fact, if your equations don't have symbols you aren't solving for, use fsolve.)

In this case, you can't avoid using solve, but solve doesn't like floats.  If it sees floating point numbers in the input, it calls 'convert(eqns, rational)' on the input and then evalf() on the output.  This often hides what is going on and may not give you what you intend (especially if the floats are approximations of non-rational numbers).

So if you start with input:
eqn1:=0.6907 x3 + 0.3336 y3 + 0.6415 z3 - 2.203 = 0
before solving maple calls convert(eqn1, rational) and turns it into
6907/10000*x3+417/1250*y3+1283/2000*z3-2203/1000 = 0

(this is maybe okay, unless your equations were supposed to be a 4 decimal place approximation of say: 67/97*x3+21/89*2^(1/2)*y3+34/53*z3-81/52*2^(1/2) = 0 )

And while solving, that is in turn simplified to have no fractions:
6907*x3+3336*y3+6415*z3-22030 = 0
 

When a solution is found, it will have only integers in it as well:
y3 = (6907-22030*cos(theta)+6415*z3*cos(theta))/(-3336*cos(theta)+
6907*sin(theta))

And this answer is already in "lowest terms" and I think we can agree that dividing top and bottom by 1000 would be silly (if you are keeping things as fractions not converting to floats).  In fact, in Maple, it would be pointless since the automatic simplifier would put you back where you started. 

Now, if you started with floating point numbers, maple actually gives you evalf of the integer answer, and that might look a little wierd if you were expecting maple to do the whole calculation with floating point numbers.
ans:=y3 = (6907.-22030.*cos(theta)+6415.*z3*cos(theta))/(-3336.*cos(theta)+6907.*
sin(theta));

You could however coerce it in the following way:
lhs(ans)=expand(numer(rhs(ans))/10000.)/expand((denom(rhs(ans))/10000.));
 

A couple suggestions:

1.  As Joe said, If you are solving several equations for several variables, do them together:

eqn1:=.6907*x3+.3336*y3+.6415*z3-2.203 = 0;
eqn2:=cos(theta)*x3+sin(theta)*y3-1. = 0;
solve({eqn1,eqn2}, {x3,y3});

Maple has more sophisticated strategies than just solving for a variable and substituting into an equation.

2. If you are going to solve the equations one as a time, use eval instead of assigning to a variable:

eqn := x+y;
eqn:=eval(eqn, x=1);
is generally much safer than:
eqn := x+y;
x:=1;

solve using sets around the variables gives nice outputs for doing this:

ans1:=solve({eqn2}, {x3});
eqn1a := eval(eqn1, ans1);
solve({eqn1a}, {y3});

3. Don't send floating point numbers into solve.

(In fact, if your equations don't have symbols you aren't solving for, use fsolve.)

In this case, you can't avoid using solve, but solve doesn't like floats.  If it sees floating point numbers in the input, it calls 'convert(eqns, rational)' on the input and then evalf() on the output.  This often hides what is going on and may not give you what you intend (especially if the floats are approximations of non-rational numbers).

So if you start with input:
eqn1:=0.6907 x3 + 0.3336 y3 + 0.6415 z3 - 2.203 = 0
before solving maple calls convert(eqn1, rational) and turns it into
6907/10000*x3+417/1250*y3+1283/2000*z3-2203/1000 = 0

(this is maybe okay, unless your equations were supposed to be a 4 decimal place approximation of say: 67/97*x3+21/89*2^(1/2)*y3+34/53*z3-81/52*2^(1/2) = 0 )

And while solving, that is in turn simplified to have no fractions:
6907*x3+3336*y3+6415*z3-22030 = 0
 

When a solution is found, it will have only integers in it as well:
y3 = (6907-22030*cos(theta)+6415*z3*cos(theta))/(-3336*cos(theta)+
6907*sin(theta))

And this answer is already in "lowest terms" and I think we can agree that dividing top and bottom by 1000 would be silly (if you are keeping things as fractions not converting to floats).  In fact, in Maple, it would be pointless since the automatic simplifier would put you back where you started. 

Now, if you started with floating point numbers, maple actually gives you evalf of the integer answer, and that might look a little wierd if you were expecting maple to do the whole calculation with floating point numbers.
ans:=y3 = (6907.-22030.*cos(theta)+6415.*z3*cos(theta))/(-3336.*cos(theta)+6907.*
sin(theta));

You could however coerce it in the following way:
lhs(ans)=expand(numer(rhs(ans))/10000.)/expand((denom(rhs(ans))/10000.));