Freitag, 19. April 2024, 04:32 UTC+2

Sie sind nicht angemeldet.

  • Anmelden
  • Registrieren

Arinest

unregistriert

1

Freitag, 8. Februar 2013, 11:14

Probleme mit der Round()-Funktion

Hallo,

ich benutze die Round()-Funktion, um meine berechneten "unrunden" Entry- und Exitwerte den Underlyings anzupassen. Ergibt sich bspw. ein Entry bei 7013,678 im Dax-Future runde ich diesen Wert auf 7013,5 ab.
Nun ergeben sich aber bei einem neuen Test für mich nicht nachvollziehbare Rundungen. Am besten lass ich Bilder sprechen.

Die Grafik zeigt den FDAX-Future. Die grünen Punkte markieren Rundungen nach folgender Definition: If(Round(High) > High, Round(High) - 0.5, Round(High)).
Die roten Pfeile zeigen Beispielswerte an, bei denen nach der Rundung ein Wert von 0,5 Punkten unterhalb dem High entsteht. Ich versteh nicht, wieso das passiert.

Gruß,
Arinest


Ganesha

unregistriert

2

Freitag, 8. Februar 2013, 12:24

Die Grafik zeigt den FDAX-Future. Die grünen Punkte markieren Rundungen nach folgender Definition: If(Round(High) > High, Round(High) - 0.5, Round(High)).
Die roten Pfeile zeigen Beispielswerte an, bei denen nach der Rundung ein Wert von 0,5 Punkten unterhalb dem High entsteht. Ich versteh nicht, wieso das passiert.
IMO ist das doch was Du mit der IF-Abfrage machst. Immer wenn der Kurs aufgerundet wird, dann ziehe einen halben Punkt ab.

Steht der Kurs (fiktiv) bei 7013,99999999 dann hast Du nach der Rundung 7014 und davon wird dann ein halber Punkt abgezogen. Der grüne Punkt steht also rund einen halben Punkt unter dem High.

Arinest

unregistriert

3

Freitag, 8. Februar 2013, 14:28

Danke für die Antwort Ganesha,

alle Daten, die du in der Grafik siehst, sind reale Daten. D.h., es gibt keinen fiktiven Wert 7013,99999999, sondern nur 7013; 7013,5; 7014 usw.
Bsp: 7013 --> gerundet bleibt 7013 --> Ergebnis Round(7013), also 7013
Bsp: 7013,5 --> gerundet 7014 --> 7014 -0,5, also 7013,5

Da die Daten alle reale Daten sind, müsste bei der If-Funktion immer das gleiche Ergebnis wie das reale Hoch rauskommen, ODER?

Dieser Rundungs-"Fehler" entsteht vorwiegend (oder fast auschließlich) bei ,5- Werten (zB. 7013,5) als Hoch.
Da aber bei ,5-Werten auch das richtige Hoch nach der Rundung errechnet wird, stehe ich vor einem Rätsel.

Ganesha

unregistriert

4

Freitag, 8. Februar 2013, 16:33

Hallo,

ich bin verwirrt, ich verstehe Dein Problem nicht. :)

Zunächst: Rundungen ist ein schwieriges Thema, auch wenn es einfach aussieht. Investox benutzt (vermutlich) intern einen Datentyp double. Diese Datentyp kann große Fließkommazahlen aufnehmen, ist aber eigentlich nicht dafür geeignet damit zu rechnen (und Runden ist eine Rechnung). Der Grund ist, dass zum Beispiel 7000.5 möglicherweise nicht als 7000.5 gespeichert wird, sondern z.B. als 7000.50000000000000000000001 oder 7000.49999999999999999. Wie genau die Zahl gespeichert wird, ist von CPU zu CPU unterschiedlich. Macht in der Praxis überhaupt keinen Unterschied, bewirkt aber das die Zahl größer <>7000.5 ist.

Dann: Mir ist nicht klar was Du eigentlich machen will. Ich vermute, dass Du einfach die Funktionalität von 'floor()' haben willst. Also den ganzzahligen Wert einer Zahl.

Die von Dir markierten Bars sehen für mich alle korrekt aus. Soweit man das auf dem Monitor sehen kann. Du kannst die Berechnungsergebnisse ebenfalls auf dem Chart anzeigen. Mit dem Mauspfeil kann man dann über den Bar gehen und sich anzeigen lassen, wie groß der numerische Wert ist.

In Deinem Fall würde ich sagen: lege mal eine Berechnung in den Chart die dieses hier macht:

Quellcode

