Sketcher Fehler: "Bestimmt" obwohl überbestimmt

[HartmutG]

Zur Begriffsklärung:
Redundante Constraints sind solche, die sich aus anderen herleiten lassen, aber trotzdem explizit vergeben werden. Bsp: zweimal dieselbe Länge für eine Linie, in einem Dreieck mit bereits drei gleichen Seiten ein Winkel von 60°.
Überbestimmte Constraints sind solche, die den bisher vergebenen widersprechen. Bsp: zwei unterschiedliche Längen für dieselbe Linie, in einem Dreieck mit bereits drei gleichen Seiten ein Winkel von 70°.

okay, danke für die Definitionsklarstellung, werde versuchen das nächste mal die von Anfang an präziser zu verwenden um ggf. Verwirrung/Missverständnisse zu vermeiden. Wenn diese nun schonmal so klar auf dem Tisch sind, hätte ich da dann zum Verständnis gleich mal zwei Fragen:

1.) hat irgendjemand jemals "überbestimmte Constraints" (s.o.) in den Sketcher reinbekommen? Ich glaube, dass der Sketcher die bei mir zumindest noch nie angenommen und gut im Griff hat. Ist das richtig oder falsch?
2.) "redundante constraints" nimmt der Sketcher offenbar gerne an. Nun könnte man ja meinen: Hey ist doch cool, warum sollten mich die stören, wenn ich einem Teilkreis mehrfach 'n Radius geben kann. So wie ich das nach meinem bisherigen Verständnis sehe, fließen alle Constraints, wenn der Sketcher diese nicht anmeckert, in das in Folge zu bestimmende Gleichungssystem. Ist das richtig oder falsch?
Wenn dem so wäre, ist das dem Iterationsverfahren übergebene Gleichungssystem überbestimmt, nun könnte man auch an dieser Stelle noch sagen: macht nix, denn es wäre lediglich "redundant". Nach meinem Verständnis ist das aber nicht egal, denn es wäre vielleicht mathematisch(<=symbolisch) redundant, aber ganz bestimmt nicht egal, wenn man ein Iterationsverfahren mit begrenzter/fester Fließkommaarithmetik drüber laufen läßt, denn ich vermute mal, FC wird wohl keine eigene Arithmetik mit beliebig variabler Genauigkeit mitbringen. Ist das richtig oder falsch? (Für mich wäre es zumindest auch die technische Erklärung, warum "Nuten explodieren", siehe anderer Thread).
Danke&Gruß, HG

[chrisb]

1.) hat irgendjemand jemals "überbestimmte Constraints" (s.o.) in den Sketcher reinbekommen? Ich glaube, dass der Sketcher die bei mir zumindest noch nie angenommen und gut im Griff hat. Ist das richtig oder falsch?

Es ist wohl richtig, dass der Sketcher sie bei Dir noch nie angenommen hat. Es ist falsch, dass das nicht vorkommen kann. Es ist wiederum richtig, dass der Sketcher sie im Griff hat und anzeigt. Ich zeige gerne ein Beispiel, wenn Du versprichst, dann nicht über FreeCAD zu meckern, welches solches zulässt.

2.) "redundante constraints" nimmt der Sketcher offenbar gerne an. Nun könnte man ja meinen: Hey ist doch cool, warum sollten mich die stören, wenn ich einem Teilkreis mehrfach 'n Radius geben kann. So wie ich das nach meinem bisherigen Verständnis sehe, fließen alle Constraints, wenn der Sketcher diese nicht anmeckert, in das in Folge zu bestimmende Gleichungssystem. Ist das richtig oder falsch?
Wenn dem so wäre, ist das dem Iterationsverfahren übergebene Gleichungssystem überbestimmt, nun könnte man auch an dieser Stelle noch sagen: macht nix, denn es wäre lediglich "redundant". Nach meinem Verständnis ist das aber nicht egal, denn es wäre vielleicht mathematisch(<=symbolisch) redundant, aber ganz bestimmt nicht egal, wenn man ein Iterationsverfahren mit begrenzter/fester Fließkommaarithmetik drüber laufen läßt, denn ich vermute mal, FC wird wohl keine eigene Arithmetik mit beliebig variabler Genauigkeit mitbringen. Ist das richtig oder falsch? (Für mich wäre es zumindest auch die technische Erklärung, warum "Nuten explodieren", siehe anderer Thread).

