Winkel der Linie berechnen

@Comfreek:
Zu bestimmten Funktionen hab ich schon Forenbeiträge gesehen,
wo das indirekt von WA-Mitrbeitern sogar bestätigt wurde.
Wenn ich sie nur wieder finden würde...

Stattdessen gibts drei konkrete Beispiele:


a)
Bild 1, ein Integral, gelöst (und händisch die Korrektheit nachweisbar)
Bild 2, ist das Selbe.

(Falls es wer nicht weiß: a^(-b) <=> 1/(a^b)
und a^(b*c) <=> (a^b)^c
und a^0.5 <=> Quadratwurzel a
(wobei ^ nicht Xor, sondern Potenzieren ist))

Selber Ausdruck also.
WA gibt ziemlich damit an (oder hat es in der Vergangenheit zumindest),
den einzigen vollständigen automatischen Integrierer der Welt zu haben
(der mit wirklich jedem Ausdruck zurechtkommen soll).
Und die Umformung in den Reellen/komplexen Zahlen ist trivial
(und anderes Zeug sollte eigentlich ohne hinschreiben nicht rein kommen)

Ergebnis, wie man sieht: Es hat erkannt, dass Bruchnenner unter den Bruchstrich kommen,
und dann war die Rechenzeit aufgebraucht (noch dazu in der Bezahlversion, die so eine Beschränkung beim Bezahlen noch nicht hatte. Genau deswegen wurde eigentlich gezahlt)


b)
Ein lin. Gleichungssystem. Irgendwas wie
Code:
a+b+c=4
2a+3b+4c=-2
a+9b=10

Werte für a,b,c sind...?
Bild drei zeigt, dass WA sowas lösen kann (im Bild sind zu wenig Gleichungen,
um eindeutige Werte zu bekommen, aber es wurde immerhin so weit wie möglich gemacht)

Gibt man mehr Gleichungen dazu (noch 3, damit wären eindeutige Zahlenlösungen möglich):
WA kanns plötzlich nicht mehr parsen.
Ich hätte Verständnis dafür, dass es heißt "Zu viel Arbeit ohne Gegenleistung".
Da das noch immer die Bezahlversion ist gilt das aber nicht.
Und dass es alles plötzlich nicht mehr parsen kann...
(und es ist kein Syntaxfehler drin. Jede der 5 Gleichungen einzeln wird verstanden,
Kombinationen von 2-4 Gleichungen auch, aber 5 zusammen ist zu viel...)


c)
Bild 5
Ein Ausdruck minus den selben, nur anders hingeschrieben (teilweise wieder die Formeln von a).
x-x ist für mich 0, diesmal hat es die Umformung auch geschafft ("Result: 0").
Trotzdem sind im Diagramm darunter interessante Zacken...
Bei 10^(-16) denkt man an double-Rundungsfehler,
aber wenn der Input für die Diagrammerstellung das umgeformte "y=0" ist
ist sowas etwas unverständlich.
Und WA rechnet außerdem nicht mit normalen 32bit-Variablen
(2^90248 geht zu 100% genau auszurechnen,
aber manchmal gilt 0=10^(-16) eben einfach so...wtf)
 

Anhänge

  • 1.JPG
    1.JPG
    27,1 KB · Aufrufe: 12
  • 2.JPG
    2.JPG
    31,1 KB · Aufrufe: 14
  • 3.JPG
    3.JPG
    27,9 KB · Aufrufe: 19
  • 4.JPG
    4.JPG
    30,7 KB · Aufrufe: 12
  • 5.JPG
    5.JPG
    22,8 KB · Aufrufe: 14
Vielen Dank für die Antwort sheel! Schon echt seltsam, was die da abziehen.

@Joe

Ah ok, ich dachte die ganze Zeit, dass du die Zahlenwerte aus der Grafik nimmst :D
Aber ich verstehe immer noch nicht, wie du auf "0,0011" kommst.

Ehrlich gesagt, weiß ich auch nicht, wieso du das alles überhaupt machst. Ich meine, wie genau lautet dein Ansatz? Wenn man zwei Punkte hat, dann ist mein Ansatz der einfachste. Natürlich kann man alles noch komplizierter machen, aber wieso?

Naja Neugierde treibt den Menschen vorwärts^^
Im Folgenden noch ein Ansatz inkl. Skizze.

grafik.png
Anmerkungen
- Die Funktion d(P1; P2) berechnet die Distanz zwischen den Punkten P1 und P2.

