Forum: Digitale Signalverarbeitung / DSP / Machine Learning Sinusimplementierung nach Cody und Waite


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Hotte (Gast)


Lesenswert?

In diesem Dokument von AD:
https://www.analog.com/en/technical-articles/an-almost-pure-dds-sine-wave-tone-generator.html

findet sich ein Hinweis auf eine Sinus-Implementierung in Form einer 
iterativen Schleife bei denen nur X*X verwendet wird und in der auf 
sogenannte Koeffizienten von "Cody and Waite" verwiesen wird. Leider ist 
nirgendwas konkretes dazu zu finden. Laut der angegebenen Formel gibt es 
wohl deren 7. Was man vereinzelt im Netz findet, ist ein Kontrukt mit 3 
Werten.

Kennt das jemand?

von foobar (Gast)


Lesenswert?

Erstes Google-Ergebnis für "sine minimax polynomials" gibt:
  https://gist.github.com/publik-void/067f7f2fef32dbe5c27d6e215f824c91

von Hotte (Gast)


Lesenswert?

Ok, sehr interessant. Das hatte ich noch nicht gefunden. Es scheint aber 
in die richtige Richtung zu gehen. Ich sehe nur nicht die Equivalenz zu 
den o.g. Parametern. Ich nehme an, es müsste etwas im Bereich "degree 7" 
oder "degree 15" sein. Den Grafiken zufolge passt der ausgewiesene 
Fehler aber ungefähr zu der Aussage, dass "ab der 15. Potenz der Fehler 
< 1/32 Bit ist".

Das Verfahren finde ich sehr interessant. Die Methode war mir bisher 
gänzlich unbekannt. Man braucht aber offenbar einen Real-Wert mit einer 
Auflösung von 30 Stellen. Nichts für kleine Prozessoren.

von Grummler (Gast)


Lesenswert?

Hotte schrieb:

> Ok, sehr interessant. Das hatte ich noch nicht gefunden.
> Es scheint aber in die richtige Richtung zu gehen. Ich
> sehe nur nicht die Equivalenz zu den o.g. Parametern. Ich
> nehme an, es müsste etwas im Bereich "degree 7"

Nee.


> oder "degree 15" sein.

Ja.
Das Polynom hat 7 Koeffizienten und geht in X^2, das macht Grad
14, und der Faktor X davor gibt Grad 15.


> Den Grafiken zufolge passt der ausgewiesene Fehler aber
> ungefähr zu der Aussage, dass "ab der 15. Potenz der Fehler
> < 1/32 Bit ist".

???

2^31 ist ungefähr 10^9; der Maximalfehler der Näherung liegt
aber bei 10^-14, ist also DEUTLICH besser.


> Das Verfahren finde ich sehr interessant. Die Methode war
> mir bisher gänzlich unbekannt. Man braucht aber offenbar
> einen Real-Wert mit einer Auflösung von 30 Stellen.

Ja... BINÄR-Stellen.

Von nix kommt nix. Wer 32Bit-Ergebnisse will, muss auch
mindestens 32Bit-Koeffizienten verwenden.

von W.S. (Gast)


Lesenswert?

Hotte schrieb:
> ...findet sich ein Hinweis auf eine Sinus-Implementierung...

Das sieht eher danach aus, als ob jemand verzweifelt nach einer Methode 
gesucht hat, um sowas in ein FPGA zu quetschen. Viele Grafiken und immer 
wieder der Versuch, den entstandenen Fehler klein zu reden. Nun ja, man 
bemüht sich, so gut es die Verhältnisse zulassen.

Aber das Thema hatten wir hier vor ein paar Jahren schon mal. Und wir 
sind hier nicht bei den FPGA's, sondern bei den Signalprozessoren. Such 
mal nach "Sinus nach Pedersen".
1
sin(x) = x * (K*x^2 + L + M/(x^2 + N))
2
mit
3
K=0.15625
4
L=-11.45242628
5
M = 480.1488517
6
N=38.55864669
kostet nur 3 Multiplikationen und 1 Division.
Es ist offenbar so, daß niemand die Suchfunktion dieses Forums benutzt 
und deshalb immer wieder die bereits gelösten Probleme nach Jahren 
wieder auftauchen.

W.S.

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

W.S. schrieb:
> Das sieht eher danach aus, als ob jemand verzweifelt nach einer Methode
> gesucht hat, um sowas in ein FPGA zu quetschen.
Beim Github, oder dem TE? Also hier lese ich eher heraus, dass es um 
eine Implementierung geht, die auch einem Sparprozessor läuft. Der 
Pedersen ist für einen FPGA schon mal nicht so gut :-)

