MATLAB vs FinSimMath II - revenge of the Fanboys

Four roots out of 5130. This makes it irrelevant.

You missed the point, being within \(\epsilon\) of the Finsim roots doesn't mean that the resulting error in the polynomial evaluation is negligible.

 

Log in or Sign up to hide all adverts.

Nonsense, the error is in the poly(Matlab), you keep (conveniently) forgetting that it goes of the rails starting with the attempt at computing the fourth polynomial coefficient bombing with a 1.74 instead of the correct 1.5.

Simple experiment: scramble the Finsim roots and insert them into your bc evaluator.

The point is that Finsim Math can do everything that Matlab does and better.

You do not know that. When Fintronic fixes their printing routine I will re-run the algorithm. We will see then. Until then, you are making an assertion with no basis.

I asked you and I am asking you again to prove it: feed the two sets of roots, in any order to your bc program.

False. A classical counter-example is verifying the quality of matrix inversion by calculating \(AA^{-1}-I\).

Another assertion without proof. You are going to say "but I do not have Matlab".

Like I said: prove it. Feed the roots in any order to your bc program, I will do the same to poly(Finsim). Then we compare notes.

Prove it (see above).

I will.

You do NOT need Matlab for this, you simply need to compute the sum of the squares of the differences.

I see, you were talking about Finsim Math finding the roots only for polynomials with real coefficients. So? The exercise is to compare against Matlab handling of like polynomials (with real coefficients).

This is more useful, this seems to be what I was asking for, I will have a look at it and I will get back to you.

 

Log in or Sign up to hide all adverts.

You are still claiming this after you have used your preferred hammer to pound the screw flat into a new crater in the drywall? Right tool for the right job, mate.

It seems unreasonable to do this with the MatLab roots since I specifically said I had to order them in the same way as the FinSimMath roots to get the above reconstruction.

Since there are 2566! ≈ 7 × 10^7635 essentially distinct ways of reordering the roots (since the BC code I wrote ignores half of the complex ones), your results may vary. I think particularly bad choices are to try to sort by magnitude or by real coefficient. Below I do two runs with one particular order with the original 35-digit FinSimMath roots now reordered.

Using extra precision (bc command: scale=50) helps, but not enough. The randomly sorted coefficients cause instability and even greater instability without the extra precision.

Code:

reconstructing 5131 coefficients from FinSimMath roots
infinity Norm
19150.27064457801988508657736397549742730882555867322593
1-Norm
4172.56078680422916839466338816414477282551213168155721
2-Norm
6121.87865827437245162218737459994384114860011346054826
num Exact
1
num better than 0.5e-9
87
num better than 0.5e-7
102

Without scale=50 (note the average error is now so much larger than 1, that division returns a non-zero result which would not be the case otherwise [see the bc manual page])

Code:

reconstructing 5131 coefficients from FinSimMath roots
infinity Norm
1213203389.502295455179988842150255477572752848864229787
1-Norm
357506265
2-Norm
477349334
num Exact
1
num better than 0.5e-9
60
num better than 0.5e-7
71

Of course with infinite precision with multiplication and addition we would be back where we started but no one has the time for that which is why IEEE floating point was invented in the first place. I talked to the/an inventor a few years back.

 

Log in or Sign up to hide all adverts.

You quoted me out of context. One root is certainly enough to support the statement highlighted in red above, particularly since for the worst match between Matlab and Finsim roots that you found, it was actually the Finsim root that turned out to be significantly less accurate. You weren't just unjustified when you said this:

You were wrong.

Of course, that was two pages of thread and four days ago, and if you had quietly acknowledged this I'd have forgotten about it by now. It's only because you keep crying "irrelevant" and trying to deflect and change the subject that it comes up again and again.

I, again, never said anything about the polynomial evaluation, which is a distinct issue from the precision of the roots themselves. So it rather seems like you missed my point.

 

