@Christopher2222 So Fit does have a way to set the starting value.

BTW, the solution Markiyan finds with DirectSearch (posting below) is almost certainly the alias of your solution. You should find that his frequency is very close to the sampling frequency minus your fequency (b after accounting for factors of 2Pi, units etc.). Aliasing can go either way so you will need to decide which one is the true frequency. The data in general will not give you that unless you have them at two different samplig frequencies.

M.D.

I understand that this post is about programs like Maple and their ability to integrate sketches and code and do things in what is called a more natural way than using a spreadsheet.

But I can't help thinking: Would Brunel have used Maple if he had access to it. It is not clear at all I think. The reason why I think so is that he may have been suspicious of using a system spitting out solutions that maybe he could not really check because of the complexity.

The translation to today's world should be that we as users are called upon to double and triple check our results before we draw real-world conclusions. We all know examples where we had to deal with results that just did not seem right—and were not right—because of some subtlety in using Maple that we did not fully appreciate.

So while I, just like the OP, prefer Maple over a spreadsheet for many physics or engineering problems, the inspiration I would take from someone like Brunel is to make sure I understand every step in the calculation and make sure I understand the solution that Maple comes up with and why I should trust it. Check the numerics, check the limiting cases, check for round-off and check the algorithms if possible. Systems like Maple are incredibly powerful, but they can lull us into an uncritical believing of the results without deep understanding.

Just my $0.02

Mac Dude

@acer Hmm, I did not check the time spacing of the samples. You are certainly correct, if the samples were taken at irregular time then the straight-forward Fourier transformation we did is, at best, approximate. (I guess I always took my data at regular time points when I wanted to extract frequencies so I tend to take regularity for granted.)

The sine/cosine-fitting business I mention to extract the phases will still work as long as the frequency value is right. If the frequency is off, the sine/cosine fit will not give a good result. One way out is to do a first-order expansion (about the best value) of the frequency dependence and fit that to get a better estimate of the frequency. I did such a thing once years ago; it works but is more involved timewise than I can justify right now. As I said, direct fitting of the frequency is bound to fail for the high-frequency component. Of course, for a single case one can always tweak the frequency by hand until the Chi-sq of the sine/cosine fit is minimized... I would not use that prodedure before I announced having found a new planet, though :-)

M.D.

@tomleslie I now believe this is actually Maple's internal representation. The help page for the arithmetic operators says this:

Such expressions can be one of three types: type `+`, type `*`, or type `^`. That is, the expression a - b is of type `+` with operands a and -b. Similarly, a/b is of type `*` with operands a and b^(-1).  Finally, a^b is of type `^` with operands a and b.

where "such expressions" refers to expressions involving arithmetic operators (*,-,*,/,^). So there is no type `/`, for instance. Likewise, the - sign is unary so Maple implements a-b as `+`(a,-b).

At least that is my understanding.

M.D.

Ok, answering my own question. As it turns out, it is actually explained in the help file for the overload() function, if in a somewhat indirect way (the example dealing with the minus sign). As usual, the Programming Guide has helpful information as well (although this one is not spelled out there).

The trick is indeed to rewrite the `^` function using overload in the following way:

`^`:=overload([ # overload takes a list of procs as its argument           proc(element::Element,n::algebraic) option overload; # procedure to use for Element type
           ...
           end proc,
           proc(element::algebraic,n::algebraic) option overload; # procedure to use for something else
           return :-`^`(element,n); # hand this one over to Maple's `^`
           end proc
           ]); # close the overload arglist

This works even when calling Lattice:-`^` explicitly (since the overload is now completely handled in there).

And the funny conversion of / into the exponent form is actually explained (or at least stated) in the help file for Maple's arithmetic operators.

M.D.

@asa12 As kitonum's results show, only the difference of t2 and t1 matter; the absolute values do not enter.

And kitonum is correct of course; if you have a larger data set then you need to do curve fitting. be advised, though, that fitting frequencies (w) is tricky and needs good initial estimates in order to succeed. I have had success in refining frequency estimates by using a first-order expansion to improve the estimate.

Of course we are a bit speculating here as you have not told us the exact nature of what you want to achieve...

M.D.

PS: kitonum took the step of linearizing the system by taking the arcsin. Clever.

@Paul Thanks very much for the reply and promised fix as well as for stating the conditions under which the bug shows up (which is important to know). I will be looking forward to the fix (OS X in my case).

Any chance that fix can be carried back at least one or two versions of Maple? While I myself use mostly Maple 2015 now and will be ok; not everyone is current all the time. Given the severity of this bug I think carrying the fix back at least a couple of versions should be considered.

Thanks,

M.D.

PS: I am aware of Edgardo's work-around and will try/use it on my old Maple 15 installation on PPC Macs that cannot run later versions of Maple. But in some cases that approach may have unintended side effects.

I really would like someone from Maplesoft to comment on this. After all, this really is not some weird fringe case.

Mac Dude.

@Carl Love It's more bizarre than that: If I prepend 0+ to the expression the answer is correct. If I prepend tone+ to the expression (tone just being an unassigned symbol) the answer is wrong. This on Maple 2015 on Mac OS X 10.10 Yosemite.

It is actually a bit unsettling. If Maple screws up with such a trivial case, how can one "trust" its results for much more complicated real-life cases where mere inspection does not really work anymore. I hasten to add that I do not, as a rule, "trust" any software and always try to double-check the result I am given, by backsubstitution if possible or other means,  but still...

