cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Need help navigating or using the PTC Community? Contact the community team. X

I want to know the reasons of my Mathcad sheet errors.

ttokoro
20-Turquoise

I want to know the reasons of my Mathcad sheet errors.

Using Mathcad the average value of f(t) and convolution of rectangular waves have wrong results.

I want to know the reasons.

1 ACCEPTED SOLUTION

Accepted Solutions
ttokoro
20-Turquoise
(To:ttokoro)

Thanks many replyings to my help. I understand they are bugs.

View solution in original post

20 REPLIES 20

|  |, if etc - not for symbolic math! Symbolic mathematics (and nature) does not like sharp corners!

Mod-Sim.pngMod-If.png

If the symbolics does not "like" sharp corners it should say so and not return an awfully wrong result.

What we see here is a clear severe bug of Primes symbolics (= MuPad) which is also present in real Mathcad.

The expression should either be not simplified at all or return the correct symbolic result

B1.png

If you are under maintenance  you may consider reporting this bug to PTC but don't expect a fix within a reasonable time.

Luc may be able to show if this bug is present in Mathcad 11, too, which uses Maple for symbolics. Guess MC11 returns the correct result.

 

Concerning  the second error I am not sure what the reason may be. Here the problem is the numerical evaluation (used by any plot) - the symbolics get the correct results:

B2.png

The precision of numerical integration is dependent on the value of TOL. But changing that value in your sheet does not noticeably affect the outcome.

Here the nature of the integrand might be the cause.

