Carl Love

## 25 Badges

11 years, 345 days
Himself
Wayland, Massachusetts, United States
My name was formerly Carl Devore.

## Boundary conditions...

@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.

## Simpler version...

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.

## Simpler version...

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.

## Anomaly...

@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?

## Anomaly...

@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?

## Version 17.00...

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

## Version 17.00...

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

## Order of assumptions doesn't matter...

@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.

## Order of assumptions doesn't matter...

@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.

## assume(a::complex) not needed...

@Andriy I certainly agree that this thing where additionally creates a third copy of the variable is a bad design (not sure if it's by design or unintended and hence a bug). But, for what it's worth, I'll point out that assuming d::complex is redundant in this case. It seems that assuming an inequation automatically includes the complex assumption, as the following shows:

restart;
#assume nothing
evalc(Re(a));
a
assume(a<>0);
evalc(Re(a));
Re(a~)
restart;
assume(a::complex);
evalc(Re(a));
Re(a~)

## assume(a::complex) not needed...

@Andriy I certainly agree that this thing where additionally creates a third copy of the variable is a bad design (not sure if it's by design or unintended and hence a bug). But, for what it's worth, I'll point out that assuming d::complex is redundant in this case. It seems that assuming an inequation automatically includes the complex assumption, as the following shows:

restart;
#assume nothing
evalc(Re(a));
a
assume(a<>0);
evalc(Re(a));
Re(a~)
restart;
assume(a::complex);
evalc(Re(a));
Re(a~)

## Please upload worksheet...

It looks like an interesting problem. Please either upload a worksheet or post the code in a plaintext format so that I can cut-and-paste it. Then I will work on the problem.

## x, y, z must be treated identically...

@antfaulkner There are still significant bugs in your procedure Fourth. It is obvious that something is wrong because you don't treat x, y, and z identically. See the Wikipedia article on the Runge Kutta fourth-order method in http://en.wikipedia.org/wiki/Runge%E2%80%93Kutta_methods. Let me know if you need more-detailed help.

When you try to upload a worksheet, make sure that you complete all three steps:

• Browse
• Click "Upload"
• Click "Insert Link" or "Insert Contents" (which inserts the link also).

## x, y, z must be treated identically...

@antfaulkner There are still significant bugs in your procedure Fourth. It is obvious that something is wrong because you don't treat x, y, and z identically. See the Wikipedia article on the Runge Kutta fourth-order method in http://en.wikipedia.org/wiki/Runge%E2%80%93Kutta_methods. Let me know if you need more-detailed help.

When you try to upload a worksheet, make sure that you complete all three steps:

• Browse
• Click "Upload"
• Click "Insert Link" or "Insert Contents" (which inserts the link also).

## Potential cancellation of zero divisors...

Maple's simplify will convert (x^2-1)/(x-1) to (x+1). One could argue that these expressions are not equal because they are not equal at x=1. Could this be the root of your issue?

 First 662 663 664 665 666 667 668 Last Page 664 of 699
﻿