Generell muss man sich die Frage stellen, wie genau man einen Sinus 
überhaupt braucht, wenn man Daten damit bearbeiten will. Das Papier tut 
das ja auch und schränkt ein, dass der spätere ADC das Problem sein 
wird, die 50 Stellen hinter dem Komma über die DDS zu transportieren.

Für Taschenrechner und Mathematikprogramme ist es aber unerlässlich, 
sehr genau zu arbeiten und solche Lösungen zu haben.

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

Hotte schrieb:
> Die Methode war mir bisher gänzlich unbekannt.
Ich erinnere mich noch ganz dunkel an das dort erwähnte ->Horner-Schema. 
Das hatten wir irgendwann mal in der Schule - aber ohne es nachzulesen, 
könnte ich es jetzt auch nicht mehr reproduzieren. Ich erkenne aber in 
der iterativen Entwicklung Ähnlichkeiten zu meinem Sinusgenerator auf 
der Basis von Quadrat-Funktionen, die ich in meinem Synth benutze, womit 
wir doch beim FPGA wären:

Man bildet für irgendeinen Phasenwert für den ersten Viertelbogen den 
Wert im Quadrat und hat dann einen Pseudosinus, wie hier im Artikel 
Digitale Sinusfunktion. Dann bildet man wieder das Quadrat davon und 
hat automatisch eine Oberwelle, die man skaliert vom ersten Wert 
abziehen kann. Das setzt man matrixartig fort und eliminiert so immer 
wieder die Oberwellen, die das Quadrat gegenüber dem Sinus mitbringt und 
im Weiteren auch die Oberwelle von der Korrekturwelle, die man ja damit 
einschleppt und so fort.

Für den Sinus braucht man dann die ungeraden- und für den Cosinus die 
geraden Werte, muss also einmal mit X multiplizieren. Auch das erkennt 
man in der o.g. Beschreibung, weil einmal noch ein "X1" hinen 
multipliziert wird, wegen "ungerade Funktion" etc.

Die gesamte Mimik kann man dann in einer Tabelle für alle Koeffizienten 
machen und findet so die Summe der Koeffizienten für die X1, X3, X5, X7, 
X9 also die Grundwelle und auch die X3, X9, X15, X21 für die 3. 
Oberwelle und die X5, X15, X25  u.s.w für die 5. Oberwelle, die man 
miteinander verrechnen kann. Interessant dabei ist, dass sich für alle 
N*N der Wert 0 ergibt, sodass die X9, die X25, X49 und die X81 etc 
rausfallen. Beim Cosinus entsprechend X4, X16, X36, X64 usw.

> Man braucht aber offenbar einen Real-Wert mit einer
> Auflösung von 30 Stellen.
Kommt immer auf die Ansprüche an und man kann das auch mit Integer 
machen, wenn man den Koeffizienten entsprechend auflöst. In einem FPGA 
hat man z.B. Bits genug und das sehr hoch aufgelöst ganzzahlig zu 
berechnen.

Man muss das auch nicht so iterativ machen, wie im Paper, sondern kann 
sich darauf beschränken, nur das X immer weiter zu quadrieren und die 
Koeffizienten separat zu multiplizieren und parallel in die Summe zu 
schieben, dann setzt sich der Fehler nicht fort und man braucht auch für 
die kleiner werdenden Anteile der Oberwellen nach oben raus nicht mehr 
so genaue Koeffizienten.

Ich benutze typisch Werte bis zur 23. Oberwelle und muss nur 9 
Multiplikationen machen. Das nähert den Sinus ausreichend gut für 
Audioanwendungen.

Fun Fact:

Die Schwierigkeit, die ich damals hatte, war es zu plausibilisieren. Ich 
hatte die erste Tabelle mit Excel 2003 angefertigt und fand heraus, dass 
es irgendwann Abweichungen zwischen dem hingerechneten und dem "echten" 
Sinus von Excel gab. In einem späteren Office war das dann anders. Da 
bin ich erst drauf gekommen, dass ich offenbar die Grenzen von Excel 
ausgetestet hatte und mein FPGA-Sinus stellenweise schon genauer war. 
Microsoft hatte offenbar in der späteren Version den Sinus-Algo 
ausgetauscht.

Der Sinus im Excel ist vergleichsweise schlecht, muss man sagen. Nutzt 
man viele Perioden von PI kommt der irgendwann nicht mal mehr auf 0.

