reaktors spannendes rundungsverhalten

[helmsklamm]

auch son schönes ding, wo man sich fragt, ob bei der entwicklung irgendjemand auch nur ein kleinteil hirn eingeschaltet hatte, oder schon alle im WE waren:

was soll diese beknackte rundungsverhalten, bzw. die willkür, wie die einzelnen module runden????

sorry, die listung ist nicht völlständig, das sind grad die sachen die mir einfallen und gehörig nerven.

der selector, und das MultiPic runden bei GENAU der nächsten exakten INTEGER auf. selsbts bei einem raster, das die denormalen streift, kann man sich völlig daruf verlassen. (diese verhalten finde ich am logichsten und ansprechensten, -brauch man was andres: einfach entsprechend addieren)

einige module, wie bspw. das XY oder der router runden sofort AUF. gewissermassen ist das aähnlich zu oben - aber genau diese annahme ist falsch: wenn der selctor bei EXAKT 1 umspringt, der router oder das XY hingegen erst bei 0+ ultraklein (denormal) ist das weder mathematisch und schon garnicht praktisch dasgleiche.

aber noch schöner:

die meisten module aber, wie quantize, SVA,snap, modulo ETC. leben im n.5 raster.

das wär völlig ok, wenn n.5

A: für alle gelten würde

B:klar definiert wäre und eben ENTWEDER auf- oder abrundet, aber nicht mal dies, mal jenes.
bei klangmodifikation ist das sicher bedeutungsls, bei bedingungslogik aber unabdingbar. ein "wenn A und B GLEICH, dann C VIELLEICHT so oder möglicherweise so" ist nicht gerade verlässlich.
das schlimmste jedoch: ein VIELLEICHT zerstört leider nicht absolut, sondern eben nur "vielleicht" - was die fehlerqeullensuche zum echten geduldsspiel macht.

ganz abgesehen davon ist dieser nötige modulverhau um zwischen "rundern" zu konvertieren schlichtweg nur nervig und ineffizient.

vielleicht gibts ja tatsächlich irgednwo jemand der unterschiedliche "runder" liebt - ich wage aber zu behaupten, das mehr leuten an ner transparenteren und effizienteren bedienung gelegen sien dürfte.
jede konstante frisst speicher und jedes add cpu und jedes unnütze einfügen daqvon zeit und und nerven.

aber vielleicht gibts ja gute gründe dafür.

und btw: vielleicht kann mir ja mal einer verraten warum das SVA so aus der reihe tanzt und vorne/hinten ein +1/-1 verlangt? welch wietsichtiger gedanke leigt dem zugrunde??

[herw]

auch son schönes ding, wo man sich fragt, ob bei der entwicklung irgendjemand auch nur ein kleinteil hirn eingeschaltet hatte, oder schon alle im WE waren:

was soll diese beknackte rundungsverhalten, bzw. die willkür, wie die einzelnen module runden????

sorry, die listung ist nicht völlständig, das sind grad die sachen die mir einfallen und gehörig nerven.

der selector, und das MultiPic runden bei GENAU der nächsten exakten INTEGER auf. selsbts bei einem raster, das die denormalen streift, kann man sich völlig daruf verlassen. (diese verhalten finde ich am logichsten und ansprechensten, -brauch man was andres: einfach entsprechend addieren)

einige module, wie bspw. das XY oder der router runden sofort AUF. gewissermassen ist das aähnlich zu oben - aber genau diese annahme ist falsch: wenn der selctor bei EXAKT 1 umspringt, der router oder das XY hingegen erst bei 0+ ultraklein (denormal) ist das weder mathematisch und schon garnicht praktisch dasgleiche.

aber noch schöner:

die meisten module aber, wie quantize, SVA,snap, modulo ETC. leben im n.5 raster.

das wär völlig ok, wenn n.5

A: für alle gelten würde

