Vorsicht Falle (Rechengenauigkeit)

Warum funktioniert ein bestimmtes Modul nicht so, wie man es sich vorstellt? Hier kann man Dampf ablassen.

Moderator: herw

Vorsicht Falle (Rechengenauigkeit)

Beitragvon herw » So 9. Feb 2014, 10:57

Manchmal stolpert man über Sachen, die glaubt man nicht:
Ganz harmlos habe ich mal nested loops in Max Zaglers partials framework ausprobiert:
nested loops 1.jpg
nested loops 1.jpg (106.37 KiB) 1413-mal betrachtet

Die äußere Schleife läuft mit der Schrittweite 1 von n=2 bis 4. Die innere Schleife wiederholt den Wert n und fügt Additionen hinzu. Die Abbruchbedingung lautet, dass n+0.6 nicht erreicht werden soll.
Also erwarte ich 2 2 2.2 2.4 3 3 3.2 3.4 4 4 4.2 4.4.
Doch was muss ich erblicken?
nested loops 2.jpg
nested loops 2.jpg (123.16 KiB) 1413-mal betrachtet

Es wird zusätzlich der Wert 4.6 angezeigt. Was soll das denn?
Nach langem Nachdenken und rumprobieren kam mir die Fundgrube in den Sinn: Dezimaldarstellung -> 32 bit Fließkommazahl.
Da war doch was mit der Rechengenauigkeit; also mal ein kleiner harmloser Test:
dreimal 0.2 addiert und mit dem direkten Wert verglichen: und siehe da, die Summe ist größer als 3.6, also Abbruch!
nested loops 3.jpg
nested loops 3.jpg (46.24 KiB) 1413-mal betrachtet

dreimal 0.2 addiert und mit dem direkten Wert verglichen: und siehe da die Summe ist kleiner als 4.6, also noch kein Abbruch!
nested loops 4.jpg
nested loops 4.jpg (43.67 KiB) 1413-mal betrachtet

arrggh! darauf muss man erstmal kommen. Was ist die Konsequenz: loops grundsätzlich mit integer-Werten und erst dann für die Ausgabe eine Umrechnung:
nested loops 5.jpg
nested loops 5.jpg (214.03 KiB) 1413-mal betrachtet


ciao herw
Benutzeravatar
herw
moderator
 
Beiträge: 2964
Registriert: Mo 13. Mär 2006, 18:28
Wohnort: Dortmund

Re: Vorsicht Falle (Rechengenauigkeit)

Beitragvon Thala » Mi 24. Mai 2017, 09:13

danke herw.
da ich gerne in core arbeite, bin ich auch schon ein paar mal ueber rechen ungenauigkeiten gestolpert.
und jedes mal kostet es stunden,
bis man sich erinnert:
da war doch was mit 64bit.