Ich sehe bei einem gut konvergierenden Verfahren wie Newton kein Problem, vom Aufwand mal abgesehen, denn die Lösungen konvergieren alle gegen dasselbe System. Wenn es eine Näherungslösung gibt, dann erfüllen natürlich auch alle Constraints (genähert) diese Lösung.
Ich glaube nicht, dass es sinnvoll ist, hier weiter nach Mängeln zu suchen, Weil der Sketcher mit etwas Gewöhnung sehr gut zu handhaben ist. Mir ist es lieber, wenn die Entwickler Dinge angehen, die man braucht, und dann muss man sich halt mal auf die alten Hasen verlassen, die einm sagen was man besser vermeiden sollte.

[HartmutG]

Es ist falsch, dass das nicht vorkommen kann. Es ist wiederum richtig, dass der Sketcher sie im Griff hat und anzeigt. Ich zeige gerne ein Beispiel, wenn Du versprichst, dann nicht über FreeCAD zu meckern, welches solches zulässt.

ne, danke, lass mal lieber die geheimen Defizite in der Schublade. Es reicht mir Dein Wort, das der Sketcher sie im Griff hat (was man natürlich nicht genau wissen kann, wenn ich vorher ein Non-Disclosure-Versprechen abgeben muss).

Ich sehe bei einem gut konvergierenden Verfahren wie Newton kein Problem, vom Aufwand mal abgesehen, denn die Lösungen konvergieren alle gegen dasselbe System. Wenn es eine Näherungslösung gibt, dann erfüllen natürlich auch alle Constraints (genähert) diese Lösung.

Aber mein Beispiel mit den explodierenden Nuten hast Du schon gesehen, oder? Da waren auch Teilkreis-, Horizontal- und Achsenkonstraints involviert die redundant waren.

Ich glaube nicht, dass es sinnvoll ist, hier weiter nach Mängeln zu suchen, Weil der Sketcher mit etwas Gewöhnung sehr gut zu handhaben ist. Mir ist es lieber, wenn die Entwickler Dinge angehen, die man braucht, und dann muss man sich halt mal auf die alten Hasen verlassen, die einm sagen was man besser vermeiden sollte.

Wenn das dann natürlich Deine Einstellung ist, sorry das ich da nachgebohrt habe. Ist selbstverständlich alles in Butter, keiner sucht nach irgendwas, alles Top, schau ich aus dem Fenster: die Sonne scheint (jetzt gerade hier zumindest) und die Fehler (die es ohnehin nicht gibt) lassen wir lieber in der Schublade.
Ich dachte, es gäbe noch andere hier, die aus Interesse/Freude an der Technik dem auf den Grund gehen wollen (oder so nett wären, es zu erklären), selbst wenn meine Vermutung totaler Müll ist. Mir ist bekannt, das ich das Problem vor dem Bildschirm bin.

Was Deine Abschätzung von "gut konvergierenden Verfahren, die sowieso alle gegen dasselbe konvergieren" betrifft, ist Dir aber schon klar, was ich meinte, oder? Schreib mal:
z:=a/10000000
s:=0
for i=1 to 10000000 s:=s+z
for i=1 to 10000000 s:=s*(s-a+1)

na? Und gegen was "konvergiert" da dann "s"? Sieht doch jeder, dass das banal ist und selbstverständlich "a" bei rauskommt, oder?
und was die Entwickler nunmal machen, ob weniger Fehler oder mehr Features, tja, wir kennen nun deine und meine Einstellung dazu. Was Sie am Ende draus machen entscheiden sie dann letzten Endes eh selber.