B:klar definiert wäre und eben ENTWEDER auf- oder abrundet, aber nicht mal dies, mal jenes.
bei klangmodifikation ist das sicher bedeutungsls, bei bedingungslogik aber unabdingbar. ein "wenn A und B GLEICH, dann C VIELLEICHT so oder möglicherweise so" ist nicht gerade verlässlich.
das schlimmste jedoch: ein VIELLEICHT zerstört leider nicht absolut, sondern eben nur "vielleicht" - was die fehlerqeullensuche zum echten geduldsspiel macht.

ganz abgesehen davon ist dieser nötige modulverhau um zwischen "rundern" zu konvertieren schlichtweg nur nervig und ineffizient.

vielleicht gibts ja tatsächlich irgednwo jemand der unterschiedliche "runder" liebt - ich wage aber zu behaupten, das mehr leuten an ner transparenteren und effizienteren bedienung gelegen sien dürfte.
jede konstante frisst speicher und jedes add cpu und jedes unnütze einfügen daqvon zeit und und nerven.

aber vielleicht gibts ja gute gründe dafür.

und btw: vielleicht kann mir ja mal einer verraten warum das SVA so aus der reihe tanzt und vorne/hinten ein +1/-1 verlangt? welch wietsichtiger gedanke leigt dem zugrunde??

Das ist keine Kurzsichtigkeit, sondern einfach die Konsequenz, die allen digitalen Datenverarbeitungsanlagen anhaftet: es gibt im Bereich der Fließkommazahlen keine hundertprozentige Exaktheit, wenn es um Rechnungen geht.
Man muss prinzipiell akzeptieren, dass digitale Maschinen das Binärsystem zur Verschlüsselung von Zahlen benutzen und bei der Übersetzung Informationen zwangsläufig verloren gehen.
Ein Beispiel: wenn du den Bruch 1/3 im Dezimalsystem darstellen möchtest und auf endlich viele Ziffern beschränkt bist, dann musst Du ab einer bestimmten Stelle eine Rundungsfehler akzeptieren. Periodische Zahlen lassen sich eben in jedem Stellensystem nicht exakt darstellen; dies gilt natürlich auch für irrationale Zahlen.
Nun erwähnst Du abrechende Dezimalzahlen wie 0,1; 0,25; 12,3 etc. und erwartest eindeutige Rechnungen und Rundungen. Abbrechende Dezimalzahlen sind aber nicht im Binärsystem abbrechend, d.h. abbrechende Dezimalzahlen sind im Binärsystem (meistens) periodisch oder zumindest nur näherungsweise darstellbar. Versuche mal 0,3 darzustellen durch eine Summe der Brüche 1/4, 1/8, 1/16, 1/32 etc..
D.h. ein exaktes Ergebnis ist nicht immer zu erwarten.
Ein sehr markantes Beispiel wird im englischen Forum diskutiert.
Dort wurde durch mehrfaches Drücken eines Buttons der Wert 0,1 gesendet und zu einem Speicher addiert. Sobald die Summe 1 überschritten wird, sollte der Speicher auf 0 zurückgesetzt werden. Dazu wurde die neue Summe mit dem Maximalwert 1 verglichen und siehe da der Speicher wurde schon nach 0,9 zurückgesetzt.
Was war der Grund? Die Werteanzeige des Seicher (numeric readout) zeigte zwar brav nacheinander die Werte 0,1 , 0,2 , ... , 0,9 an; doch verglich man mal die Differenz der Summe mit dem Maximalwert, dann gab es eine kleine Abweichung; die Summe betrug nämlich nach dem 10. Drücken 1,0000001192... somit war die Rücksetzbedingung erfüllt und der Speicher wurde bei der (angeblich) genau erreichten 1 zurückgesetzt.
Interessant bzw. beachtenswert ist, dass die Größer-Beziehung diese kleine Abweichung in der siebten Nachkommastelle nicht berücksichtigt.
Wie auch in jeder Programmiersprache hat man diese kleine System bedingten Abweichung zu berücksichtigen. In der Regel ist das bei Audiosignalen nicht sehr von Bedeutung, da man unter Umständen einen Sample später reagiert. Bei der Eventverarbeitung ist , wie du korrekt beschreibst, das allerdings fatal, da man im Dezimalsystem exakt denkt, aber das System zwangsläufig die Exaktheit im Fließkommabereich nicht einhalten kann.
Dies wird auch im Handbuch (weit versteckt) erwähnt. Man sollte für exakte Berechnungen (wenn es geht) ganze Zahlen benutzen, damit mit diesen (im zulässigen Werteberecih) wirklich exakt gerechnet wird.
Im vorliegenden Fall war es also angesagt, den Button 1 senden zu lassen und beim Überschreiten des Werte 10 den Speicher zurückzusetzen. Vor dem Ausgang des Makros musste man dann nur noch mit 0,1 multiplizieren.
Natürlich geht die Bearbeitung aller möglichen Werte mit integer-Zahlen und einer abschließenden Multiplikation nicht immer bzw. würde alles sehr komplex machen. Wo es aber möglich ist, würde ich zur integer-Rechnung übergehen. Auch die exakte "Rundung" müsste man sich dann als Überschreiten der 5 in der Einerstelle denken.
Das Rundungsmanko ist somit kein Reaktor spezifisches Problem sondern eine grundsätzliche Einschränkung aller digitalen Systeme.