eigentlich ziemlich peinlich, wenn reaktor es mit 32bit nicht schafft 1 und 1 zusammen zu zaehlen. oder eine simple null als e hoch minus irgendwas darstellt. scheint wohl in der floating point natur zu liegen :(
Thala
synthesist
 
Beiträge: 77
Registriert: Do 1. Okt 2015, 14:36

Re: Vorsicht Falle (Rechengenauigkeit)

Beitragvon herw » Do 8. Jun 2017, 13:42

Thala hat geschrieben:danke herw.
da ich gerne in core arbeite, bin ich auch schon ein paar mal ueber rechen ungenauigkeiten gestolpert.
und jedes mal kostet es stunden,
bis man sich erinnert:
da war doch was mit 64bit.

eigentlich ziemlich peinlich, wenn reaktor es mit 32bit nicht schafft 1 und 1 zusammen zu zaehlen. oder eine simple null als e hoch minus irgendwas darstellt. scheint wohl in der floating point natur zu liegen :(
ja klar,denn es werden nur wenige Stellen für die Mantisse benutzt. Unabhängig davon, nimmt die Dichte der Gleitkommazahlen mit deren Größe ab:
Gleitkommazahlen.
ciao herw
Benutzeravatar
herw
moderator
 
Beiträge: 2964
Registriert: Mo 13. Mär 2006, 18:28
Wohnort: Dortmund

Re: Vorsicht Falle (Rechengenauigkeit)

Beitragvon Eventmanager » Mo 12. Jun 2017, 10:43

Ebenso blöd wie N,5 dass bei Quantizierung mal Auflösung zum nächsthöheren Wert, mal Abrundung bedeutet. Warum einigt man sich nicht endlich darauf, das n,5 in der Quantizierung unzulässig ist? 4:8 darf als Quantizierungs-Wert nicht 0.5 ergeben. Irgendwas unendlich nah dran, aber eben klar definiert zur 0.49999... - oder 0.50000...1 Seite, (dieser Offset wird hinterher selbstredend wieder da zu addiert, aber in den Q-Modulens selbst ist 0.5 nicht gestattet!.)
Man sollte doch wohl eine Lösung finden, die jenseits von Beliebigkeit, alle zu fFreiden stellt. Wreckmeisters wohltemperiertes 12-Ton-System ist auch nicht korrekt,a ebr wir haben uns drauf geeignigt und leben eigentlich ganz damit!

Wenn ich eben nur die Wahl zwischen Ungenauigkeit und Beliebigkeit habe, ziehe ich Ungenauigkeit vor!
Eventmanager
meister
 
Beiträge: 156
Registriert: Di 25. Jun 2013, 15:26

Re: Vorsicht Falle (Rechengenauigkeit)

Beitragvon herw » Mo 12. Jun 2017, 13:44

Eventmanager hat geschrieben:Ebenso blöd wie N,5 dass bei Quantizierung mal Auflösung zum nächsthöheren Wert, mal Abrundung bedeutet. Warum einigt man sich nicht endlich darauf, das n,5 in der Quantizierung unzulässig ist? 4:8 darf als Quantizierungs-Wert nicht 0.5 ergeben. Irgendwas unendlich nah dran, aber eben klar definiert zur 0.49999... - oder 0.50000...1 Seite, (dieser Offset wird hinterher selbstredend wieder da zu addiert, aber in den Q-Modulens selbst ist 0.5 nicht gestattet!.)
Man sollte doch wohl eine Lösung finden, die jenseits von Beliebigkeit, alle zu fFreiden stellt. Wreckmeisters wohltemperiertes 12-Ton-System ist auch nicht korrekt,a ebr wir haben uns drauf geeignigt und leben eigentlich ganz damit!

Wenn ich eben nur die Wahl zwischen Ungenauigkeit und Beliebigkeit habe, ziehe ich Ungenauigkeit vor!
oh da liegst du ganz falsch. Das Auf- und Abrunden bei n,5 ist genau geregelt: IEEE 754. Es wird immer abwechselnd mal auf- und abgerundet. Das ist eine Forderung von Donald E. Knuth, damit es bei längeren Rechnungen nicht zu einer statistischen Drift kommt.
Wenn du die mathematisch übliche Rundung suchst (immer bei n,5 aufrunden), dann schau mal im partials framework nach, bzw. du kannst auch mein Makro benutzen:
mathematisches Runden.jpg
mathematisches Runden.jpg (33.17 KiB) 323-mal betrachtet

Durch die Verdopplung am Anfang des Rechenweges bekommt man genau den Fall, dass aufgerundet wird. Zum Schluss muss wieder halbiert werden.
Benutzeravatar
herw
moderator
 
Beiträge: 2964
Registriert: Mo 13. Mär 2006, 18:28
Wohnort: Dortmund

Re: Vorsicht Falle (Rechengenauigkeit)

Beitragvon Eventmanager » Sa 17. Jun 2017, 10:57

Danke, hab nur R5 aber die Blaupause lässt sich ja im Handumdrehen nachbauen. Frage: Reden wir hier von dem gleichen round?
Bildschirmfoto 2017-06-17 um 11.50.45.jpg
Bildschirmfoto 2017-06-17 um 11.50.45.jpg (30.5 KiB) 310-mal betrachtet
Eventmanager
meister
 
Beiträge: 156
Registriert: Di 25. Jun 2013, 15:26

Re: Vorsicht Falle (Rechengenauigkeit)

Beitragvon herw » Sa 17. Jun 2017, 11:08

Eventmanager hat geschrieben:Danke, hab nur R5 aber die Blaupause lässt sich ja im Handumdrehen nachbauen. Frage: Reden wir hier von dem gleichen round?
Bildschirmfoto 2017-06-17 um 11.50.45.jpg
ja, es besteht nur aus einem float-Eingang und einem integer-Ausgang und hat ansonsten innen nur eine direkte Verbindung.
Benutzeravatar
herw
moderator
 
Beiträge: 2964
Registriert: Mo 13. Mär 2006, 18:28
Wohnort: Dortmund

Re: Vorsicht Falle (Rechengenauigkeit)

Beitragvon Eventmanager » So 18. Jun 2017, 12:41

Aha, also mein "integer-quantizer-"modul"" dass ich aufgrund Kompaktheit der Prim-Alternative vorziehe. Danke nochmal. Im Prinzip ist hier die Quantisierung in den Ein/Ausgang unsichtbar versteckt, oder? Einfach in den Properties den Out auf INT stellen, bedarf doch "intern" einiges mehr, als pures Durchschleifen... Wie überredet man ne Maschine dazu, statt Minuten, Stunden, Tage... nur die Kalenderwoche anzuzeigen?

Jut, grad nachgebaut und 20 mal test-knob auf 0.5 default springen lassen = IMMER 1 :-)))) Sehr schön! Wobei das prim-Quantize dass von haus aus auch schon macht (zumindest keine Abweichung in meine Versuchen. Hm, Zufall oder Implementation???).

