@Mac Dude I obtain a plot much like yours, using the following code. But I see this as wrong, because it does not account for the fact the the first column (presumably the independent data) is not equally spaced.

Download hmm.mw

I did some other analysis earlier today. I'll try to clean it up now.

@Maple4evergr8 Did you say what OS you use? Sorry, if i missed that. It might be key to why the popup plot device is not working from you from the Command Line Interface.

I think that I don't properly understand why you have to use the CLI. It sounds to me like part of your requirements are some modal (confirmation) dialogue stuff. So altogether it seems you want console/plot separation, confirmation dialogues, ... (other?). Maplets are useful for all that, as are Embedded Components. But you might be able to get by with the readline command in the CLI for confirmation.

It might not be important to you, but the commandline interface also has plot drivers which do not fully respect some modern plot features, sich as programmatic 2D plot size, background image, and some other stuff.

@Maple4evergr8 You wrote, "So, is there an easy way in general to save "frames" of an animation, which you afterwards then use to re-create the animation?"

See the code in the proc in my answer (even if you don't like the idea of console-like output in a GUI block) for saving each frame as a table entry and then recombining (plots:-display) in sequence to obtain an animation.

@Elzas Is there some reason why B(z) is no better than a some linear interpolation?

If you only want float values for F(t) then have you tried evalf(Int(...)) to force only numeric integration, rather than using lowercase evalf(int()) where Maple spends time attempting a symbolic integral for every t value?

You wrote expt and I'm not sure what you meant there.

If MTM:-sort and :-sort both did the very same thing for all kinds of input then there'd be no reason for the existence of both.

You can read the ?MTM help page and see that the commands were designed to support the runtime of the Maple Toolbox for Matlab.

You can force use of that package version, even when the MTM package is not loaded, by calling it like MTM:-sort( V ) .

You can force the use of the global version, even when the MTM package is loaded, by calling it like :-sort( V ) .

So such problems may be resolvable, whether the package is loaded or not.

In your examples it also not clear why you had to load the MTM package.

Start by stating clearing you operating system and version, and you Maple version.

acer

Is your F evalhf'able? I mean, does F work if you call it like evalhf(F( somenumericvalue )) ?

Why not show us your F? Perhaps we could find suggestions to make it faster, even if it's not evalhf'able.

The `plot` command will try to work adaptively, by default. It may figure out that fewer points are required in some subregions of `t`, and more in others. And it may well be computing fewer points than you imagine. You could use getdata to figure out just how many points are in the plot structure.

The plot renderer may also be interpolating to make the curve show smooth. Perhaps you could do something similar, by generating a modest number of values and then calling ArrayInterpolation to extend to 1000 values.

It's difficult to suggest more without knowing details of F or the resulting plot.

acer

@Preben Alsholm One of the important uses of the condition number is in estimating the error in a numerically computed solution to a linear system. For example this lapack doc page illustrates using

ERRBD = EPSMCH / RCOND

for estimating a bound on the error, where EPSMCH is "machine epsilon". I believe that is why the nag doc page you cite focuses on which side RCOND might be inaccurate, and by how much. (People often want to know how many decimal digits are correct, etc.)

Perhaps LinearAlgebra:-ConditionNumber might be modified for the real/complex float case where the norm p=1 or p=infinity, so as to offer both the definition [ ie, explicit formula norm(A)/norm(inverse(A) ] as well as lapack dgecon/zgecon. Caution may well still be required when computing via defn though, as the conditioning of the Matrix is going to affect the accuracy of the  intermediary Matrix inverse result! 

And of course, documentation. All these details could be described and illustrated by example.

@Antonvh Your Question makes it clear that you've already discovered "Tools ->Options ->Precision -> Round screen display", which is also provided by interface(displayprecision=...) .

But your "annoying" example seems to be covered by the suggestion of Patrick T. in that page cited by Markiyan. eg,

interface(displayprecision=5):
interface(typesetting=extended):
Typesetting:-Settings(striptrailing=true):

I used 5 for your X.

Would it be possible to put a vertical axis on (at least) one of those, so that we could see how they match the wavelength values?

acer

@Preben Alsholm I agree. Setting infolevel[LinearAlgebra]:=1 shows that in the float case it uses f06raf (lapack dlange,  which computes the norm of the Matrix), followed by f07adf (lapack dgetrf, which computes the LU decomposition) and then f07agf (lapack dgecon, which estimates the condition number using those intermediary results).

Online ocumentation of the lapack function dgecon says,

An estimate is obtained for norm(inv(A)), and the reciprocal of the
*  condition number is computed as
*     RCOND = 1 / ( norm(A) * norm(inv(A)) )

And online documentation of nag f07adf cites,
   Higham N J (1988) FORTRAN codes for estimating the one-norm of a real or complex matrix, with applications to condition estimation ACM Trans. Math. Software 14 381–396

So it looks as if the discrepancy is that the estimation of norm(inv(A)) by dgecon is not always as accurate as it could be.

Regardless of whether that norm(inv(A)) estimate is useful (perhaps it often is adequate, for some commonplace bounding of error estimates log10, etc?), it might be good if LinearAlgebra:-ConditionNumber provided the functionality to force the choice of method.

That is, in the 1-norm and infinity-norm floating-point case ConditionNumber could offer the choice of the current (presumably faster?) estimate using lapack dgecon or the use of the explicit formula norm(A) * norm(inv(A)) .

@akiel123 You've ignored most if not all of my points and suggestions.

1) Your defined operator F__Msl does not compute F_sla(something) * b__1(somethingelse) , as you claim.

Instead it is computing F_sla * (something) * b__1(somethingelse) .

I wrote as much in my Answer above.

2) In consequence of the above syntax mistake your operator F__Msl does not return a numeric value when it is called with numeric arguments. I suggested in my Answer that you try that yourself. If you did you'd likely discover the above problem.