http://www.lahey.com/float.htm

[chrisb]

Was Deine Abschätzung von "gut konvergierenden Verfahren, die sowieso alle gegen dasselbe konvergieren" betrifft, ist Dir aber schon klar, was ich meinte, oder? Schreib mal:
z:=a/10000000
s:=0
for i=1 to 10000000 s:=s+z
for i=1 to 10000000 s:=s*(s-a+1)

na? Und gegen was "konvergiert" da dann "s"? Sieht doch jeder, dass das banal ist und selbstverständlich "a" bei rauskommt, oder?

...Gelöscht von Moderator... Du hast ein wohlbekanntes Beispiel für die Probleme mit Gleitkommaberechnungen endlicher Genauigkeit gebracht. Das ist 1. kein gut konvergierendes Verfahren, hat 2. nichts mit dem Verfahren für das Lösen der Jacobi-Matrix zu tun und schießt 3. am Problem weit vorbei, weil der Sketcher doch eine Lösung gefunden hat. Obendrein ist fraglich ob CAD-Programme wirklich auf 1/10000000 genau sein müssen.

und was die Entwickler nunmal machen, ob weniger Fehler oder mehr Features, tja, wir kennen nun deine und meine Einstellung dazu. Was Sie am Ende draus machen entscheiden sie dann letzten Endes eh selber.

Es ist nicht klar was Du eigentlich willst. Ein CAD-Werkzeug, das Du benutzen kannst oder einen verbesserten Sketcher. Im letzten Fall solltest Du über Eigeninitiative nachdenken, grundlegende Kenntnisse im Programmieren (mit Basic?) hast Du ja; dann schau es Dir doch einfach mal an!

[HartmutG]

Du hast ein wohlbekanntes Beispiel für die Probleme mit Gleitkommaberechnungen endlicher Genauigkeit gebracht. Das ist 1. kein gut konvergierendes Verfahren,

uiiii, selbst sowas triviales geht also schon den Bach runter und Du bist dennoch der Meinung, dass:

hat 2. nichts mit dem Verfahren für das Lösen der Jacobi-Matrix zu tun

offenbar bist Du der entsprechende Entwickler das zu erklären. Im übrigen ging es um die "Bestimmtheit", die dann nämlich im Iterationsverfahren endet und gerade dort vermutete ich das. Aber danke an dieser Stelle für die Erklärung/Richtigstellung, hab' ich wieder was dazu gelernt. Hättest Du doch schon drei Posts früher sagen können: "Axoim 1: FC ist fehlerfrei und strotzt jeglichen natürlichen Widerkeiten von Fließkommaarithmetik."

und schießt 3. am Problem weit vorbei, weil der Sketcher doch eine Lösung gefunden hat. Obendrein ist fraglich ob CAD-Programme wirklich auf 1/10000000 genau sein müssen.

naja, also ob eine hunderte kilometergroße Nut, die FC in eine unbedienbare Diashow verwandelt nun eine akzeptable 1/10000000 genaue Lösung ist, mag jeder Benutzer selber für sich beantworten. Du findst den Fehler cool und hast lieber 'n Workaround, dafür aber neue Features, bei mir (ehemaliger Entwickler von kommerziellen Steuerungen) ist es umgekehrt. Ist müßig mit Dir drüber zu diskutieren.
Und natürlich könnte man mit der gigantomanischen Nut auch leben, sieht doch cool aus und meine GTX1080 hat das Hilfsgitter sogar in vertretbarer Zeit gerendert, aber weißt Du mit Sicherheit, an welchen (ähnlichen) Stellen das weitere Dinge in den Abgrund zieht, die man vielleicht nicht so offensichtlich zu Gesicht bekommt?

Dir gefällt mein Ton nicht? An welcher Stelle eigentlich konkret? Welche Stelle ist beleidigend und/oder unpassend, sag schon? Könnte es vielleicht auch an Dir und Deiner Erwartungshaltung liegen, das Du manche Dinge einfach nicht sehen WILLST?