Dr. David Harrington

6140 Reputation

21 Badges

19 years, 331 days
University of Victoria
Professor or university staff
Victoria, British Columbia, Canada

Social Networks and Content at Maplesoft.com

Maple Application Center
I am a professor of chemistry at the University of Victoria, BC, Canada, where my research areas are electrochemistry and surface science. I have been a user of Maple since about 1990.

MaplePrimes Activity

These are replies submitted by dharr

In Maple 2024, I get a warning "Warning, units problem, not enough information to unambiguously deduce the units of the variables {V, n}; proceeding as if dimensionless"

in the integration limits you have n times a unit being a volume, which seems strange. Do you mean something like V = n*V1..m*V1 where n is dimensionless and V1 is a volume. Or did you mean n and m to have values before the integral? 

plot3d(-x^2/9 + y^2/4, x = -5 .. 5, y = -5 .. 5)

Do you mean surface? Do you want the shortest path on the surface?

@salim-barzani I believe you forgot to apply the chain rule in the part you did by hand. Here is a corrected version that verifies with pdetest on the original equation.


@dharr I am trying to understand how you get from the pde to the ode. I can't get Maple to do this so I am wondering if there is some hidden assumption here that needs to be specified. If so, that may be why pdetest fails. Or the solution may not be correct.


As others have already asked you to before, please upload your actual worksheet using the green up-arrow in the Mapleprimes editor (not just an image.) That way, we don't have to retype your input, and you may get a better response.

@mmcdara Nice analysis. Vote up. No, I don't have the GlobalOptimization toolbox.

@Ariathm It might be finding the wrong local minimum. In non-linear least square problems like this getting the initial guess values close to the right answer is key to success, and I might have chosen some bad values.

I noticed p__eng is strangely like p__3 but not quite. Perhaps it is better to calculate these in Maple from some earlier expression, rather than enter them by hand. Especially if you have some form without the fractional powers, it will help.

@dharr The long calculation has probably to do with the difficulty of finding derivatives for the horrible expression. The following simplifies the expression enough that it proceeds to a solution. I used simplify(..,symbolic) to get rid of the fractional powers. In principle that can give invalid results, but here I think it is probably OK since everything is positive, but you should check that the answer makes sense. Note that the kappa value found is at the end of the range.


Looks OK, given that kappa is not correct yet



The error message is "Error, (in fsolve) {delta[0], y[0]} are in the equation, and are not solved for", and indeed you have not given values for delta[0] or y[0].

For future reference, it is easier if you upload your worksheet using the green up-arrow in the Mapleprimes editor.

@michele Since you now get the same answer, you and I are now almost certainly checking the same polynomials, so the ratios between our times is now meaningful. For other polynomials the time will be different,, e.g., after running the worksheet, go back to the execution group with p:= etc and hit enter, then enter on the CodeTools:-Usage line and your answer will have x^25268 in and the time will be about 50% longer. If you choose 2 polynomials with gcd = 1, the times will be significantly longer.

Bottom line: it depends on the polynomials.

@michele I'm just worried that for different versions of Maple, different number of random numbers might be used, leading to a diffferent answer for later calculations, even if the first one, r, is the same. An across-versions comparison might need to save the actual polynomial to an .m file and the read them in. That seems like overkill, so try running this to see if you get the same answer, and then the timing comparisons might make more sense.

Edit: 13th Gen Intel(R) Core(TM) i5-1335U   1.30 GHz; 16.0 GB RAM, in "best performance" mode.



`Standard Worksheet Interface, Maple 2024.1, Windows 11, June 25 2024 Build ID 1835466`


"X86 64 WINDOWS", "x86-64", 12



r:= 87*x^10 - 56*x^9 - 62*x^3 + 97*x - 73;


p:=expand(r*randpoly(x, degree=10^6)):
q:=expand(r*randpoly(x, degree=10^5)):


memory used=18.21MiB, alloc change=8.75MiB, cpu time=1.76s, real time=8.61s, gc time=15.62ms



Download gcd.mw

@michele The version of Maple could make a difference here, and the exact random numbers might not be the same (which seems to be the case in the second example because a different answer is obtained). Different polynomials might take different times so unless you average a lot of examples, it is hard to know what an average time is. So for the class polynomials you are using these might not be typical.

So are these results not acceptable to you? You are getting answers without crashes for what I would call large degree polynomials. Your CPU and real times are the same suggesting only one CPU, and perhaps an older computer without multiple cores?

I assume grade means degree here? Some further details about typical coeffs, number of terms, degree etc would be helpful. For integer coeffs, dense or sparse number of terms, degree 10^5 seems feasible, but with both degrees 10^6, it took longer than I was willing to wait. (This was Maple 2024 on Windows 11.)


r:=randpoly(x, degree = 15);
p:=expand(r*randpoly(x, dense, degree=10^5)):
q:=expand(r*randpoly(x, dense, degree=10^5+20)):



memory used=70.30MiB, alloc change=35.88MiB, cpu time=4.72s, real time=19.49s, gc time=0ns


p:=expand(r*randpoly(x, degree=10^6)):
q:=expand(r*randpoly(x, degree=10^5)):


memory used=8.03MiB, alloc change=-29.05MiB, cpu time=1.06s, real time=3.67s, gc time=0ns



Download gcd.mw


@MaPal93 I'm not sure how they are chosen. They seem to be points with integer coordinates on a grid, but I suppose if a region was too small for that then some rationals would be chosen. Note that for regions 2 and 3, the horizontal axis has no particular significance. I think the basic idea is to have any point for which evaluation proves that the equations and inequalities are satisfied; in that sense it doesn't matter where in the region it is.

@C_R With floating point limits, it is supposed to switch to numerical integration. From ?int

"If any of the integration limits of a definite integral are floating-point numbers (e.g. 0.0, 1e5 or an expression that evaluates to a float, such as exp(-0.1)), then int computes the integral using numerical methods if possible (see evalf/Int). Symbolic integration will be used if the limits are not floating-point numbers unless the numeric=true option is given."

But the alternate form also gave a numeric answer with 0..1,0..1 which is not expected, unless the floats in the integrand triggered this.

1 2 3 4 5 6 7 Last Page 1 of 63