Klotzkopp

Von der, die durch das Dreieck selbst aufgespannt wird. Das Dreieck definiert eine Ebene im R3, und wenn dein Punkt gar nicht erst in dieser Ebene liegt, hat dein Gleichungssystem gar keine Lösung. Auch dann ist deine Formel nicht "sicher". Schau dir die Formel für t an: Egal wo P liegt, wenn c.X == a.X ist, dividierst du da durch 0.

Du hast nicht bedacht, dass in R3 der Fall auftreten kann, dass P gar nicht in der Ebene des Dreiecks liegt. In diesem Fall gibt es keine Lösung für s und t, da du ja durch keine Linearkombination aus dieser Ebene herauskommst. Das müsstest du also vorher prüfen. Das hier könnte interessant für dich sein: Point in triangle test Bedenke bitte auch, dass dir die Ungenauigkeit der Fließkommatypen hier ordentlich in die Suppe spucken kann.

So allgemein kann man das auch nicht sagen. Die Laufzeitkomplexität sagt ja nichts über die tatsächliche Dauer aus. Bei kleinen Arrays können die O(n^2)-Algorithmen durchaus schneller als die mit O(n log n) sein. Es kommt auch darauf an, ob die Daten vorsortiert sind, und wie teuer Vergleiche in Relation zu Vertauschungen sind. Es gibt nicht "den" besten Sortieralgorithmus für jede Situation.

Du hast keine Frage gestellt, deswegen gebe ich einfach mal so meine Kommentare ab Soso Normalerweise würde man den gesamten Algorithmus in eine Funktion packen. Aber das ist ja keine große Sache. Es gibt (je nach Plattform) einen Unterschied zwischen unsigned long und unsigned int. Im Hinblick auf Portierbarkeit ist es daher auch keine gute Idee, solche Konstanten fest in den Code zu schreiben. Du vergleichst vorzeichenlose mit vorzeichenbehafteten Werten. Das ist generell keine gute Idee. Dein Algorithmus funktioniert darum auch nicht, wenn negative Werte auftreten. Hast du das nachgemessen, oder wie kommst du darauf? Ein Algorithmus wird nicht zwangsläufig dadurch performanter, dass man die Anzahl der äußeren Schleifendurchläufe reduziert. Inwiefern ist das ein Gewinn? Dein Algorithmus braucht genauso viele Vergleiche und Tauschoperationen wie Selection Sort.Du hast vielleicht nur halb so viele Schleifendurchläufe, allerdings machst du bei jedem Durchlauf doppelt so viel. Dein Algorithmus hat dieselbe Laufzeitkomplexität wie Selection Sort (O(n^2)) und auch dieselben Nachteile (nicht stabil, nicht natürlich).

Ich vermute, du erzeugst irgendwo in deinem Code undefiniertes Verhalten. Dann kann alles passieren. Ohne den Code zu kennen, kann man dazu nicht mehr sagen.

Wenn du kein Konsolenfenster willst, dann erstell das Programm doch einfach nicht als Konsolenanwendung.

Wieviel Speicher ein Pixel braucht, ergibt sich aus der angegebenen Farbtiefe: 16 Bit = 2 Byte.

Warum fängst es nicht einfach ab, wenn Fields Null zurückgibt?

Das ist definitiv so. Wenn ich in Excel die Klammern so setze, dass der Ausdruck einfach von links nach rechts berechnet wird, komme ich genau auf deine falschen Ergebnisse.

Bist du sicher, dass es ein Feld namens "BuchungsNr" gibt, und da auch immer etwas drinsteht? Die Fehlermeldung lässt darauf schließen, dass dieser Aufruf Null ergibt, worüber AddItem natürlich nicht so glücklich ist.

:eek Das Problem hat mit der Fallunterscheidung für das Vorzeichen nicht das Geringste zu tun. Die ist immer noch überflüssig und falsch. Das Problem ist, dass die Programmiersprache, die du da benutzt, offenbar Punkt-vor-Strich nicht beherrscht. Die zusätzlichen Klammern in den Formeln sind es, die das Problem gelöst haben. :upps

Was praktisch gesehen dasselbe ist. Radiant ist eine Hilfsmaßeinheit für (das eigentlich einheitenlose) Bogenmaß.

Offenbar erwartet die Sinusfunktion, die du da benutzt, ihr Argument in Grad, nicht in Bogenmaß.

Das sieht soweit gut aus. Jetzt müssen wir noch berücksichtigen, dass du, falls alpha >= 0 ist, das Vorzeichen wechselst. Bitte die Werte für $alpha * (-1) Sin($alpha * (-1)) Cos($alpha * (-1)) $1*Cos($alpha * (-1)) $2*Sin($alpha * (-1))

Ich habe das mal mit Excel nachvollzogen, und komme auf diese Werte (gerundet): 6 56 100 90 83 137 -11 103 Das sieht immer noch wie ein Rechteck aus. Deine Y-Werte sind mehr oder weniger in Ordnung, aber deine X-Werte sind alle zu klein, eigenartigerweise paarweise um denselben Betrag. Zeig doch bitte mal folgende Werte: $alpha Sin($alpha) Cos($alpha) $1*Cos($alpha) $2*Sin($alpha)

Zeig doch bitte mal die Werte in links, oben, laenge, breite und koord (nach dem Aufruf), damit man den Fehler besser eingrenzen kann.

Nein. Die Matrix gilt immer, auch wenn der Winkel negativ ist. Ist dir nicht aufgefallen, dass der einzige Unterschied zwischen dem Code im if-Block und dem im else-Block der ist, dass du das Vorzeichen von alpha umdrehst? Das heißt, du machst bei -45° dasselbe wie bei +45°. Das kann's ja wohl nicht sein. Ansonsten sieht die Rechnung gut aus. Bist du sicher, dass die Eingabedaten richtig verteilt sind und du die Ausgabedaten richtig interpretierst? Gib doch einfach mal die Werte aller Ein- und Ausgabevariablen mit an.

@Stampi: Die Unterscheidung des Vorzeichens des Winkels ist übrigens überflüssig, und in deinem Fall sogar falsch, weil du effektiv das Vorzeichen ignorierst.

Ja.

Ich komme auf 1000, nicht 500. Das ändert aber nichts am Prinzip. Das ist völlig unerheblich. Da wird auch nichts angenähert. Der Zufall hat kein Gedächtnis. Es ist völlig wurscht, wie oft man vorher wo gezogen hat. Wo man ziehen sollte, ergibt sich ausschließlich aus dem Wert der Y.

Es gibt keine "if-Schleife". Du könntest in den ersten beiden if-Blöcken die weitere Verarbeitung des Schleifenkörpers abbrechen (continue) oder das Ganze als if/else if-Kaskade aufbauen.

Oder um es anders zu formulieren: Dein else bezieht sich nicht auf alle drei if, sondern nur auf das letzte.

Soweit schon mal falsch. Das ist aber nicht das einzige, was passiert. Da die dritte Bedingung nicht wahr ist, wird deren else-Block auch ausgeführt. Damit wird i zweimal inkrementiert.

Zähl doch mal nach, was in deiner Schleife mit i passiert, wenn zeichen '1' ist.

Du solltest die Texte vorher in Zahlwerte umwandeln. Ein Operand ist das Ding, auf das ein Operator angewendet wird. "operant" ist ein Adjektiv und hat mit Operatoren nichts zu tun.