von Grummler (Gast)


Lesenswert?

W.S. schrieb:

> Das sieht eher danach aus, als ob jemand verzweifelt
> nach einer Methode gesucht hat, um sowas in ein FPGA
> zu quetschen.

???

Was bitte ist an einer Tschebyscheff-Approximation
"verzweifelt"?


> sin(x) = x * (K*x^2 + L + M/(x^2 + N))
> mit
> K=0.15625
> L=-11.45242628
> M = 480.1488517
> N=38.55864669
> kostet nur 3 Multiplikationen und 1 Division.

...und hat den offenkundigen Nachteil, dass man dividieren
muss.

von Hotte (Gast)


Lesenswert?

Grummler schrieb:
> 2^31 ist ungefähr 10^9; der Maximalfehler der Näherung liegt
> aber bei 10^-14, ist also DEUTLICH besser.
Ich hab es nochmals nachgelesen, ja, das Dokument sprucht davon, dass 
die beiden genannten PErsonen nachgewiesen hatten, dass es bis zu e-15 
genau sei. Das passt soweit.

Grummler schrieb:
> Ja... BINÄR-Stellen.
Wieso binär? Die Werte in den Tabellen sind in Dezimal und haben 
teilweise 30 Stellen.

Grummler schrieb:
> ...und hat den offenkundigen Nachteil, dass man dividieren
> muss.
Wäre für meinen Fall eventuell noch tolerabel. Wie genau ist diese 
Funktion? Wie genau müssten die Koeffizienten sein?

von Grummler (Gast)


Lesenswert?

Hotte schrieb:

> Grummler schrieb:
>> 2^31 ist ungefähr 10^9; der Maximalfehler der Näherung
>> liegt aber bei 10^-14, ist also DEUTLICH besser.
>
> Ich hab es nochmals nachgelesen, ja, das Dokument sprucht
> davon, dass die beiden genannten PErsonen nachgewiesen
> hatten, dass es bis zu e-15 genau sei. Das passt soweit.

Ja... vielleicht nochmal kurz zur Erklärung (mich nervt
das name dropping in dem Paper von AD etwas):

1. Basis der ganzen Geschichte ist eine stinknormale
   Polynom-Approximation nach Tschebyscheff.
   (Vorteil: Maximalfehler wird im GESAMTEN INTERVALL
   garantiert nicht überschritten -- Taylor-Entwicklung
   ist im Gegensatz dazu nur im Entwicklungspunkt
   perfekt und wird immer schlechter, je weiter man zu
   den Intervallgrenzen geht.)

2. Die Koeffizienten für das Tschebyscheff-Polynom
   lassen sich mit dem Remez-Algorithmus finden; auf der
   von foobar verlinkten Seite wird das weiter unten
   erwähnt.
   Aus dem AD-Paper lässt sich raten, dass Hart lediglich
   solche Polynome publiziert hat.

3. Worin die Verbesserung von Cody und Waite besteht, ist
   weiterhin unklar.
   In Anbetracht dessen, dass die Formeln auf der von foobar
   verlinkten Seite schon über 40bit Genauigkeit liefert,
   wäre mir das aber auch egal.


> Grummler schrieb:
>> Ja... BINÄR-Stellen.
> Wieso binär? Die Werte in den Tabellen sind in Dezimal
> und haben teilweise 30 Stellen.

Ja klar -- dort werden ja auch Polynome bis zur 33. Ordnung
verglichen, und das hat nur mit entsprechend genauen
Koeffizienten Sinn.

Wenn Du nur ein Polynom 15. Ordnung auf 32Bit genau
auswerten willst, brauchst Du maximal vielleicht 36Bit
oder so für die Koeffizienten.
Cody und White behaupten ja, dass es auch mit 32Bit
langen Koeffizienten klappt -- aber deren Werte sind
vermutlich (auf eine bisher geheime Art und Weise)
handoptimiert.

Kann man im Zweifelsfalle einfach ausprobieren.


> Grummler schrieb:
>> ...und hat den offenkundigen Nachteil, dass man
>> dividieren muss.
>
> Wäre für meinen Fall eventuell noch tolerabel.

Ahh, okay.


> Wie genau ist diese Funktion? Wie genau müssten die
> Koeffizienten sein?

Lies mal den Beitrag von W.S. hier im Thread und traktiere
dann die Suchfunktion; das sollte Dir weiterhelfen. Das
Thema ist vor drei, vier Jahren schonmal diskutiert worden;
ich habe aber keine Einzelheiten mehr parat. Ich müsste
genauso suchen wie Du.

