Skip to main content
S
sm�ller-21-Visitor
1-Visitor
April 16, 2016
Question

Iterative Calculation 2.0 modified

  • April 16, 2016
  • 50 replies
  • 16698 views

Hey guys,

i modified my iterative calculation and it is better to work with that functions and variables.

Having now the problem, that the calculation for the second row is not correct.

It should be an independend calculation for every loadcase with a different maxiter.

And the second example is not working.

Can anyone see the failure?

THx guys

50 replies

S
sm�ller-21-VisitorAuthor
1-Visitor
April 16, 2016

I think i solved a part of my failure but still dont know why my second example doesnt work.

Hopefully anyone can help me finding the failure.

Is this now correct iteration?

Best thx to all!

-
-MFra-21-Topaz II
21-Topaz II
April 16, 2016

Hello Mr. Stefan, maxiter is a scalar or a vector?

maxiter.jpg

W
Werner_E25-Diamond I
25-Diamond I
April 16, 2016

F.M. wrote:

Hello Mr. Stefan, maxiter is a scalar or a vector?

He is never using the scalar "maxiter" (the worksheet variable) as argument of his function when calling it.

He is always using

which IS a vector

Its a bit strange, and confusing indeed. The global worksheet variable "maxiter" is a scalar, but the formal function argument "maxiter" always is a vector. Again same name for different things. So in this respect all is OK (given we are looking for the error in his sheet), apart from the fact, that its a very bad habit doing things like that.

Werner

S
sm�ller-21-VisitorAuthor
1-Visitor
April 16, 2016

OK thx for input. But how can formulate it better?

Not sure how i should do it 😞

Still have the problem that i dont know how to show the result of the previous iteration step

W
Werner_E25-Diamond I
25-Diamond I
April 16, 2016

OK thx for input. But how can formulate it better?

Not sure how i should do it 😞

Still have the problem that i dont know how to show the result of the previous iteration step

Not sure which post of whom this is an answer to.

I just sketched a way to implement your calculations in a different way here above in the answer where I told you the reason for your Iter1() failing.

I guessed I answered to your question concerning the previous iteration step already here Re: recursivic Calculation

Sure its just a qucik, dirty hack, but it does the job and leaves your routines unchanged otherwise.

Of course you could add to your F.new and F.old a local variable F.veryold to keep track of the previous versions of your variables if you prefer.

S
sm�ller-21-VisitorAuthor
1-Visitor
April 16, 2016

OK thx for the input!!!!

Now i only need to know how to get the output of the previous iterationstep.

Because of the conditions i need to write.

Example:

break if Stress_actual >= Stress_maximum

Now i think i need to know which was the iteration in which the condition is true and how much was the stress of the latest possible iteration.

Thx !!!

Ok so i out in the iter() all variables i need in the following loop code.

But what i still dont get is, im working in that code with scalars?

But how do i handle the Vectors later on because i have more than 10 loadcases?

OK im gonna try it thx

W
Werner_E25-Diamond I
25-Diamond I
April 16, 2016

> Now i only need to know how to get the output of the previous iterationstep.

Do you even read my answers? Was already answered twice.

> But how do i handle the Vectors later on because i have more than 10 loadcases?

Sorry, no idea what you mean by loadcase.

If you mean input values - your function iter() would have more than 10 arguements then.

If you mean the size of your inputs (which at the time is 2) - it would not matter if your vectors are 2 x 1 or 10000 x 1 when you call a function with them vectorized.

WE

S
sm�ller-21-VisitorAuthor
1-Visitor
April 16, 2016

Yes i tryed but i need more than only getting the last force.

How do i get for example the diameter

-
-MFra-21-Topaz II
21-Topaz II
April 16, 2016

Well begun is half done .... To avoid ambiguous definitions for me it is a rule.

S
sm�ller-21-VisitorAuthor
1-Visitor
April 16, 2016

yes im on the way to get a correct iteration

OK i  made the Iteration on your tipps and i hope it is better now. ANd it is what you meant:

But having problems with row 7 of the Result.

Hopefully i did understand what you tryed to explain to me

