@Markiyan Hirnyk Thanks, I was having a lot of trouble editing my answer, trying to add in the plots.

It is not completely clear (to me) exactly what the Asker wants to obtain, in terms of a visual result.

@Markiyan Hirnyk Thanks, I was having a lot of trouble editing my answer, trying to add in the plots.

It is not completely clear (to me) exactly what the Asker wants to obtain, in terms of a visual result.

For example, calling R() once produced this image. It produces a different result each time it gets called.

acer

For example, calling R() once produced this image. It produces a different result each time it gets called.

acer

@Markiyan Hirnyk Sure, and I'm not disagreeing with your answer, which does the job asked. But the requested task seems a bit flaky, if generalized in some ways.

Suppose that you had something with units m^3 added to something with units cm^2. You could not make that unit-free, it would make no sense. It cannot be made unit-free without knowing which variable is supposed to represent a unit that makes the dimensions compatible. And since the units of length vary in scale then it would not be valid to just eradicate them without rescaling.

If everything has the very same units (eg. m^3*s, or whatever) then you could simply evaluate with Units:-Unit=1.

acer

@Christopher2222 It might be possible to unprotect and overwrite routines in the Typesetting package in order to have typed 2D Math input be displayed (or even parsed?!) differently. But one might want some Button, coded to restore the original, or else doing anything else in the session could be problematic.

@Christopher2222 It might be possible to unprotect and overwrite routines in the Typesetting package in order to have typed 2D Math input be displayed (or even parsed?!) differently. But one might want some Button, coded to restore the original, or else doing anything else in the session could be problematic.

@Christopher2222 That's the earlier post I had in mind, thanks.

@Christopher2222 That's the earlier post I had in mind, thanks.

The warning is just there to let you know that you forgot to declare p1 as a local inside the procedure `myplot`. The original post, which you cited, did not make that omission.

acer

@Christopher2222 I think I see. So you don't want to programmatically insert any new embedded component, which is how I interpreted your question. You want to type into an existing component and have it update (by running some custom code) as you type.

As far as I know the Action When Changed code behind components currently on gets executed when the focus is changed to elsewhere.

And I seem to recall previous related queries which could not be done even by some Thread (Threads package) in the "background" because the GUI did not allow asynchronous updating of that sort. I could be wrong about this.

That's about all I can think of, for mechanisms that might actively watch the value of a Text/Math component and process and replace it in such a dynamic manner.

@Christopher2222 I think I see. So you don't want to programmatically insert any new embedded component, which is how I interpreted your question. You want to type into an existing component and have it update (by running some custom code) as you type.

As far as I know the Action When Changed code behind components currently on gets executed when the focus is changed to elsewhere.

And I seem to recall previous related queries which could not be done even by some Thread (Threads package) in the "background" because the GUI did not allow asynchronous updating of that sort. I could be wrong about this.

That's about all I can think of, for mechanisms that might actively watch the value of a Text/Math component and process and replace it in such a dynamic manner.

@erdem You might consider calling the EigenConditionNumbers command at default working precision (Digits=10 say), with options supplied to make it return both  estimated eigenvalues and condition numbers. Then you might test the estimated condition numbers, to try and gauge whether you need to rerun under higher working precision.

You might call that command and supply the option 'balance=scale', to help keep the condition numbers smaller. (See here.)

Let me know if you need code to estimate bounds on the eigenvalues' errors, as a function of condition numbers and working precision. Or see here and here.

But most importantly, you should follow Carl's advice below and ensure that the eigen-solving is done as a floating-point computation and not as an exact one. You can do that by either forming the Matrices with datatype=float or by wrapping each Matrix in a call to `evalf` before passing to the LinearAlgebra command.

Christopher, you wrote,

    sqrt(a)/a is in fact simplified to 1/sqrt(a)

and there it does seem that you mean unassigned symbolic `a` there. But what is actually happening under that call to the `simplify` command is that symbolic a^(1/2)/a becomes 1/a^(1/2). Just for the sake of clarity.

Another somewhat related inconsistency is the following distinction, which can sometimes be awkward (such as when trying to do matching),

A := 1/x^(p);

                               1 
                               --
                                p
                               x 

dismantle(A);

PROD(3)
   POWER(3)
      NAME(4): x
      NAME(4): p
   INTNEG(2): -1


B := x^(-p);

                              (-p)
                             x    

dismantle(B);

POWER(3)
   NAME(4): x
   SUM(3)
      NAME(4): p
      INTNEG(2): -1

Here, the powers of symbolic `p` involved in A-B do not combine unless we issue a subsequent command to force it. Also, the value of `A` becomes that of `B` under a call to `simplify` or `combine` but not under a call to `normal` or `expand`. And the value of `B` becomes that of `A` under `expand` but not under `normal`, `simplify`, or `combine`. And A/B and B/A do not become 1 under `normal`, but they do under `simplify`, `combine`, and `expand`. I expect that some of this might confuse new users.

acer