- Da in unserem Fall P1 und P3 bzw. P2 und P3 genau parallel zur x-Achse bzw. zur y-Achse ausgerichtet sind, brauchen wir keinen Pythagoras bei der Berechnung, sondern können stattdessen einfach auf die Differenzen ihrer x- bzw. y-Komponente zurückgreifen.
Dies ist z.B. nicht der Fall bei d(P1; P2)! Hierbei muss die Distanz mittels des Pythagoras errechnet werden.

- Geschickterweise wendet man eine Translation an, sodass P1 genau im Koordinatensystemursprung liegt. Somit vermeiden wir, die jeweiligen x- und y-Werte von P1 und P3 kennen zu müssen. Wenn diese nämlich auf der x-Achse liegen, können wir getrost 0 jeweils einsetzen.

Code:
P1(xp1; yp1)
P2(xp2; yp2)
P3(xp3; yp3)

          Gegenkathete       d(P2; P3)               yp2 - yp3                      yp2 - yp3
sin ? = ----------------- = ------------ = --------------------------- = --------------------------------
           Hypotenuse        d(P1; P2)      /-----------------------|     /---------------------------| 
                                          \/ d(P1; P3)² + d(P2; P3)²    \/ (xp3 - xp1)² + (yp2 - yp3)²
Ich hoffe, eure Browser rendern dies richtig.

Nun kann man die Werte einsetzen (entnommen aus Beitrag #10 von mir)
Code:
yp2 - yp1 = 187

(xp3 - xp1)² = (308 - 0)² = 308²
(yp2 - yp3)² = (187 - 0)² = 187²
=> sqrt(308² + 187²) = 11 * sqrt(1073)

              187                17 
sin ? = ---------------- = --------------
         11 * sqrt(1073)     sqrt(1073)

mittels arcsin: ? = 31.26°

Und nichts anderes habe ich in meinem vorherigen Beitrag #10 herausgefunden ;)
 
Ich kann nochmal etwas Hilfe gebrauchen bei der Berechnung.

Ich habe hier ein neues Beispiel.

Das ist wieder eine Trendlinie mit zwei Zeitangaben und Kursangaben, diesmal habe ich die beiden Zeitangaben als Unix Timestemp Sekunden genommen und subtrahiert, ergebniss ist: 207000 Sekunden vielleicht ist die Zeit Sekunden zu klein und man sollte das auf Minuten oder Stunden, Tage umrechnen, aber ich habe jetzt mal die Sekunden aufgeschrieben.

Dann habe ich die beiden Kurswerte der Linie subtrahiert und dort sind es: 0.00735 Unterschied zwischen beiden Punkten

Nun koennte ich ja eine Formel von ComFreek seinem Beispiel benutzen, das wuerde dann so aussehen:

0.00735 / 207000 = 28163265,30612245

und von diesem Ergebniss mus man dann ein "arctan" wert erhalten?

Ich habe eine arctan Funktion in meinem Programm gefunden die gibt mir als Ergebnis fuer "28163265,30612245 " ein arctan wert von 1.57

aber irgendetwas ist das noch falsch, die trendlinie hat ein Winkel von ca.20-30 Grad, hier sind auch nochmal die original Trendlinien Werte:

Zeit 1: 2013.11.25 17:00
Kurs 1: 1.349

Zeit 2: 2013.11.28 02:30
Kurs 2: 1.35635
 
Zuletzt bearbeitet:
Erstmal ist es zwar dein Arctan-Wert richtig, allerdings ist es nicht in Grad angegeben. Man muss immer drauf achten, welche Einheit die trigonometrischen Funktionen im aktuellen Modus (z.B. beim Taschenrechner) akzeptieren.
Wenn man 1,57 umrechnet, bekommt man einen ungefähren Wert von 89,99...° raus.

Dieser Wert mag zwar komisch erscheinen, ist aber nicht falsch!
Das liegt einfach an deiner Einheit der Datumsskala.

Nun könnte man ein wenig rumprobieren, allerdings kann man auch rechnerisch den Wert für die Datumsdifferenz herausbekommen, damit ein Winkel von 25° beispielsweise gebildet wird:
Code:
tan ? = 0.00735 / x
=> x = 0.00735 / tan ?

Mit ? = 25°:
x = 0.01576
Nun muss man noch irgendwie erreichen, eine sinnvolle Umrechnung deiner Datumsdifferenz von der Einheit Sekunde zu einer Einheit, dessen Wert dann 0.01576 entspricht, zu finden.
Ich habe auf die Schnelle leider keine gefunden (weder Wochen, Monate, Quartale oder Jahre).
 
ich glaube bei der Zeiteinheit muss man das dann bei diesen Charts so machen, das man die Bars zwischen beiden Linienpunkten abzaehlt. Ich sollte mal auf die weise weiter testen.
 
Zurück