@ThU:

For the z coordinate of the intersection:

z:=y*log(x);
Subs(solve(y*log(x)=y+x*log(x),{y}),z);

No?

Mac Dude

@ThU:

For the z coordinate of the intersection:

z:=y*log(x);
Subs(solve(y*log(x)=y+x*log(x),{y}),z);

No?

Mac Dude

On re-reading this it occurred to me that this distance is also a useful quantity when trying to fit a function to a data set where the independent-variable values have errors.

E.g. often I want to fit y=f([parameters],x) to a data set [[x],[y]] weighted with the errorbar on the values in [y]. If the values in [x] are exact it is easy: find the expressions for the rms deviation of y from f([parameters],x) (i.e. the penalty function) with proper weighting & minimize that by varying parameters, with an appropriate method. Packages in Maple will do this for me. If the values in [x] also have errors, it is not so obvious how to do it right. I have read of heuristic schemes where df/dx at the values of [x] is used to estimate the increase in error bar in the values in [y] due to the uncertainty in x, but that is inaccurate for all but the most well-behaved functions f, and not shown to be correct--or even approximately so---in any rigorous sense.

Using the distance of f(x) to the data points as penalty function seems like a much more rigorous---if more complex---way to do this. Now the errors in both x and y are easily incorporated in weighting the rms  deviation (now: distance) of function to data. Interestingly enough; this example also exposes the difficulty of practical application: The distance of a data point to a curve (usually defined as the length of the shortest vector from the data point to a point on the curve that is normal to the tangent of the function at that point) is not in general a unique value making its evaluation a bit of a pain, even more so at higher dimensions.

This is fun. Experts in this field probably know all this; but re-reading this post made me realise what is going on in such fitting problems (which I have occasionally had to deal with). So, thanks for this post.

Mac Dude.

Could we make this an Advertisement Free Zone (Tm) ? It is one thing for Maple employees exposing certain aspects of the system (which can be very helpful and/or interesting) but another entirely for companies to push their wares here. I believe the Maplesoft Website has a mechanism to advertise Maple-related products; that ought to do it.

Mac Dude.

@Mamari So I just tried it and, as expected, defining e.g. f(t):=t^2 does not a function create. I.e. f(3) does not resolve to 9; even t:=3;f(t); does not resolve to 9. The variables palette is slightly confusing in that it dos show f defined as function; however, it does not act like one. To me it seems there is---effectively---just a new name f(t).

What is this "box dialog" you mention?

M.D.

@Mamari So I just tried it and, as expected, defining e.g. f(t):=t^2 does not a function create. I.e. f(3) does not resolve to 9; even t:=3;f(t); does not resolve to 9. The variables palette is slightly confusing in that it dos show f defined as function; however, it does not act like one. To me it seems there is---effectively---just a new name f(t).

What is this "box dialog" you mention?

M.D.

Several issues here:

1. Assignments in Maple are done with ":=", not "=".   "=" sets up an equation.

2. While "F(0):=0.999" actually may work (making f(0) the name of a variable) it does not define a function. I suggest you say "f0:=999" to define a variable.

3. "f(t):=..." almost certainly does not what you want. To define a function f(t) you need to use the arrow operator like so:

    f:=(t)->...

4. plot is not a part of the plots package so you just say

   plot(f(t),t=0..20).

Mac Dude

Several issues here:

1. Assignments in Maple are done with ":=", not "=".   "=" sets up an equation.

2. While "F(0):=0.999" actually may work (making f(0) the name of a variable) it does not define a function. I suggest you say "f0:=999" to define a variable.

3. "f(t):=..." almost certainly does not what you want. To define a function f(t) you need to use the arrow operator like so:

    f:=(t)->...

4. plot is not a part of the plots package so you just say

   plot(f(t),t=0..20).

Mac Dude

Ok, so here is what I came up with, based on your suggestion:

Subs:=proc(eqn::seq(equation),elemt::Element) # option overload;
description "subs command for Elements or BeamLines";
local qs:=[exports(elemt)];
return Record(seq(qs[i]=:-subs(eqn,q[qs[i]]),i=1..numelems(qs)));
end proc;

This is a part of a package that gets loaded using with() and that also defines the Element type I use in the arglist.

I did not yet manage to get the overload to work, that's why it is commented out. If I overload subs (with small s) then it fails to use my subs procedure for more than one replacement given.

Thanks,

M.D.

Ok, so here is what I came up with, based on your suggestion:

Subs:=proc(eqn::seq(equation),elemt::Element) # option overload;
description "subs command for Elements or BeamLines";
local qs:=[exports(elemt)];
return Record(seq(qs[i]=:-subs(eqn,q[qs[i]]),i=1..numelems(qs)));
end proc;

