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

@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~)

@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~)

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.

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

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

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?

Bryon wrote:

We published another small update to the editor in MaplePrimes. The problems you were experiencing should now be taken care of.

• If you are referring to the "Sorry, something went wrong" problem, that seems fixed.
• If you are referring to the problem of the HTML editor being a blank window in the old editor, that is not fixed. It is still a blank window.
• If you are referring to the problem of the spacing of bulleted lists, I am not sure about the status of that. This list is spaced correctly, but I could not correct the spacing on an old post.

What exactly does refreshing one's browser entail? I've shut down and restarted Firefox. Should I dump all MaplePrimes cookies? re-install the browser?

@antfaulkner The upper limit of numeric integration for your procedures ESys and Fourth is controlled by global variable T, which is set to 4 in the code posted in the original question in this thread (I couldn't find any attached file in your reply). To get the equivalent of soln(5), you'd need to set T to 5 (or more), run ESys or Fourth, and then get the values from (x[N],y[N],z[N]) (or (x[25],y[25],z[25]) assuming that you keep h=0.2).

@antfaulkner The upper limit of numeric integration for your procedures ESys and Fourth is controlled by global variable T, which is set to 4 in the code posted in the original question in this thread (I couldn't find any attached file in your reply). To get the equivalent of soln(5), you'd need to set T to 5 (or more), run ESys or Fourth, and then get the values from (x[N],y[N],z[N]) (or (x[25],y[25],z[25]) assuming that you keep h=0.2).