Ich hoffe das ist so einigermaßen rüber gekommen. Das Wort "vielleicht" würde ich also mal so interpretieren: man kann nicht alle Rechnungen und Vergleiche, die Reaktor durchzuführen hat, in ihrer exakten Werteberechnung voraussagen, sondern muss eine (kleine) Schwankungsbreite zulassen.
Wenn Du konkret jetzt also mit exakten Rundungen arbeiten möchtest, musst Du die Werte geeignet in den Bereich der ganzen Zahlen hochziehen (mit abgeschittenen weiteren Dezimalen) und dann entscheiden, ob nach oben oder unten gerundet werden soll.

Das ist jetzt leider sehr theoretisch, aber ich weiß ja nicht, wo die Kernschmelze bei deinem Ensemble stattgefunden hat.
Wenn Du Lust hast, dann lade doch ein sehr kleines Beispiel hoch und man kann das konkret mal ausprobieren. Das hätte dann einen grundsätzlichen Wert.

ciao herw

[helmsklamm]

danke für die ausführung. war sehr aufschlussreich, trotzdem:

ein logikmodul bspw. gibt bei EXAKT 0, oder darunter "falsch" aus. es gibt niemlas bei 0 "wahr" aus. genausso wählt ein selector bei exakt 2 den 2ten eingang und nie den ersten.

was ist bei 0.5 grundsätzlich anders, das es eeben bei 0.5 nicht exakt ein vordefiniertes ergebniss liefert, sondern mal so, mal so? NICHTS, 0.5 ist eine genauso exakte zahl wie 0 oder 2.
lediglich die modul-implementierung ist aus irgeneinem grund als vabanqspiel ausgelegt.

und warum schlatet eben der selector, der router... bei exakter integer weiter, aber bspw. das multidisplay, das SVA... bei (etwas größer) als N.5?
das ist sinnfreie inkoseqeunz, nichts weiter.

und warum sind bspw. die beiden letztgenannten 1-basiert, während der großteil 0-basiert ist? das erfordert doch ebenfalls nur zusätzliche konvertierungen, ohne auch nur die spur einer logischen verbesserung erkennbar werden zu lassen.

[herw]

...ein logikmodul bspw. gibt bei EXAKT 0, oder darunter "falsch" aus. ...

welches Logik-Modul meinst Du und wie ist es beschaltet?

[herw]