This is a part of a package that gets loaded using with() and that also defines the Element type I use in the arglist.

I did not yet manage to get the overload to work, that's why it is commented out. If I overload subs (with small s) then it fails to use my subs procedure for more than one replacement given.

Thanks,

M.D.

@ilods I have not looked at Preben's solution but in my own work I force numerics by substituting as many variables as I can with their explicit values early on, before doing any manipulation. Then Maple combines the numeric terms as much as possible (maybe I need to enlist the help of evalf, expand, simplify or such) and I am left with an expression depending only on x and y, or whatever the case may be; so I can e.g. plot it. Setting Digits to 15 as Axel suggests gives maximum accuracy while still allowing Maple to use hardware floating point arithmetic (I do that in my .mapleinit file) so things are at least reasonably fast.

As for the length: you can of course suppress output with ":" instead of ";" at the end. Maple will grind through the long expressions and when you then substitute the values it may all come out right, if not fast. I believe you could also change the threshold for this kind of message (maybe it is a kernelopt? I forgot) but that seems ill advised.

Mac Dude

@ilods I have not looked at Preben's solution but in my own work I force numerics by substituting as many variables as I can with their explicit values early on, before doing any manipulation. Then Maple combines the numeric terms as much as possible (maybe I need to enlist the help of evalf, expand, simplify or such) and I am left with an expression depending only on x and y, or whatever the case may be; so I can e.g. plot it. Setting Digits to 15 as Axel suggests gives maximum accuracy while still allowing Maple to use hardware floating point arithmetic (I do that in my .mapleinit file) so things are at least reasonably fast.

As for the length: you can of course suppress output with ":" instead of ";" at the end. Maple will grind through the long expressions and when you then substitute the values it may all come out right, if not fast. I believe you could also change the threshold for this kind of message (maybe it is a kernelopt? I forgot) but that seems ill advised.

Mac Dude

To expand a little on Jörg's answer:

In Maple, assignments are done by ":=". The "=" is a logical expression, not an assignment.

You define a function by writing f:=(x)-> a*x+b*x^2+c  i.e. using the arrow operator (there are other ways but this is the quickest way for a statement function). Assigning an expression to f(x) makes the whole f(x) a name (which is not f(y)); usually not what you want.

As to Maple vs Matlab: it really depends what you want to do. Maple is primarily a Computer Algebra System; Matlab is primarily a tool for numeric evaluations esp. involving matrices. So if you are looking for analytic solutions, Maple is your friend. If you routinely deal with large numerical problems; Matlab is. (And, yes, I am simplifying greatly here.)

Note however, that both systems have aspects of the other side as well (certainly Maple can do a lot of numerics; I believe late versions of Matlab have a certain amount of symbolic capability added) and in fact can access each other at a certain level (the details of which I have not explored at all).

HTH,

Mac Dude

To expand a little on Jörg's answer:

In Maple, assignments are done by ":=". The "=" is a logical expression, not an assignment.

You define a function by writing f:=(x)-> a*x+b*x^2+c  i.e. using the arrow operator (there are other ways but this is the quickest way for a statement function). Assigning an expression to f(x) makes the whole f(x) a name (which is not f(y)); usually not what you want.

As to Maple vs Matlab: it really depends what you want to do. Maple is primarily a Computer Algebra System; Matlab is primarily a tool for numeric evaluations esp. involving matrices. So if you are looking for analytic solutions, Maple is your friend. If you routinely deal with large numerical problems; Matlab is. (And, yes, I am simplifying greatly here.)

Note however, that both systems have aspects of the other side as well (certainly Maple can do a lot of numerics; I believe late versions of Matlab have a certain amount of symbolic capability added) and in fact can access each other at a certain level (the details of which I have not explored at all).

HTH,

Mac Dude

@Alejandro: It looks like I ran into this error because I created the Array with only one element so I may in fact have had a situation like you show, with the "unusual" range. I do this because I cannot have unused lements at the end of the array. It is quite curious.I don't have the crashing version anymore and my code (with datatype anything like Preben suggested) works so I can't reliably reproduce what I did but I know I did not specify an actual range (like 1..2 or so) in the Array constructing function (Array()). Now I am wondering whether I can get this to work with strings and a valid initial range...

The reason why I ranted about the bug is that in less than a year of doing serious (in the sense that I actually want and use the results) work with Maple I have run into quite a number of "undocumented features" that by and large are not that obscure. While I fully understand that software has bugs; it is also true that bugs can be fixed, esp. relatively simple ones like the issue we are talking about here. The dynamic length of rtables is an advertised (in the handbooks) feature and not some obscure, rarely known oddity. It would be a part of the test suite(s), one might have thunk...

Oh well, "Caveat Coder". Maybe I'l submit a software performance report.

Mac Dude.