@sideshow Why are you still using round brackets to reference entries of A[k] ? Didn't you read or understand my earlier answer?

Why are you STILL trying to represent 2D Input by pasting here as text?

Why aren't you uploading a worksheet with your full code, or pasting here from valid input as text?

Have you tried using a Worksheet with 1D Maple Notation, since you're having trouble with 2D Input?

@gkokovidis 2D Input strikes again.

@terryma

1) Try to compute your (6) with,

int( simplify(f), s ) assuming real;

or,

simplify( int( simplify(f), s ) ) assuming real.

2) I don't understand what you are trying to say about your expression (5). Where did the x go?

@terryma If your followup comment you are wrong, in at least two cases.

The first case is that the exponent 0.5 is not the same as the exponent 1/2. Maple is capable of both floating-point and exact calculations. You're confusing the two.

((1/7)^2)^(0.5) <> 1/7;

                                       1
                       0.1428571429 <> -
                                       7

The above example makes the earlier results I showed from `is` and `simplify` seem suspect and overzealous. That's why I included the exact exponent 1/2 in my original response. Compare also with,

(x^0.5)^2;

                               1.0
                              x   

simplify(%);

                              1. x

which falls down on say,

sqrt(2)^(1.0);

                          1.414213562

1.0*sqrt(2);

                                (1/2)
                           1.0 2     

And what's a good rule without exceptions to exceptions to the rule?

exp(1)^(1.0);

                                  1.0
                          (exp(1))   

A second case now is that in your followup explanation you left out the earlier qualifier that x is positive (or even nonnegative). But I believe you are already aware of this, from before.

((-2.0)^2)^(0.5) <> -2.0;

                      2.000000000 <> -2.0

You should be very cautious about using a float exponent if you don't have to. So that's one thing for you to take away: power 0.5 is different from power 1/2.

Another thing to keep in mind is that it is the command `sqrt` which computes. You can call the `simplify` command on x^(1/2) , but otherwise raising to 1/2 will not do much of anything. Compare these results:

sqrt( x^2 ) assuming x>0;

                               x

( x^2 )^(1/2) assuming x>0;

                               (1/2)
                           / 2\     
                           \x /     

simplify( ( x^2 )^(1/2) ) assuming x>0;

                               x

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