...was ist bei 0.5 grundsätzlich anders, das es eeben bei 0.5 nicht exakt ein vordefiniertes ergebniss liefert, sondern mal so, mal so? NICHTS, 0.5 ist eine genauso exakte zahl wie 0 oder 2.
lediglich die modul-implementierung ist aus irgeneinem grund als vabanqspiel ausgelegt.
...

das Runden ist offensichtlich durch die Rechengenauigkeit eingeschränkt. Die Zahl 1,4999999995 (realisiert durch Summe der Konstanten 1,49999 und 9,95E-06) wird richtig abgerundet, während 1,4999999996 (1,49999+9,96E-6) falsch aufgerundet wird. Die Unsicherheit besteht in der zehnten Ziffer nach dem Komma. Problematisch ist das nur, wenn die Eingabezahlen durch mehrere Rechnungen und Rechenungenauigkeiten gerade in diesen Bereich hineinrutschen.
Oder gibt es gröbere Verstöße?

[helmsklamm]

bei logik meinte ich die eingänge und gibt "intern" falsch aus. exakt 0, oder darunter wird als "falsch" interpretiert. exakt 0 wird niemals als VIELLEICHT "wahr" interpretiert. (selbstredend kann der ausgang natürlich "wahr" sein, wenn der eingang "falsch" ist;)

wenn n "fliesskomma-knob" auf die nächthöhrere/niederige integer "fährt", gibt es diese "böse" 10te nackkommastelle nicht?
und was ist, wenn ich nen button habe, der zwischen 0.4 und EXAKT 0.5 toggelt - hier bleibts ja trotzdem (ohnen weitere nackkommastellen) beim VIELLEICHT.

[herw]

bei logik meinte ich die eingänge und gibt "intern" falsch aus. exakt 0, oder darunter wird als "falsch" interpretiert. exakt 0 wird niemals als VIELLEICHT "wahr" interpretiert. (selbstredend kann der ausgang natürlich "wahr" sein, wenn der eingang "falsch" ist;)

wenn n "fliesskomma-knob" auf die nächthöhrere/niederige integer "fährt", gibt es diese "böse" 10te nackkommastelle nicht?
und was ist, wenn ich nen button habe, der zwischen 0.4 und EXAKT 0.5 toggelt - hier bleibts ja trotzdem (ohnen weitere nackkommastellen) beim VIELLEICHT.

ich habe mich da nochmal hineingekniet und ein bisschen experimentiert.
helmsklamm hat Recht damit, dass schon Rundungen in der ersten Stelle nach dem Komma zum Teil falsch gerundet werden.
Bei einem Regler, der zum Beispiel die Schrittweite 0,1 hat, tritt eine falsche Rundung immer dann auf, wenn die Vorkommazahl gerade ist:
also 4,5 wird auf 4 gerundet und 5,5 auf 6 (NI-Rundung).
Zumindest diesen Fehler konnte ich (so hoffe ich) auffangen (herw-Rundung).

verbesserte Rundung.gif

Die Idee ist ganz einfach: Ich multipliziere die vorgegebene Zahl mit 2; dadurch wird diese zu einer ungeraden ganzen Zahl; dann addiere ich 0,5 und runde korrekt. Ich erhalte nun eine gerade Zahl. Nun muss ich die Rundung der doppelt so großen Zahl wieder rückgängig machen: also nochmals 0,5 subtrahieren und wieder runden und dann erst durch 2 dividieren.

verbesserte Rundung1.gif

Die Rundung verläuft dagegen bei beiden Lösungen korrekt mit Abweichungen in der 6. Stelle nach dem Komma:
4,499999 wird korrekt abgerundet und 4,500001 korrekt aufgerundet.
In der siebten Stelle nach dem Komma reagieren beide Lösungen nicht mehr.
Erhöht man übrigens die CoreCell-Rechengenauigkeit auf 64 Bit, so liefern beide Rundungen bis zur Abweichung 1E-15 eine korrekte Rundung.
Der Vorteil meiner Lösung liegt darin, dass die Steuerung mit x.5 immer korrekt ist.
Ich denke helmsklamm, Du kannst damit leben.