von Hotte (Gast)


Lesenswert?

Vielen Dank für die Erklärungen. Ich suche!

von Alexander S. (alesi)


Lesenswert?

Grummler schrieb:
> Das
> Thema ist vor drei, vier Jahren schonmal diskutiert worden;

Hallo,

Minimax Approximationen mit Polynomen oder rationalen Polynomen, z.B. 
für die arctan Funktion, wurden u.a. in diesen beiden Diskussionen 
besprochen:
Beitrag "Näherung für ArcusTangens?"
Beitrag "64 Bit float Emulator in C, IEEE754 compatibel"

Die Bücher "Computer Approximations" von Hart und "Software Manual for 
the Elementary Functions" von Cody und Waite hätte ich da.

von ... (Gast)


Lesenswert?

> in Form einer  iterativen Schleife bei denen nur X*X verwendet wird

X*X ist schlicht X^2.

Falls einem float reicht, und Mann die Schleife ausrollt:
1
  //
2
  sin =  (((((((( 0.0000027 * x*x )
3
    - 0.0001984 ) * x*x )
4
    + 0.0083333 ) * x*x )
5
    - 0.1666667 ) * x*x ) + 1.0 ) * x;
6
  //

Die Herren Taylor und Horner lassen schoen gruessen :).
Die Genauigkeit (bis 90 Grad) reicht fuer einen 8 stelligen
Milchmaedchentaschenrechner.

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

Alexander S. schrieb:
> Die Bücher "Computer Approximations" von Hart und "Software Manual for
> the Elementary Functions" von Cody und Waite hätte ich da.
Würde mich auch mal interessieren. ISBN?

Was mir zum Thema Genauigkeit noch einfällt:

Die iterativen Algos und Näherungen liefern immer eine dedizierte 
Fehlerfunktion, die man in der Signalstruktur erkennen kann.
Der Fehler wächst meistens zum Definitionsbereichsende hin und die 
Schwingung, die sich beim Durchlauf ergibt, ist relativ niederfrequent 
und hat teilweise Anteile unterhalb der Nutzfrequenz. Auch beim Pedersen 
ist das so, dass sich da eine Schwingung ergibt.

(M)eine binäre quadratische Näherung v.o. liefert aber einen 
statistischen Rundungsfehler, dessen Spektrum weitgehend deutlich 
oberhalb der Nutzfrequenz liegt - also gut gefiltert werden kann, bzw. 
bei Nutzung der Werte in weiteren Rechenschritten nicht zu deutlichen 
Mustern führt, wodurch auch die Endwerte einer solchen Rechnung ein gut 
verteiltes Fehlerspektrum aufweisen.

Bei der Bewertung der Genauigkeit schneidet daher ein Algo, der 
scheinbar nur auf 10 Bit genau ist, erheblich besser ab, als ein 
anderer, der vielleicht auf 16 Bit genau ist, aber eine eindeutige 
Fehlerfrequenz hat. Hinzu kommt, dass die Störfrequenzen bei geschickter 
Wahl der Vektorbreiten bis in hohe Abtastfrequenzen und Nutzfrequenzen 
hinein ganzzahlige binäre Vielfache sind und damit der musikalisch 
unproblematisch n-ten Oktave liegen.

von Jürgen S. (engineer) Benutzerseite


Angehängte Dateien:

Lesenswert?

Hotte schrieb:
> Wie genau ist diese Funktion?
Siehe Bild: Der Fehler ist von -PI ... PI  und  -PI/2 ... +PI/2 
aufgetragen.

Genau da muss man aufpassen: Ein Kollege hatte mal so einen drin und 
sich
über die peaks gewundert, die im Signal steckten. Die kamen von den 
Rändern.
Man darf den nur für 2 der 4 Viertelbögen nutzen. Da ist er auf 
1/100.000 bei 0.5 digit genau. Das Ungünstige ist halt die Division. Die 
muss auf Ganzzahlmaschinen wie im FPGA sehr hoch aufgelöst in RADIX 2 
laufen.

Mit CORDIC für die DIV ist nix zu wollen,  weil man dann besser den 
Sinus direkt nimmt.

von Alexander S. (alesi)


Lesenswert?

Jürgen S. schrieb:
> Würde mich auch mal interessieren. ISBN?

