On the one hand, it seems that you want tend to go from 0 to 12; and on the other hand, it seems that you want it to go from 0 to 50. You can't do both at the same time! Obviously, you know that; so I have to ask you to describe more precisely what you are trying to achieve.

Side note: You need to set the value of alpha. That problem won't manifest until you fix the tend problem.

@emma hassan Change the subs command from subs({...}, Points) to

subs(XY, op(SOL), BC, Points);

There should not be any curly braces {}, and the order is important: BC must come after op(SOL).

@emma hassan Change the subs command from subs({...}, Points) to

subs(XY, op(SOL), BC, Points);

There should not be any curly braces {}, and the order is important: BC must come after op(SOL).

Someone, probably your classmate, just asked that four days ago. Here's the link.

@marc005 This limit, if it exists at all, is definitely not a limitation on Matrix size; it is a limit on the size of a Matrix that can be displayed in the browser.

You can easily select chunks of a large Matrix for browsing. Say M is the Matrix,

M[r1..r2, c1..c2]

gives (rows r1 to r2) X (columns c1 to c2).

@emma hassan I think that the values of U[0,4], ..., U[3,4] need to be filled by the boundary conditions. I don't think that they are meant to be solved for. I don't know enough about this type of problem to help you more with that.

Regardless of that, once the boundary grid points have values assigned, the commands are still GenerateMatrix and LinearSolve.

@emma hassan I think that the values of U[0,4], ..., U[3,4] need to be filled by the boundary conditions. I don't think that they are meant to be solved for. I don't know enough about this type of problem to help you more with that.

Regardless of that, once the boundary grid points have values assigned, the commands are still GenerateMatrix and LinearSolve.

I had used "%0.5s" as the output format code, which specifes a minimum width of 0 and a maximum width of 5. This can be simplified to just "%s" because the strings being passed in already have a maximum length of 5. Since the format code does not depend of the block length, there's no need for the variable WFO. So the final command can become

sprintf(cat("%s", " %s" $ words-1), sscanf(T, cat(WFI $ words))[]);

Notice the space before the second %s. That's what puts the spaces between the blocks.

I had used "%0.5s" as the output format code, which specifes a minimum width of 0 and a maximum width of 5. This can be simplified to just "%s" because the strings being passed in already have a maximum length of 5. Since the format code does not depend of the block length, there's no need for the variable WFO. So the final command can become

sprintf(cat("%s", " %s" $ words-1), sscanf(T, cat(WFI $ words))[]);

Notice the space before the second %s. That's what puts the spaces between the blocks.

@acer My results agree with yours now. I don't know what happened that caused my earlier results. May I assume that your results otherwise agree with mine: that additionally causes an additional copy of the variable to be created?

@acer My results agree with yours now. I don't know what happened that caused my earlier results. May I assume that your results otherwise agree with mine: that additionally causes an additional copy of the variable to be created?

@acer Version 17.00. Do you get different results in another version?

@acer Version 17.00. Do you get different results in another version?

@Markiyan Hirnyk You wrote:

After reading your long comment I still don't understand why the code works with
assume(d <> 0); additionally(d::complex);,
but it does not work with
assume(d::complex);additionally(d<>0);.

Andriy's four examples above show that the order that the assumptions are made does not matter. What matters is whether there is an assignment between the assume and additionally that saves the intermediate version of the assumed variable.

@Markiyan Hirnyk You wrote:

After reading your long comment I still don't understand why the code works with
assume(d <> 0); additionally(d::complex);,
but it does not work with
assume(d::complex);additionally(d<>0);.

Andriy's four examples above show that the order that the assumptions are made does not matter. What matters is whether there is an assignment between the assume and additionally that saves the intermediate version of the assumed variable.