M.D.

Well, it isn't obvious whether your code snippets are supposed to be Maple code or pseudo code. But a few observations:

In general, don't use implied multiplication. For C1cosh() write C1*cosh() etc. (assuming that is what you mean).

Assignments in Maple are written as := . The simple = sign denotes an equation (a Maple object).

In Maple, variable names are case sensitive. C1 is not the same as c1.

Please review your code snippets, fix them up as well as you can and try again.

Mac Dude

@gkokovidis Caveat 1: time()-st only measures evaluation time, not the time spent simplifying or in the GUI. It isn't always obvious what is what (e.g. simplify() is not simplification in this sense and does incur CPU time measurable by time()).

Caveat 2: as written, time()-st returns the total CPU time. This specifically means that if you compare a parallelized version of code against a single-threaded one the parallelized will appear to be not any faster as the total CPU time is the sum of the times spet on each CPU. time[real]() returns the wall-clock time so can be used to quantify the effect of parallelizing code.

As others have mentioned, CodeTools:-Usage will give more detailed info but works only on expressions (incl. procedures).

M.D.

@ecterrab Thanks very much. Just downloaded the update and will work on this later.

M.D.

@tomleslie I see what you mean. I may have overlooked the second statement involving sym().

As for translation of toolbox functions, I agree 100% with you. In this case, by "translation" I was really implying to do those bits by hand. There is rather obviously no way an automatic translator could know what is behind a toolbox call, unless the translator is actually a part of the toolbox.

I have done translations of relatively large programs from Mma to Maple using Maple's translator. Not a particularly joyful experience: The translator mostly did the mechanical aspects (converting = to :=, [] to () and the like). A number of Mma constructs had direct Maple counterparts that the translator missed. But eventually I ran into structural differences that did not translate and had to be resolved by re-programming those parts. This mostly had to do with grouping constructs like modules and such. Unfortunately I ended up with code that really wasn't optimal for Maple, and it never fully recovered from that. Mind you, that code was at least an order of magnitude longer and much more complex than the OP's code here.

As for the code of the OP, it seems that starting from the translated code and then fixing up the pieces that did not make it across should work and may be the fastest way to get some results. It looks like the OP has access to Matlab so (s)he can verify the Maple code. The code-structure does not look that complex to me (but then, I did miss the subtlety with the sym() calls...)

M.D.

@tomleslie Hmm... needing symbolics to create a matrix and fill it with zeros? Seems odd, to say the least.

I don't have Matlab so cannot run the OP's code. But I suggest the OP check it and the need for symbolics. It seems that he is doing numeric calculations mostly.

Having said that; why would symbolics make the translation to Maple difficult or impossible? I can see that Maple's translator chokes, but there are only very few statements which might involve symbolics; they should be amenable to hand-translation.

M.D.

First, read up on Maple's Vector and Matrix and Array types as you will need these.

The matrix Q is not initialized and you are using an undefined element (Q(3,3)), so you need to initialize it in some fashion. The simple way is to use the bracket notation:

Q:=<<1,2,3>|<4,5,6>|<7,8,9>>;

where each triplet becomes one column.

The assignments to T should work once you replace the = with := . In Maple, = is a logical operator (unless used to assign to keyword parameters in function calls), assignments are done with := . The reason this works because of something called "Programmer Indexing"; read up on it in the Programming Guide (a very worthwhile document if you want to learn Maple in earnest). However, the "proper way" to do this woud be to declare T and use [ ] for the indexing:

T:=Matrix(3,3,datatype=float);

...

for i from 1 to numelems(R) do

T[1,1]:=cos(R[i])^2;

...

end do;

which reminds me that R is not assigned anything either. Since you are showing a code snippet, these assignments are presumably happening earlier.

inv() is presumably Matlab's matrix inverse, in Maple this is LinearAlgebra:-MatrixInverse().

Matrix multiplication in Maple is . (period). * will either fail or do element-wise multiplication. Strictly speaking, element-wise operators have a trailing tilde, e.g. A*~B, but in newer Maple versions the tilde's are not always necessary.

That leaves the Qk(:;:;i) construct, that I don't know off hand how to handle, esp. not knowing Matlab very well. Presumably, Qk is a 3 by 3 by numelems(R) Matrix. In Maple, that would be an Array (Maple's Matrices are 2-d; Arrays can have any number of dimensions). Matlab's wild card index : is .. (two dots) in Maple; but I have had a lot of trouble with constructs like Qk[..,..,i]. You'll need to experiment here. Another potential pitfall is that Qk[..,..,i] for a given i is NOT of type Matrix. To use the LinearAlgebra routines on it you'd need to convert it with

convert(Qk[..,..,i],Matrix);

In Maple, you could also do this as a list of Matrices; i.e.

Qk:=[M1,M2,M3,M4];

and your Qk(:;:;i) would become something like Qk[i][..,..] . Again, you will want to try these until it works the wayyou want it to.

Finally, be aware that Maple can (and often will) merrily store whole expressions of ever-increasing length if it runs across undefined variables ("names" in Maple lingo). Specifying the datatype as float in the various declarations helps identifying such situations as Maple will barf if you try to assign an unevaluated expression to a float.

I hope this helps some what.

Mac Dude