The effect is there in Mathcad 15, too (and I guess it will also be shown in Mathcad 11), but the effect is slighty different depending on the algorithm chosen (we can chose among a couple of algortithms for the integration in real Mathcad - in Prime we can't) and also depending on the value of TOL.

Here some statements from the Mathcad manual/user guide (the last manual which deserved that name was delivered with Mathcad 11, but most statements about numerics still apply):

  • Like all numerical methods, Mathcad's integration algorithm can have difficulty with illbehaved
    integrands. If the expression to be integrated has singularities, discontinuities, or large
    and rapid fluctuations, Mathcad's solution may be inaccurate.

  • Mathcad’s numerical integration algorithm makes successive estimates of the value of the
    integral and returns a value when the two most recent estimates differ by less than the value of
    the built-in variable TOL.
LucMeekes
23-Emerald III
(To:ttokoro)

I can only agree with Valery: Be very careful when using the | | operator in combinatioin with symbolics.

Here's Mathcad 11:

LM_20180613_Error.png

But then, it's the 13th today...

 

Success!
Luc

At least Maple got the correct symbolic solution when replacing the absolute value by root of square.

Nevertheless I am surprised that even Maple in MC11 has problems with the absolute value in a way that it returns a completely wrong result. This should never happen in a Math software and I see it as a very severe bug (which will not be fixed, I know). If a software returns no result because its not capable to find a solution, then this may be a sign of quality (or the opposite of it). But returning a wrong result, thats an absolute no-go!

LucMeekes
23-Emerald III
(To:ttokoro)

What happens in Prime/Mathcad 15 (with symbolic evaluation) if you take the symbolic equivalent of the if() statement: the Heaviside step function:

LM_20180613_Error1.png

 

(Of course, as shown, numeric evaluation gives the right answer with any of the three ways to make the function positive)

 

Success!

Luc

Similar results in MC15. Heaviside works with symbolics, too.

The drawback of course is that we have to manually derive the points of zero and basically split the function manually at those points. Similar to the distinct integrals I used in my first answer to get the correct symbolic result.

A bug stays a bug even if there may be a workaround and this IS a bug (even in MC15/Maple).

How about this alternative to the absolute value in MC11?

In MC15 an additional similar bug shows up.

B.png

LucMeekes
23-Emerald III
(To:Werner_E)

Mathcad 11 doesn't know sign(), but signum() instead.

Multiplying y(t) with its signum is as bad as | |.

ttokoro
20-Turquoise
(To:ttokoro)

Thanks many replyings to my help. I understand they are bugs.

ttokoro
20-Turquoise
(To:ttokoro)

Unfortunately, no bug fix with Prime 5.0.

the eternal bug in the german release

 

bug.JPG

prime 3.0 or 3.1: OK

prime3_1.JPG

 

prime 4.0 or 5.0: bad

prime5.JPG

Werner_E
24-Ruby V
(To:skunks)

> prime 4.0 or 5.0: bad

Worauf soll sich das beziehen? Außer der Größe der Grafik scheint doch kein Unterschied zu bestehen?

Jedenfalls keiner, auf den du deutlich hinweisen würdest.

Außerdem scheint es sich ja nicht um einen Prime-Plot zu handeln, sondern um eine simple reinkopierte Grafik. Mit Cut&Paste hatte Prime ja von Anfang an unglaublicherweise größte Probleme und das hat sich bis zur letzten Version nicht gebessert. Vor allem betraf das aber das Kopieren von Prime-Ausdrücken über die Zwischenablage in andere Programme.

 

Mit deinem Post über die eigentümlichen Auswahlmöglichkeiten in der deutschen Version das Datum betreffend hat dein neues Posting aber wohl nichts zu tun (obwohl es eine Antwort auf ebendieses ist), oder?

 

Ich habe die Prime 5 flüchtig überflogen.

 

Das Datum ist in der deutschen Version immer noch an 2 Stellen vertauscht;

ich habe damals (Prime 3) das als Fehler eingereicht, PTC antwortete, dass dieser Fehler lediglich in der deutschen Übersetzung vorhanden ist, somit ist keine Korrektur notwendig (kein Scherz).

 

Das Einfügen eines Bildes aus der Zwischenablage geht ab Prime 4 (also auch in Prime 5) nicht mehr sauber, die Grafik wird nicht automatisch eingepasst. Für meine Statik-Texte eine erheblich Arbeitsbehinderung.

Werner_E
24-Ruby V
(To:skunks)

Die Antwort von PTC glaube ich sofort. Die Firma ist gleichermaßen arrogant wie unfähig.

Cut&Paste war wie gesagt immer schon ein Problem für die Prime-Entwickler (eigentlich unglaublich angesichts der Tatsache, dass es sich um ein sehr elementares Feature handelt). Möglicherweise haben sie beim Versuch, Cut&Paste von Prime weg zu verbessern die umgekehrte Richtung verschlimmbessert.

Auch ich hab heute P5 nur überflogen, aber außer dem nun integrierten 2D-Plot Modul, welches bereits für P4 angekündigt war, gibts ja keine Neuerungen. Und diese Integration ist dermaßen holprig erfolgt, dass man fast auch gleich eine extra Software wie Origin verwenden und deren Ergebnis nach Prime kopieren könnte (wenn das mit dem Kopieren endlich mal ordentlich funktionieren würde).

Kann man beim normalen (sehr eingeschränkten) 2D-Plot in Prime wenigstens ersten, zweiten und Maximalwert jeder Achse durch Variable angeben und somit Schrittweite der Skalen bzw. Anzahl der Intervalle dynamisch steuern, so ist das beim neuen Modul offenbar nur mehr für Anfangs- Endwert möglich. Die Schrittweite oder Anzahl der Unterteilungen ist dynamisch so nicht mehr änderbar, nur mehr fest über dieses eigenartige völlig unintegrierte Menü im eigenen Windowsfenster, welches sich nur allzu oft hinter der Anwendung öffnet und gesucht werden muss. Für Plots, bei denen sich der dargestellte Bereich in Abhängigkeit von Eingabevariablen ändert ist das völlig unzureichend.

Ein Armutszeugnis für PTC, dass die da nichts brauchbareres zusammen bringen!

 

Werner_E
24-Ruby V
(To:skunks)


@skunks wrote:

the eternal bug in the german release

In der englischen Version sieht das so aus

B.png

und man wollte uns offenbar die Verwirrungen mit verdrehtem Tag und Monat ersparen, aber minimalen Aufwand bei der "Eindeutschung" betreiben.

Viel lästiger sind da die Tastaturkürzel, die vielfach nicht so funktionieren wie angeben und es gibt auch Funktionen, für die (auf englischsprachigen Tastaturen) ein shortcut existiert, mit deutschem Keyboardlayout aber partout keines zu finden ist (obwohl natürlich ein nichtfunktionierendes angezeigt wird).

Nutzer in Italien scheinen da noch schlimmer dran zu sein, wie einige Postings hier vermuten lassen.

Angesichts der Tatsache, dass PTC auch nach 10 Jahren "Entwicklung" nicht in der Lage ist, einen auch nur einigermaßen brauchbaren Nachfolger für Mathcad 15 zu entwickeln, verwundert es nicht, dass die Entwicklung der internationalen Versionen des Programms offenbar ganz hinten auf der Prioritätenliste der Entwickler steht.

 

Man war aber auch schon bei Mathcad 15 und davor immer schon gut beraten, das Programm in englischer Sprache zu betreiben (die Verwirrungen um t-> tonne und s als Einheit Sekunden bei der Laplace-Trafo sind legendär). Leider ist das bei Prime mit dem Aufrufparameter "/culture:en-US" viel aufwändiger geworden. Damit das nämlich auch beim Doppelklick auf eine Prime-Datei funktioniert muss man selbst in der Registry herumpfriemeln.

 

Prime 5 ist ja eine große Enttäuschung und so gilt die Empfehlung, entweder das potentere MC15 zu verwenden oder sich besser eine andere Software zu suchen nach wie vor.


@ttokoro wrote:

Unfortunately, no bug fix with Prime 5.0.


Did you really expected a bug fix in P5?

 

BTW, did you report  the bug to PTC and did you got an encouraging reply?

ttokoro
20-Turquoise
(To:Werner_E)

Of course I reported these bugs to PTC and I got the accept letter from PTC. I was an old user of MC11. I started to use Mathcad again from Prime 3.0. Even from the development speed of Prime 4.0 and 5.0 of these years, I still hope the bugs will be fixed.  


@ttokoro wrote:

Of course I reported these bugs to PTC and I got the accept letter from PTC. I was an old user of MC11. I started to use Mathcad again from Prime 3.0. Even from the development speed of Prime 4.0 and 5.0 of these years, I still hope the bugs will be fixed.  


I wouldn't hold my breath!

The problem is with the symbolics (old version of muPad) and PTC does not have much control over it.

The main problem seems to be that a limit is calculated wrong and the symbolics get the wrong sign for the upper limit (see attached).

B.png

Here's the bug even more simplified:

 

B.png

 

Top Tags