verbesserte Rundung.ens.zip

[helmsklamm]

das nenne ich ne antwort:-)

[herw]

das nenne ich ne antwort:-)

heute bin ich gut drauf, ich glaube ich bringe jetzt den Modular dieses Wochenende mal in die Release-Phase.
Sonst noch Fragen

[helmsklamm]

heute bin ich gut drauf, ich glaube ich bringe jetzt den Modular dieses Wochenende mal in die Release-Phase.
Sonst noch Fragen

erst wieder, wenn mir deine unlogischen strukturen anfangen zu nerven;-)

[herw]

heute bin ich gut drauf, ich glaube ich bringe jetzt den Modular dieses Wochenende mal in die Release-Phase.
Sonst noch Fragen

erst wieder, wenn mir deine unlogischen strukturen anfangen zu nerven;-)

wieso unlogisch, alles auf der Basis der Mathematik.
Übrigens habe ich mich nochmals schlau gemacht über das "komische" Rundungsverhalten von NI: Es ist in der Tat korrekt implementiert, da es sich an der Standard IEEE 754 hält.
Dort wird tatsächlich das Runden für x.5 so festgelegt, dass zur geraden Zahl gerundet wird. Es gibt offenbar statistische Phänomene, die dies erforderlich machen (vor allem Finanzrechnung, Bankenwesen).
Der Standard schreibt übrigens auch vor, dass noch drei andere Rundungsarten zu implementieren sind: generelles Aufrunden, generelles Abrunden und Runden gegen Null.
Der oben angegebene Wikipedia-Artikel ist sehr interessant, da er all die Fehler- und Implementierungsmöglichkeiten auflistet - zwar ein trockener Stoff aber bei Bedarf gut zum Nachschlagen.
Leider verschweigt dies NI und spricht im Handbuch nur von einem "unbestimmten" Ergebnis.

ciao herw

[helmsklamm]

aja, das stets zur geraden zahl hin gerundet wird, hat ja ne logik. ob das für schaltungen nun die bste wahl ist, wage ich aber anzuzweifeln. ein generelles aufrunden (von mir aus auch abrunden, hauptsache GENERELL) wäre sicherlich sinnvoller. ausserdem verstehe ich die handbuchlogik, dieses zu verschweigen, nicht.

zur dir unterstellten unlogik - das war natürlich ein scherz.

[herw]

aja, das stets zur geraden zahl hin gerundet wird, hat ja ne logik. ob das für schaltungen nun die bste wahl ist, wage ich aber anzuzweifeln. ein generelles aufrunden (von mir aus auch abrunden, hauptsache GENERELL) wäre sicherlich sinnvoller. ausserdem verstehe ich die handbuchlogik, dieses zu verschweigen, nicht.

zur dir unterstellten unlogik - das war natürlich ein scherz.

weiß ich doch (mittlerweile).
Übrigens steht in dieser IEEE-Norm auch, dass eine Programmiersprache (und das ist ja REAKTOR in gewisser Weise auch) alle Arten der Rundung zur Verfügung stellen muss:

• Runden nach IEEE 754: bei gleichem Abstand zu den benachbarten ganzen Zahlen immer zur geraden Zahl
• Runden gegen Plus-Unendlich
• Runden gegen Minus-Unendlich
• Runden gegen Null (Betrag wird verkleinert).
  Mir fällt dann noch das "normale" mathematische Runden ein (Auf- und Abrunden wie in der Schule), wie Du es Dir wünschtest.
  
  Ich werde mich mal dran setzen und alle Formen bereitstellen; irgendwie und irgendwann braucht man diese Elementarfunktion ja doch.
  Ich habe übrigens schon eine kleine Sammlund in die User-Library hochgeladen: FUNCTIONS (core)
  
  ciao herw