1
2
3
calc round: if(round(high)>high, round(high)-0.5, round(high));
calc floor: floor(high);
if(round <> floor, 1, 0)


Der erzeugte Graph müsste konstant 0 anzeigen. Gibt es irgendwo eine 1, stimmt was nicht, dann müsste da genauer hingucken.

Viele Grüße

Arinest

unregistriert

5

Freitag, 8. Februar 2013, 23:29

Nochmals Danke für deine Bemühungen Ganesha,

ohne weitere Verwirrungen stiften zu wollen und erkären zu müssen, was denn das ganze überhaupt soll, stelle ich mir folgende Frage: Warum erhalte ich bei Rundungen von Zahlen mit einer 5 nach dem Komma (zB. 7000.5) nicht immer ein aufgerundetes Ergebnis, sondern auch ein abgerundetes.

Zunächst: Rundungen ist ein schwieriges Thema, auch wenn es einfach aussieht. Investox benutzt (vermutlich) intern einen Datentyp double. Diese Datentyp kann große Fließkommazahlen aufnehmen, ist aber eigentlich nicht dafür geeignet damit zu rechnen (und Runden ist eine Rechnung). Der Grund ist, dass zum Beispiel 7000.5 möglicherweise nicht als 7000.5 gespeichert wird, sondern z.B. als 7000.50000000000000000000001 oder 7000.49999999999999999. Wie genau die Zahl gespeichert wird, ist von CPU zu CPU unterschiedlich. Macht in der Praxis überhaupt keinen Unterschied, bewirkt aber das die Zahl größer <>7000.5 ist.


Das trifft es wohl haargenau. Es wird keinen Einfluss auf meine Berechnungen haben, da ich seltenst ,5-Werte runde. Es fiel mir lediglich auf und ich will nunmal immer wissen, warum das so ist. Danke für deine Hilfe.

Hier noch eine Grafik des 5min-FDAX, wobei der grüne Punkt jetzt der Einfachheit halber Round(High) ist.



Gruß,
Arinest

tomi

unregistriert

6

Samstag, 9. Februar 2013, 13:07

Hallo

Zitat

Frage: Warum erhalte ich bei Rundungen von Zahlen mit einer 5 nach dem Komma (zB. 7000.5) nicht immer ein aufgerundetes Ergebnis, sondern auch ein abgerundetes.

Ohne dass ich das jetzt in Investox nachgeprüft habe, denke ich, dass es an der sog. mathematische Rundung liegt. S. http://de.wikipedia.org/wiki/Rundung: "Folgt auf die letzte beizubehaltende Ziffer lediglich eine 5 (oder eine 5, auf die nur Nullen folgen), so wird derart gerundet, dass die letzte beizubehaltende Ziffer gerade wird."

7653.5 wird also aufgerundet zu 7654, während 7652.5 abgerundet wird. Die meisten Programmiersprachen verwenden diese Rundungsregel - Excel hingegen nicht.

Gruss, Thomas

Lenzelott Männlich

Experte

Registrierungsdatum: 30. Dezember 2002

Beiträge: 3 051

Wohnort: Giessen

7

Samstag, 9. Februar 2013, 13:30

Ich löse das "Problem" normalerweise in meinen Systemen wie folgt:

Quellcode

1
2
calc ticksize:#_MinPriceChange#;
INT(close/ticksize)*ticksize
If you think it´s expensive to hire a professional, wait until you hire an amateur.

Arinest

unregistriert

8

Samstag, 9. Februar 2013, 18:21

@ tomi
Ja, es ist wirklich die 3.Regel der Mathemathischen Rundung. Kannt ich noch nicht. Wieder was dazu gelernt. Dank dir.

@Lenzelott
Danke.

Gruß,
Arinest

Ganesha

unregistriert

9

Samstag, 9. Februar 2013, 18:49

@All: Ich muss fragen: In welchem Kontext besteht überhaupt Bedarf einen Preis zu runden?

Arinest

unregistriert

10

Sonntag, 10. Februar 2013, 17:41

@All: Ich muss fragen: In welchem Kontext besteht überhaupt Bedarf einen Preis zu runden?

Wie schon gesagt, ging es mir hauptsächlich um das Wissen warum so gerundet wird.

Preise an sich runde ich nicht. Das Runden benutze ich zur genauen Bestimmung meiner Entrys und Exits. Bsp.: System sagt Short Entry bei 7114.834. Investox rundet auf 7115. Ich will aber 7114.5 als Entry.
Das gleiche Prinzip auch bei der Bestimmung der Kontraktanzahl.

Gruß,
Arinest