I already pointed out that you were doing the matching wrong since you handpicked a pair of roots. You can't draw any conclusion with your approach because :

-the roots are not ordered
-you compared only a pair, instead of comparing all of them
-you miss the fact that if a Matlab root is a little better than a Finsim root, this may be easily countered by another Matlab root being much worse than a Finsim root (this is why you need to compare all of them).

I explained to rpenner how to do this comparison properly (by calculating the distance between the calculated and the given coefficients, for all the coefficients (or by calculating the distance from zero for the polynomial evaluations for all the roots). This is how it's done, what you have done is not only irrelevant but also incorrect. You can stop mouthing now.

It is clear that you don't know what you are doing , luckily rpenner does.

 

Technically, Tach, you picked this pair of approximate roots as being the most distant pair after each approximate root was paired with its closest analogue.

He can draw conclusions about the closeness of each approximation to the actual root that they both represent. In fact you drew that same conclusion when you claims FinSimMath root was "better" produced than MatLab root 1198. In this, prysk is fully justified and unrebutted in claiming for that one root you were wrong. You appear to have universally assumed the superiority of FinSimMath and used that to justify your claim that any discrepancy root to root was solely a result of errors in the MatLab roots which is circular reasoning. A scientist seeks evidence to contradict one's own hypothesis, not to confirm it.

This is specious. No roots are ever ordered but by the workings of engineers. The complex roots of a polynomial are a set, without intrinsic order.

This is specious. He is comparing the approximate roots you claimed were the single corresponding pair furthest apart to the actual root of the polynomial and discovered that you unfairly placed the blame in this case on MatLab when FinSimMath was more in error. The fairness of your evaluation is part of the discussion.

Except it was roughly 1000 times closer to the actual root and this was the pair that was by your measure the furthest apart. So now, instead of justifying your unfair comparison you are inventing a conspiracy of unevidenced MatLab roots that have their errors add up to be more than the error of the FinSimMath root you selected. So this is not so much a reason why he can't draw a conclusion but the prosecution claiming there might be evidence to convict MatLab on if the prosecution could have been bothered to look for it.

Time to start unwinding your position and in fairness apologize to the OP for claiming the FinSimMath is always better than MatLab.

 

It took me quite a lot of time to convince you to do the comparison in a proper manner by considering all the roots, now you are regressing.

Not "universal". I listed the examples at the beginning of this thread, remember? Ironically, it was you who kept asserting Matlab's "superiority".

False. I asserted that the error in the calculation of the polynomial coefficients is the result of incorrect root calculations. You need to check your facts before you make such false statements.

Specious. The ordering of roots is simply for comparison purposes. You know better.

Comparing a pair of roots is irrelevant, as explained. Comparing all the roots, as I taught you to do (with a lot of convincing) is the relevant way of doing it. How quickly you "forget".

So, teaching you to calculate the sum of squares of differences for all the roots seems to have been wasted.

This is an outright lie, I pointed out the precise Finsim advantages over Matlab.

 

I never picked anything at all. Those roots were originally identified by you in posts [POST=3110902]#125[/POST] and [POST=3111497]#134[/POST], remember?

When finding the best Finsim match for a given Matlab root, it is not necessary to order all of them. I've already explained that to you. You are really grasping at straws with this one.

You casually forget that when you talked about the "better roots" found by Finsim in posts [POST=3110902]#125[/POST] and [POST=3111497]#134[/POST], as well as in posts like [POST=3107829]this[/POST] one:

(emphasis already present), you had checked precisely zero of those roots. You asserted over and over again, with no evidence, that the Finsim roots were more accurate than the Matlab ones.

I didn't "miss" anything because I simply never said anything at all about all the roots we haven't checked. I don't know how accurate they are, and until someone gets around to checking them, neither do you. That was the point rpenner made in [POST=3111345]post #128[/POST] and that I myself made as far back as posts [POST=3106894]#65[/POST] and [POST=3106873]#59[/POST].

I may or may not get around to checking all the roots in more detail (you seem to forget in all of this that we're talking about the roots of a degree 5000 polynomial that literally nobody in the world cares about). If I do, and assuming rpenner doesn't beat me to it, it will be when I don't have something more important (e.g. actual work, cleaning my nails, eating glue) to be getting on with.

I've explained quite clearly what I am doing, as well as what I am not doing. It's you who, in response to a comment I made about the accuracy of a few roots, suddenly and with no explanation whatsoever changed the subject to polynomial evaluation. Nothing you said about polynomial evaluation invalidates what I said about root accuracy in posts [POST=3112559]#165[/POST] and [POST=3112702]#170[/POST].

 

Not at all. At that time, you were still unable to recover the polynomial coefficients. As a matter of fact, you have never been able to recover the polynomial coefficients.

Err, your first attempt at finding the roots failed. Miserably. How quickly you "forget".
All your subsequent attempts at verifying the validity of the Matlab roots by reconstructing the polynomial coefficients from the roots also failed.

Actually rpenner (after a lot of prodding) went ahead and verified all the roots, the proper way. In your haste, you missed that.

You can continue eating your nails while sniffing glue, rpenner beat you to it.

Err, do you have any idea how the validity of the roots is verified? have you forgotten the fiasco of the first set of "roots" that you reported? hadn't rpenner bailed you out, you wouldn't have known that the roots were off.

 

Wow. You really are slow.

In [POST=3106325]post #27[/POST] you started with:

By [POST=3106530]post #31[/POST], this had evolved to:

Now, what roots? Because if you actually look at my earlier [POST=3105685]post #20[/POST], you'll find that I didn't post any roots.

Maybe you missed my [POST=3108055]post #86[/POST], where I explained how I went back and rechecked what I'd actually reported for this supposedly "failed" first set of roots. In short: there was no failure. The first set of roots was exactly the same as the second set. The extra use of double() suggested by rpenner that I used in [POST=3106600]post #36[/POST]? It was totally redundant. Matlab was already working in double precision. If I'd posted the roots I had along with post #20, the list would have been identical to the one I eventually produced in post #36.

You spent half the thread mouthing off about how I'd "failed epically" etc. when there was never any failure in the first place. You actually made the whole thing up, and it's just that nobody cared to check what had really happened until I did it four days later. The whole "fiasco" never existed outside your head.

The whole time, the only mistake rpenner or I made was listening to you.

 

You sure failed epically, the reconstruction of the polynomial coefficients was, and still is, a failure. poly(Matlab) bombs, right?
Not to mention your inability and unwillingness to address the Matlab failure in inverting Pascal matrices larger than 21x21.

 

So. You're caught having spent several days throwing around insults and charges of "epic failures" that were shown to be totally baseless, and this is how you respond? More deflection?

That really says all anyone needs to know about you right there. You were wrong and blowing hot air the whole time, Tach, and it's on record for everyone to see. Deal with it.

 

Pot. Kettle.

How is poly(Matlab) bombing a deflection? How is Matlab not being able to handle inversion of Pascal matrices larger than 21x21 a deflection?

 

Hardly, since you were absolutely, unambiguously, and definitively wrong. Not Matlab. Not Finsim. You. You made the whole thing up.

Simple. You are shown that you made a series of completely unjustified and wrong accusations, and now you're trying to change the subject. That is classic deflection.

 

"Accusations"? I simply pointed out that poly(Matlab) bombs and so does the inversion of Pascal sparse matrices larger than 21x21.
There is nothing I can do for you if you get buthurt and take this FACTS personally. <shrug>

The OP is about sw packages, the comparison between the strengths and weaknesses of such packages is the subject of the thread. Taking it personally is your problem.

 

This diversion has been moved from the original thread, and closed. Tach is banned for anti-discussion.