Computer approximations
https://www.worldcat.org/title/841853758
Es gibt auch noch einen Nachdruck von 1978, siehe "View all formats and 
editions".

Software manual for the elementary functions
https://www.worldcat.org/title/6250863

Die Bücher gibt es aber nur noch im Antiquariat.

von Hp M. (nachtmix)


Lesenswert?

Alexander S. schrieb:
> Die Bücher gibt es aber nur noch im Antiquariat.

Es wird genug andere Bücher geben, wo das auch drin steht:
https://epdf.tips/search/Computer+approximations

Alles frei herunterladbar!

von Alexander S. (alesi)


Lesenswert?

Hp M. schrieb:
> Es wird genug andere Bücher geben, wo das auch drin steht:
> https://epdf.tips/search/Computer+approximations
>
> Alles frei herunterladbar!

Das sagt sich leicht. Je spezifischer, und insbesondere älter, die 
Information ist, die man sucht, desto schwieriger ist es dazu freie 
Quellen im Internet zu finden. In welchem der pdfs auf https://epdf.tips 
findet man denn z.B. die Koeffizienten für die rationale Minimax 
Approximation für den arctan mit einer Genauigkeit von 22 
Dezimalstellen?
Ich kenne nur Internetquellen mit Programmbeispielen, wo einige wenige 
der Koeffezienten aus dem Buch verwendet werden.

von Hotte (Gast)


Lesenswert?

Jürgen S. schrieb:
> Man darf den nur für 2 der 4 Viertelbögen nutzen. Da ist er auf
> 1/100.000 bei 0.5 digit genau.
Das wäre super!

... schrieb:
> Falls einem float reicht, und Mann die Schleife ausrollt:
>   //
>   sin =  (((((((( 0.0000027 * x*x )
>     - 0.0001984 ) * x*x )
>     + 0.0083333 ) * x*x )
>     - 0.1666667 ) * x*x ) + 1.0 ) * x;
>   //
Das wäre mir auch sehr symphatisch. Wie genau ist der?

Ich nehme an, die dort eingesetzten Zahlen können sinnvoll fortgesetzt 
werden, also die 0.166xxxx um höhere Genauigkeit zu erlangen?
Die 0.xxx27 sind genau?

von Christoph db1uq K. (christoph_kessler)


Angehängte Dateien:

Lesenswert?

Das Buch ist bei epdf vorhanden. Nach Anklicken von Ampeln oder Hügeln 
darf man 10,8 MB herunterladen. 279 Seiten ISBN 9780138220648
Hier die Seiten zu sin/cos
Mit Beispielprogramm in Fortran, man sieht quasi die einzelnen 
Lochkarten.
Musste ich auch noch lernen 1976.

: Bearbeitet durch User
von ... (Gast)


Lesenswert?

> Wie genau ist der?

Fuer die 7 dezimalen Nachkommastellen eines einfachen
Taschenrechners reicht es. Bei 90 Grad gibt es ein wenig Abweichung.

> können sinnvoll fortgesetzt werden

> Die Herren Taylor [x]
> und Horner lassen schoen gruessen

Ich dachte der Hinweis reicht. Es sind die Koeffizienten
der Taylorapproximation. (1/(2n+1)! ... 1/3! 1/5! ...)

Ja, das ganze laesst sich sicher noch aufbohren.
Fuer float lohnt das aber schon nicht mehr.
Mir hat es so wie es ist, im allgemeinen gereicht.
Damit der Compiler auch wirklich "float" benutzt,
muss man gehoerig aufpassen :).
Das Beispiel laesst das aus.

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

... schrieb:
>> Wie genau ist der?
>
> Fuer die 7 dezimalen Nachkommastellen eines einfachen
> Taschenrechners reicht es. Bei 90 Grad gibt es ein wenig Abweichung.

Das ist eine von denen Funktionen, die die unangenehme Eigenschaft 
haben, nach "hinten" raus gegen 2*PI immer ungenauer zu werden. Man kann 
sich helfen, wenn man nur den ersten Viertelbogen nimmt und dort 
umklappt. Gibt aber trotzdem einen Knick.

von Walter T. (nicolas)


Lesenswert?

À propos 2*PI: Gibt es eigentlich gebräuchliche Sinus-Funktionen, die 
nicht im Grad- oder Bogenmass sind? (Ich denke an so etwas wie dezimale 
Perioden.)