I think there is a general failure in my code because when i am changing am in the vector of row 7 it has an influence on the following result of row 8

Strange...

I think i need to change the code to get the program work properly

-
-MFra-21-Topaz II
21-Topaz II
April 16, 2016

Keine Notwendigkeit, einen Vektor mit den Elementen alle gleich zu erstellen.  Einfach verwenden   die Konstante maxiter.

sciocchezza.jpg

-
-MFra-21-Topaz II
21-Topaz II
April 16, 2016

Hello Stefan do you like  this solution?

ForSM.jpg

W
Werner_E25-Diamond I
25-Diamond I
April 16, 2016

@ F.M.

Looks to me like the force values in your last table are wrong!

Could it be you haven't created a solution on your own but just used Stefans faulty calculation routines?

Can't tell without the sheet.

E.g. in row number 6 F should be around 1334000 N yielding a bolt diameter of approx 37.3223 mm (slightly smaller than the limit 37.323 mm).

Your table says F=983401 N and you get a bolt diameter of 34,302 mm which is much /too) smaller than the 37,323 mm.

WE

-
-MFra-21-Topaz II
21-Topaz II
April 16, 2016

You are right Werner. The reason is that I used a very great tolerance. If I use a much smaller tolerance, the result is more satisfactory.

ForSM.jpg

S
sm�ller-21-VisitorAuthor
1-Visitor
April 16, 2016

Danke für den INput

Da s ist der Fehler nehme ich an

Den Rest habe ich leider nicht verstanden wie ich mit weniger Aufwand den letzten Iterationsschritt aufrufen kann nach dem break.

Verstehe es nicht 😞

S
sm�ller-21-VisitorAuthor
1-Visitor
April 16, 2016

zumindest schaut es ja jetzt richtig aus oder

Wie meinst du das nach dem break den vorletzten schritt aufrufen und mit der variable merken?

Verstehe das nicht ganz. 

-
-MFra-21-Topaz II
21-Topaz II
April 16, 2016

Although I don't know what is a.m, I would introduce a relative tolerance to be compared with that obtained between the calculated diameter of the bolt and a.m, and stop the iterations when the latter is less than or equal to the given tolerance. As you can see in the program, the operations are all between scalar variables (elements of vectors) with indices.

Es gibt keine wesentlichen Änderungen im Vergleich zu früheren Versionen. Dies ist vielleicht abhängig von der Unkenntnis des Problems, und das Fehlen einer Beschreibung der Daten.

Best regards

F,M.

iter2.jpg

W
Werner_E25-Diamond I
25-Diamond I
April 16, 2016