3) You didn't answer why you are trying to use lowercase minimize and maximize instead of uppercase Minimize and Maximize from the Optimization package you loaded and used earlier. [edit] Of course if you intend Maximize/Minimize then something will need adjustment, to obtain objective values.

4) You haven't explained how you intend on the constraints being used in your line that currently calls minimize and maximize. Did you somehow expect them to affect all three calls? (They don't.)

There doesn't seem to be much point in discussing the sqrt's while there are these other issues.

In your latest worksheet an earlier call to your OptimizeSpring returned a numeric result. I don't know whether you want local or global optima. But even if you choose to use DirectSearch instead of Optimization you've have the same issues as mentioned above in your later computation.

In my opinion the heavy use of operators has just made your whole sheet much more difficult to navigate and work with. It seems that at least some of them are unnecessary and have led to some of the confusion. And the calls to evalf don't help efficiency either (you can get float evaluations for your computations without them, and without them and the operators the optimization could perform better under evalhf. And 2D Math seems to have led to problems too.

I'm sorry but I've spent all the time I can on this.

In your definition of the operator assigned to F__Msl you have

F__s1a*(l__s1(theta__3), l__s1(theta__4))*b__1(theta__1, theta__2, theta__3)

because of a space between F_sla and the opening bracket that follows it. That space gets parsed as an implicit multiplication.

I don't understand what you're trying to do in that computation for `Bestangles`. Which calculations are the constraints supposed to affect? Do you really intend `minimize` rather than `Minimize`? Are your bounds intended to keep thing real?

What about the earlier errors, with `theta` in OptimizeSpring?

Is it really necessary to take (so many) square roots?

Perhaps before attempting to optimize you could ensure that the objective behaves as you intend for simple numeric inputs?

acer

@John Dolese I wrote float[8] not evalf[8], meaning the data type for the Matrices and Arrays.

Yes, you'd have to adjust your approach i  order to use evalhf. Probably a good idea anyway.

Combining into fewer, well interacting procedures does not necessarily bring performance improvements on its own. But it does let you leverage Maple's acceleration techniques to greater effect. E.g. evalhf. 

Tom and I seem to be letting you know the same kind off thing wrt atan  and atan2.

I would set a target for doing 100s if not 1000s of wavelength to colour conversions on the order of a few seconds if not less.

GambiaMan, every time you ask a Question here you add a great many meaningless small tags to your post.

Could you please stop doing that?

acer