Bei meinen Anwendungen wird gefühlt immer mit 2*PI skaliert, weil die 
Periodendauern ja meistens einen rationalen Zeitbezug zum Prozessortakt 
haben, und der einzige Teil, wo ich verstehe, dass der Bezug auf 2*PI 
einen Sinn hat, ist die Näherung für kleine Winkel.

: Bearbeitet durch User
von ... (Gast)


Lesenswert?

> nur den ersten Viertelbogen nimmt

Bei 90 Grad (PI/2) sollte man aufhoeren und dann die Periodiziaet
nutzen. Wenn "zufaelligerweise" :) die erste Ableitung des
nimerischen Polynoms bei 90 Grad zu Null wird, gibt es logischerweise
auch keinen Knick. Eigentlich sollte das so sein.
Und wenn nicht, kann man ja nachhelfen.

Ich wuesste keinen vitalen Grund, warum man die ganze Periode
approximieren sollte oder wollte. Ausser es ist eine immanente
Eigenschaft der Approximationsfunktion. Polynome zaehlen wohl
mit Sicherheit nicht dazu.

> gebräuchliche Sinus-Funktionen
Neben Deg und Rad kennen Taschenrechner auch Grad.
360 Deg := 400 Grad. Sicher sehr nuetzlich wenn der einzige
vorhandene Winkelmesser diese Teilung hat :).

von Hp M. (nachtmix)


Lesenswert?

Walter T. schrieb:
> À propos 2*PI: Gibt es eigentlich gebräuchliche Sinus-Funktionen, die
> nicht im Grad- oder Bogenmass sind? (Ich denke an so etwas wie dezimale
> Perioden.)

Na klar: 
https://de.wikipedia.org/wiki/Strich_(Winkeleinheit)#Der_artilleristische_Strich

von PicoUser (Gast)


Lesenswert?

Vollwinkel (τ für turn/(Um)Drehung) ist gebräuchlich für Festkomma und 
herstellerspezifische Erweiterungen wie sinpi(), cospif(), usw.
https://de.wikipedia.org/wiki/Vollwinkel

von Walter T. (nicolas)


Lesenswert?

PicoUser schrieb:
> Vollwinkel (τ für turn/(Um)Drehung) ist gebräuchlich

Danke, das ist ergiebig.

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

... schrieb:
> bei 90 Grad zu Null wird, gibt es logischerweise
> auch keinen Knick. Eigentlich sollte das so sein.
Bei der ganz oben genannten Approx könnte das so sein, ja - habe die 
Fehlerfunktion nicht mehr ganz vor Augen, aber die pendelte ja um Null.

Bei der zuletzt (von dir ?) genannten Funktion ergibt sich aber eine 
Fehlerfunktion die kontinuierlich mehr Abweichung liefert, damit gibt es 
automatisch einen Knick. Und selbst wenn es nicht die erste ABL trifft, 
taucht es spätestens bei der 2. auf und damit wird es mitunter giftig 
bei der Lösung von DGLs.

... schrieb:
> 360 Deg := 400 Grad.
Waren das nicht diese "GON" oder wie die hießen? Ich habe das mal in den 
90ern für den Amiga genutzt, weil sich das sehr gut in 100% und binäre 
Vielfache aufteilen ließ. Aber sonst habe ich die nicht benötigt.

Was man in jedem Fall braucht, ist die Skalierung auf 0 ... 2PI und -PI 
... +PI sowie von 0 ... 1, damit man sie gut (= bitgenau !) in das 
lokale INT-System der vorliegenden Rechnung übersetzen kann. Davon 
ausgehend habe ich mir Sinüsse für 32-Bit Binärphasen mit bitgenauer 
Skalierung geschrieben - sowie eine, die mit 1.0 = 232792560 
funktioniert.

Die erste habe ich mal gegen eine identisch formulierte von Mathworks 
antreten lassen, die sehr interessante Ergebnisse liefert (Simulink 
Blockset), welches sich ihrerseits von der Implementierung durch Xilinx 
unterscheidet, was beides für sich etwas verwundert.

Die zweite Zahl stelle ich mal zur Diskussion.

von W.S. (Gast)


Lesenswert?

... schrieb:
> Ich wuesste keinen vitalen Grund, warum man die ganze Periode
> approximieren sollte oder wollte.

Es gibt auch keinen. Die Symmetrie-Eigenschaften sind bekannt und da man 
durch schieres Zurückführen auf den ersten Quadranten 2 Bit an 
Genauigkeit gewinnen kann, ohne dafür nur einen Finger bei der 
eigentlichen Approximation zu rühren, dann ist das quasi ein Geschenk.

W.S.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.