> Später muss ich die Rechnung noch um andere sachen erweitern, sodas sich dann viele andere Abbruchkriterien für die Kraft habe. (Schraubenverbindung, Bauteilfestigkeit etc.

Ja. daher ist es sinnvoll, die dazu nötigen Berechnungen (wie hier eben den Bolzendurchmesser) in Funktionen auszulagern, um das eigentliche Iterationsprogramm möglichst übersichtlich zu halten.

Ich denke ja noch immer, dass die Aufgabe(n) trotz unterschiedlichster Abbruchkriterien doch mit einem Lösungsblock realisierbar sein könnte. Für den Bolzendurchmesser allein hab ich das ja in dem anderen Thread gezeigt, wie es gehen könnte.

> Die sachen lassen sich nciht direkt lösen und müssen itertaiv bestimmt werden.

Naja, zumindest für Kraft/Bolzendm. stimmt das nicht. Auch da hatte ich ja schon eine direkte Formel zur Berechnung angegeben. Allerdings wird es bei zusätzlichen anderen Kriterien wohl so sein, dass man tatsächlich keine direkte Berechnungsformel angeben kann.

Aber vielleicht können wir ja zumindest die Angelegenheit hier doch noch zufriedenstellend abschließen.

Im Anhang meine Lösungsvariante, welche hoffentlich auch demonstriert, was ich mit meinen bisherigen Anmerkungen meinte.

Zunächst ist die Dmberechnung und auch die OK/NOK "Berechnung" ausgelagert, da ich sie in meiner Routine mehr als einmal benutze. Danach folgt die von mir immer wieder "eingeforderte" Berechnungsroutine, die nur und ausschließlich auf skalaren Größen operiert. Diese wird vorzugsweise oberhalb der Definition der Eingabevariablen geschrieben, damit man nicht irrtümlich etwas benutzt, das nicht als Parameter übergeben wird. Diese Routine, die also nur einen Satz Daten berücksichtigt, habe ich "Iter_single" genannt:

Du siehst, dass ich hier nicht mit F.alt und F.neu herumeiere, ein F reicht völlig. Nur, um nach den Abbruch noch den vorherigen Wert zur Verfügung zu haben, speichere ich jeweils den letzten Wert von F, bei dem der Vergleich noch OK war, in einer Variablen F.OK. Und nur diese und der zu diesem Wert gehörige Durchmesser und OK-Wert werden dann zurückgegeben. Deshalb müssen diese nach der for-Schleife neuerlich berechnet werden. Man könnte alternativ so wie das F.OK auch ein d.OK und vl ein OK.OK mitführen und sich damit diese Neuberechnung ersparen

Probleme kann es hier geben, wenn bereits der Initialwert zu einem zu großen Durchmesser führt (als F,OK wird dann 0 angenommen). Das sollte man der Ordnung halber vl noch abfangen. Ich wähle aber bei den folgenden Aufrufen ohnehin immer 0 N als Initial-Wert, da passiert das offenbar nicht.

Jetzt gibt es mehrere Möglichkeiten, diese Routine zu verwenden. Entweder tatsächlich nur mit einem Datensatz

oder aber mit Vektoren als aktuelle Parameter, dann aber muss der Aufruf vektorisiert werden

Hier sieht man jetzt schon die Problematik - das Ergebnis ist eine verschachtelte Matrix. Wir erhalten einen Vektor dessen Einträge jeweils 1 x 5 Matrizen sind. Das ist für weitere Berechnungen und Ausgaben recht unhandlich, weswegen ich noch eine eigene Routine "Iter" nachgeschaltet habe. Diese ruft "Iter_single" in jedem Fall vektorisiert auf, prüft danach, ob das Ergbenis eine verschachtelte Matrix ist und schreibt diese dann gegebenenfalls in eine normale Matrix um.

Ich hab der Rückgabematrix auch noch einen Zeile mit Spaltenköpfen spendiert.

Die Routine "Iter" kann jetzt also sowohl mit skalaren Werten, als auch mit (gleich großen) Vektoren aufgerufen werden. Wenn ein Eingabevektor nur aus lauter gleichen Einträgen bestehen würde, kannst du stattdessen auch einfach nur den skalaren Wert hinschreiben, so wie ich das mit F.init und maxiter gemacht habe:

Mit deinen Werten ergibt sich dann folgende Tabelle:

Das wärs eigentlich auch schon. Schmerzlos und im Grunde recht kurze Routinen.

Ich hab auch noch als Alternative eine weiter Funktion "Iter_neu" geschrieben. Diese orientiert sich an deinem ursprünglichen Ansatz indem sie die Vektoreingabewerte mit einer Schleife (ich hab den Schleiferzähler s als Name übernommen) einzeln abklappert, damit die Funktion Iter_single aufruft und die Ergebnisse gleich in einer Matrix (auch mit Spaltenköpfen) aufsammelt. "Iter_neu" hat eigentlich keine Vorteile gegenüber "Iter". Im Gegenteil, denn "Iter_neu" kann nicht mit lauter skalaren Werten aufgerufen werden, sondern es müssen hier F.init und maxiter Skalare sein und die anderen Parameter müssen (gleichgroße) Vektoren sein. Also ist "Iter_neu" eher eingeschränkt und weniger flexibel.

Hoffe, dass wir damit diesen Thread erledigen können.

LG

Werner

W
Werner_E25-Diamond I
25-Diamond I
April 16, 2016

Eine Ergänzung noch dazu, nämlich eine weitere Möglichkeit, nach dem Abbruch der for-Schleife zu einem gültigen F-Wert zu kommen und diesen auch noch genauer als auf 100N genau zu bekommen.

Nachdem die for-Schleife abgebrochen wurde, geht es in eine neue Schleife, die solange F um 1N verringert, bis der Vergleich von d und a ein "OK" ergibt. Auf diese Weise hast du nun die Kraft F auf 1 N genau. Das ist jetzt sozusagen die verfeinerte Version meines allerersten Vorschlags zur Rückgabe des letzten gültigen F-Werts, den ich bereits in dem anderen Thread gemacht hatte. Dort hatte ich gemeint, dass du mit F doch nur einen Schritt, also 100 N, zurückgehen musst.

Ich habe mir hier nicht die Mühe gemacht, den Iterationszähler "i" in dieser zweiten Schleife weiter hinauf (oder runter?) zu zählen, weil ich ohnedies nicht verstehe, warum du diesen Zähler überhaupt ausgibst. Wenn du mit 0N als Startwert beginnst, immer um 100N erhöhst und es stellt sich dann F=983400 N ein, dann ist doch ohnedies klar, dass F eben 9834-Mal erhöht wurde und nach deiner Zählweise sind das dann 9835 Iterationsschritte.

Hier die neue "Iter_single2":

Die neue "Iter2" ist gegenüber "Iter" unverändert, nur ruft sie eben "Iter_single2" auf.

Hier zum Vergleich die Ergebnisse von "Iter" und die genaueren von "Iter2" (noch genauer machts ein Lösungsblock 😉

Der Unterschied zwischen a.m und d.m ist nun schon so klein, dass er kleiner als ein Mikrometer ist und daher in der Tabelle nicht mehr zu erkennen ist.

WE

S
sm�ller-21-VisitorAuthor
1-Visitor
April 17, 2016

hey vielen Dank,

schaut echt supper aus!

Genau so brauche ich es =).

Das mit der Tabelle und den Namen oben is auch toll.

Jetzt werd ich mir den Code genauer anschauen. Wusste nicht wie ich es schreiben soll das er runterzählt und der while Schleife.

S
sm�ller-21-VisitorAuthor
1-Visitor
April 17, 2016

Echt toll.

Habe jetzt wieder einiges dazugelernt.

Du hast ja alles ausgegliedert, sogar die Bedingung OKNOK. Wusste nicht das das geht. Ich dachte das alles in dem Code stecken muss.

Gliedert man alles aus wird es echt übersichtlich und schön. Nicht so wie mein Monstercode.

Außerdem kann man ja alles ausgegliederte extra auf Richtigkeit überprüfen.

MIt variablen arbeiten ist echt besser, bei so extrem langen und komplizierten Rechnungen.

Werde das jetzt immer so machen.

Übrigens bei den Loadcases haben wir das auch so gemacht. Beispiel:

OKNOK(D,B):= / "OK" if D<=B  "NOK" otherwise    (variable)

OKNOK:= OKNOK(D,B) (vektorisiert) (D,B entsprechend den realen Vektoren)

echt fein so zu arbeiten

------------------------------------------------------------------------------------------------------------------------

Werde die Berechnung des Durchmessers noch in einem Lösungsblock auslagern, sodass man auch versteht wie es zur Formel kommt

Noch eine Frage zum Lösungsblock.

Wenn ich in einem Block eine Variable definiere zum Beispiel W0=a+b

dann muss ich, wenn ich diese in einem anderen Lösungsblock verwenden möchte wieder gleich definieren oder ?

Oder kann man generell für das ganze Worksheet W0(A,B)=a+b definieren?

Ist es korrekt, wenn ich oberhalb der ganzen Lösungsblöcke W0(a,b) definiere? Berechnet er dann alles richtig?

Bin mir unsicher.

Beispiel:

LösungsblockA(W0....)=

LösungsblockB(W0...)=....

------------------------------------------------------------------

Die Bedingung ist hoffentlich korrekt geschrieben oder?

OKNOK(D,B):= / "OK" if D<=B  "NOK" otherwise    (variable)

OKNOK:= OKNOK(D,B) (vektorisiert) (D,B entsprechend den realen Vektoren)


Nimmt Mathcad hier jede einzelne Zeile extra her und berechnet die Bedingung?


Habe massenweise Bedingungen wo ich dann entsprechende Werte zuweise je nachdem wo welcher Wert liegt.

a(D,B):= / 1 if D<=B  0 otherwise    (variable) (D und B können auch recht komplexe formeln sein)

a:= OKNOK(D,B) (vektorisiert) (D,B entsprechend den realen Vektoren)


Ist diese Schreibweise korrekt?


-----------------------------------------------------------------------------------


Vielen Dank Werner hast mir echt sehr geholfen!




W
Werner_E25-Diamond I
25-Diamond I
April 17, 2016

Du hast ja alles ausgegliedert, sogar die Bedingung OKNOK. Wusste nicht das das geht. Ich dachte das alles in dem Code stecken muss.

Gliedert man alles aus wird es echt übersichtlich und schön. Nicht so wie mein Monstercode.

Außerdem kann man ja alles ausgegliederte extra auf Richtigkeit überprüfen.

Ja, ohne Modularisierung hängt man sich auf, wenns komplexer wird.

Der Nachteil sind natürlich die Funktionen mit der elend langen Parameterliste, aber im Vergleich zum Monstercode ein geringer Preis. Und der Vorteil ist natürlich die Übersichtlichkeit, zT auch die Kürze (obwohl das kein Kriterium sein sollte) und eben der Komfort, eben mal schnell auch eine komplexe Berechnung mit anderen Eingabeparametern durchkalkulieren zu können ohne irgendwo ganz oben Eingabewerte ändern zu müssen. Auch das gleichzeitige Gegenüberstellen der Ergebnisse unterschiedlicher Eingabeparameter wird dadurch möglich und erleichtert (geht sonst auch - wie bei dir eben mit Eingabevektoren).

Was das Auslagern in externe Unterprogramme anlangt.

Auch kleine Unterprogramme/Funktionen können einem oft das Leben erleichtern oder den Code lesbarer machen.

OKNOK(D,B):= / "OK" if D<=B  "NOK" otherwise    (variable)

OKNOK:= OKNOK(D,B) (vektorisiert) (D,B entsprechend den realen Vektoren)

echt fein so zu arbeiten

Ja, aber weniger fein, dass du schon wieder einer Variablen den gleichen Namen gibst wie einer Funktion (und damit diese überschreibst). Das ist wirklich schlechter Stil und die Funktion kannst du ab jetzt ja auch nicht mehr verwenden.

Werde die Berechnung des Durchmessers noch in einem Lösungsblock auslagern, sodass man auch versteht wie es zur Formel kommt

Ob das dann überschtlicher wird? Jedenfalls handelst du dir damit u.U. numerische Ungenauigkeiten und längere Rechenzeiten ein. Beides spielt bei deinem Blatt, soweit ich das jetzt überblicken kann, aber keine Rolle.

Wenn du mit "wie es zur Formel kommt" deine ursprüngliche schrittweise Berechnung meinst - das kannst du in der Funktion ja genau so machen:

Noch eine Frage zum Lösungsblock.

Wenn ich in einem Block eine Variable definiere zum Beispiel W0=a+b

dann muss ich, wenn ich diese in einem anderen Lösungsblock verwenden möchte wieder gleich definieren oder ?

Oder kann man generell für das ganze Worksheet W0(A,B)=a+b definieren?

Ist es korrekt, wenn ich oberhalb der ganzen Lösungsblöcke W0(a,b) definiere? Berechnet er dann alles richtig?

Du musst doch zwischen einer Variablen W, die du mit W:=a+b definierst und einer Funktion W(a,b):=a+b unterscheiden? Ich verstehe deine Frage nicht ganz. Eine Variable wird doch in einem Lösungsblock nur dann definiert, um einen Schätzwert anzugeben und das sollte man (muss man aber nicht) oberhalb von "Give" machen.

Und wie jede andere Variable auch behält sie ihren Wert solange, bis eine neuer zugewiesen wird.

Den Rest deiner Lösungsblockfrage verstehe ich dann leider überhaupt nicht. Solltest du vl besser nochmals und mit ein paar erklärenden einfachen Screenshots neu stellen.

Werner

S
sm�ller-21-VisitorAuthor
1-Visitor
April 17, 2016

Aeh wo ist die s Schleife?

Wie geht den das und trotzdem behandelt er jede Zeile der ganzen Vektoren extra ? Bin etwas verwirrt?! Oder Magie 😃

S
sm�ller-21-VisitorAuthor
1-Visitor
April 17, 2016

Was Genauigkeit betrifft 1N reicht mir

Die Kommastellen schluckt ohnehinn Microsoft Excel 🙂

---------------------------------------------------

Kannst du einen Umstieg auf Mathcad Prime empfehlen ?

Erwäge gerade diesen Vorschlag einzubringen. Jedoch wenn der Funktionsumfang ähnlich ist, zahlt es sich ja nicht aus.

Hatte schon gehört das viele Funktionen gestrichen wurden.

Mir geht es speziell um eine bessere Word Excel Kopplung.

(nicht immer das excel file schließen müssen, wenn ich neue werte berechnen möchte. (Readexcel, Writeexcel)

Diese ist in Mathcad 15 ja sehr sehr schlecht.

Oder die Möglichkeit ein besseres Inhaltsverzeichnis zu erstellen (ohne diese lästigen HyperlinksI wie in Microsoft Word.)

Die Diagrammfunktion im 15er ist ja auch sehr rudimentär.

-------------------------------------------------------------

W
Werner_E25-Diamond I
25-Diamond I
April 17, 2016
Was Genauigkeit betrifft 1N reicht mir

Kann ich mir gut vorstellen, wenn ich mir die Unterschiede der Bolzendurchmesser, die nur mehr im Zehntel Mikrometer Bereich liegen, ansehe, Vermutlich wäre die Schrittweite 100 N durchaus auch ausreichend. Du hats ja jetzt die Wahl.

Wenn ich Excel höre, verkrampft sich was in mir. Excel und Ingenieurwesen, das passt so gar nicht zusammen. Auch wenn ich natürlich weiß, wie oft im Ingenieurswesen Excel-Sheets verwendet werden. Excel ist ja quasi überall verfügbar und sooo einfach zu bedienen (wirklich?). Oftmals wird die Verwendung firmeninterner Exelsheets vorgeschrieben und oftmals sind sie so alt und komplex, dass niemand mehr da ist, der genau weiß, was da passiert und gegebenenfalls einen Fehler finden und ausbessern könnte. Excel-Sheets in der Technik sind eine wahre Pest. Fast schon so wie Fortran-Programm, die auch fast nicht auszurotten sind.

Es gibt wirklich keinen vernünftigen Grund Excel zu verwenden, wenn man Programme wie Mathcad zur Verfügung hat.

Kannst du einen Umstieg auf Mathcad Prime empfehlen ?

NEIIIIIIIIIIN!!!!!!!!!!!!!!!!!!!!!!!!!!! Prime ist ein Sch...

Das Progamm ist elend langsam, das Handling ist nicht nur gewöhnungsbedürftig wegen des (nicht M$ konformen) Ribbon Interface, sondern es sind die meisten Operationen einfach umständlicher und erfordern mehr Tastendrucke oder Mausklicks.

Außerdem ist der Funktionsumfang von Prime wesentlich geringer - vieles von dem, was in Mathcad15 selbstverständlich ist, ist in Prime (noch immer) nicht implementiert.

Zur Excel-Ankopplung kann ich nicht viel sagen, denn die Daten kommen vielleicht einmal von Excel nach Mathcad, aber das wars dann auch schon.

Außer READ- und WRITEEXCEL gibts in Mathvad 15 ja auch noch die Excel-Komponente, die man einfügen kann.

Viel mehr gibts meines Wissens auch in Prime nicht, wenngleich die Excel-Komponente sicher modernen ist. Möglicherweise macht die in Mathacd15 Probleme mit moderneren Excel Versionen - ich weiß es aber nicht wirklich.

Du kannst es ja ausprobieren. Wenn du Prime Express runterlädts, hast du für 30 Tage eine Vollversion und danach werden eine Reihe von Funktionen gesperrt. Außerdem, wenn du eine Mathcad15 Lizenz hast, hast du vermutlich ohnedies automatisch auich eine Prime Lizenz, denn MC15 kann man ja ohnedies nicht mehr kaufen. Man kauft Prime und PTC gibt Mathcad15 dazu. Eine Version zum Spielen und sich drüber ärgern und eine zum seriösen Arbeiten. PTC ist sich dessen offenbar bewusst.

Die Möglichkeit, ein automatisches Inhaltsverzeichnis zu erstellen, gibt es auch in Prime nicht. In Mathcad 15 und davor gab es einige diesbezügliche Ansätze, die von Anwendern hier gepostet wurden. Aber alle basierten auf Skripts in eingefügten Komponenten - aber das gibts in Prime ja auch nicht, also kann man sich sowas dort auch nicht selber basteln.

Die Qualität der Diagramme in Mathcad 15 reichen meist für Dokuementationszwecke, doch für Präsentationen sind sie oft unzureichend. Hier musste man leider dann u.U. doch wieder auf Excel zurückgreifen, um seine Daten schöner aufzubereiten oder gleich ein spezielles Programm wie zB Origin benutzen.

Doch in Prime ist das alles VIEL schlimmer. Gerade der Plot-Bereich dort ist eine Frechheit und bietet noch viel weniger Möglichkeiten als in älteren Mathcad-Versionen. Von der umständlicheren Bedienung mal ganz abgesehen.

Aber wie gesagt - probier es selbst mal aus - du wirst Mathcad 15 noch mehr schätzen lernen 😉

Es gibt schon ein paar wenige Bereiche, in denen Prime gegenüber Mathcad punkten kann. Es kann mehr Hauptspeicher nutzen und auch einen zweiten Prozessorkern (war für mich noch kein Thema und die Berichte dazu sind nicht immer voll des Lobs). Auch was die Eingabe von Matrizen anlangt, ist das in Prime bequemer. Was die Ausgabe und Anzeige großer Matrizen betrifft, stimmt das dann schon wieder nicht mehr.

Gerüchtehalber soll PTC bei der nächsten Version 4 von Prime deutlich an der Performance-Schraube gedreht haben und die meisten Operationen sollen nun deutlich schneller und flüssiger ablaufen. Auch die Verbesserung im Plot-Bereich soll ein Schwerpunkt bei dieser kommenden Version sein - angeblich hat man dafür ein Programm eines Drittanbieters implementiert. Warum der Hersteller eines High-End-CAD wie Creo das nicht selber schafft, ist ein wenig seltsam.

Nun, vieles wird noch immer auf der Wunschliste verbleiben und es wird wohl noch ein paar Versionen dauern, bis Prime in der Funktionalität an das mittlerweile ja schon fast 10 Jahre alte Mathcad14/15 aufschließen kann. Eigentlich eine Witznummer.

Also, installiere Prime und probiere es ruhig aus. Vielleicht ist ja wirklich gerade die dir wichtige Excel-Anbindung besser.

Werner

S
sm�ller-21-VisitorAuthor
1-Visitor
April 17, 2016

"

We rely hero on that the very first initial value of F is an OK-value.

Otherwise the returned F will be zero.

"

Wenn das nicht so wäre hätte ich ein sehr großes Problem hahahahah

W
Werner_E25-Diamond I
25-Diamond I
April 17, 2016

Ja, das war mir schon klar, dass es kaum sein kann, dass der Bolzendurchmesser auch bei einer Kraft von 0 Newton schon zu groß sein müsste.

Trotzdem sollte jede Funktion, die man schreibt, alle theoretisch möglichen Fälle abdecken, auch wenn der Problemfall so wie in deiner Anwendung praktisch nie eintreten kann.

Show more replies
Terms & ConditionsAccessibility statement