Andre Frage: Das erwähnte Partial Framework... was sind hier deine besonderen Highlights (ausser eigentlich ALLES;-).
Ich suche vor allem so kleine, pfiffige Heinzelmännchen, wie eben der "bedingungslose Aufrunder" und so!
(und: gibts das auch für R5?)
Eventmanager
meister
 
Beiträge: 156
Registriert: Di 25. Jun 2013, 15:26

Re: Vorsicht Falle (Rechengenauigkeit)

Beitragvon herw » So 18. Jun 2017, 13:08

Eventmanager hat geschrieben:Aha, also mein "integer-quantizer-"modul"" dass ich aufgrund Kompaktheit der Prim-Alternative vorziehe. Danke nochmal. Im Prinzip ist hier die Quantisierung in den Ein/Ausgang unsichtbar versteckt, oder? Einfach in den Properties den Out auf INT stellen, bedarf doch "intern" einiges mehr, als pures Durchschleifen... Wie überredet man ne Maschine dazu, statt Minuten, Stunden, Tage... nur die Kalenderwoche anzuzeigen?

Jut, grad nachgebaut und 20 mal test-knob auf 0.5 default springen lassen = IMMER 1 :-)))) Sehr schön! Wobei das prim-Quantize dass von haus aus auch schon macht (zumindest keine Abweichung in meine Versuchen. Hm, Zufall oder Implementation???).

Andre Frage: Das erwähnte Partial Framework... was sind hier deine besonderen Highlights (ausser eigentlich ALLES;-).
Ich suche vor allem so kleine, pfiffige Heinzelmännchen, wie eben der "bedingungslose Aufrunder" und so!
(und: gibts das auch für R5?)
partials framework ist in REAKTOR 5 entwickelt worden (und natürlich auch in R6 benutzbar).
Ich benutze hauptsächlich multiplexing und die standard library in core. Dort findest du auch im math-Ordner die verschiedenen Rundungsarten.
::kaffee::
bild 1.jpg
bild 1.jpg (15.82 KiB) 303-mal betrachtet
Benutzeravatar
herw
moderator
 
Beiträge: 2964
Registriert: Mo 13. Mär 2006, 18:28
Wohnort: Dortmund

Re: Vorsicht Falle (Rechengenauigkeit)

Beitragvon Eventmanager » So 18. Jun 2017, 14:11

Ah, danke! Sogar vom "Stephan" höchstselbst gebastelt;-)
Grad gesaugt, Dokumentationen (Plural) sind auch an Bord. So soll´s sein. Vielen Dank nochmal für den Tipp, viellleicht pinnst du den irgendwo als "Must-have", genau wie den ACEW, die FFT und quiitschboys init-tabelle und auch was du so an "universellen" Heinzelmänchen der Welt vermacht hast.... Mir fällt auch noch spontan Paul Rogats HSL/RGB tool, der Bupu-Mapper und so manches von Mike Dalliot ein... Es gibt auch son alles-zu-alles UMRECHNER, schneller und übersichtlicher als jeder OS-Rechner...den hab ich leider irgendwie verschlampt und finde den partout nicht mehr in der UL... /(falls irgendwer weiss was ich meine, bitte Link)

Alles absolut elementare Teile, die an prominenter Stelle in die Factory-Lib gehören...
Eventmanager
meister
 
Beiträge: 156
Registriert: Di 25. Jun 2013, 15:26

Re: Vorsicht Falle (Rechengenauigkeit)

Beitragvon herw » So 18. Jun 2017, 21:12

Eventmanager hat geschrieben:Ah, danke! Sogar vom "Stephan" höchstselbst gebastelt;-)
Grad gesaugt, Dokumentationen (Plural) sind auch an Bord. So soll´s sein. Vielen Dank nochmal für den Tipp, viellleicht pinnst du den irgendwo als "Must-have", genau wie den ACEW, die FFT und quiitschboys init-tabelle und auch was du so an "universellen" Heinzelmänchen der Welt vermacht hast.... Mir fällt auch noch spontan Paul Rogats HSL/RGB tool, der Bupu-Mapper und so manches von Mike Dalliot ein... Es gibt auch son alles-zu-alles UMRECHNER, schneller und übersichtlicher als jeder OS-Rechner...den hab ich leider irgendwie verschlampt und finde den partout nicht mehr in der UL... /(falls irgendwer weiss was ich meine, bitte Link)

Alles absolut elementare Teile, die an prominenter Stelle in die Factory-Lib gehören...
partials framework ist von Max Zagler! Stephan hat es unter seinem Namen veröffentlicht. In meiner library kannst du auch die Version 1.1 herunterladen, dort gibt es kleine Korrekturen.
Als must-have ist es hier schon des öfteren erwähnt worden.
Benutzeravatar
herw
moderator
 
Beiträge: 2964
Registriert: Mo 13. Mär 2006, 18:28
Wohnort: Dortmund


Zurück zu KERNSCHMELZE

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast

cron