Es gab schon mal als spontane Idee einen Beitrag von mir (Beitrag "Festkommazahlen in Würde") zum Thema Festkommazahlen in C++. Nachdem ich das inzwischen tatsächlich nutze, etwas aufgebohrt habe und vermutlich in Zukunft noch mehr dran frisieren werde, gehört es eher hierher in die Codesammlung. Der jeweils aktuelle Stand ist immer unter http://mfgkw.dyndns.org/fixpoint_release.zip zu finden. Verriss oder konstruktive Kritik gerne an mich. Ich werde in diesem Thread bei markanten Änderungen kurz Bescheid geben und bei Gelegenheit mal Vergleiche von verschiedenen Rechnern zeigen. Seit der ersten Vorstellung in Beitrag "Festkommazahlen in Würde" hat sich vor allem geändert: - etliche Fehler beseitigt - unnötige Überläufe eliminiert - std::numeric_limits<> für das template implementiert - eine Debugvariante eingebaut, mit der man vor Wertebereichsüberläufen gewarnt wird und zum Schluß den kleinsten und größten insgesamt genutzten Wert erfragen kann - eine Debugvariante eingebaut, die alle Berechnungen parallel in double nochmal macht und dadurch einen Vergleich ermöglicht (in einer fixpoint-Variable steckt dann auch eine double drin, mit einem Wert als wenn alles bisherige in double gerechnet worden wäre) - sin() und cos() eingebaut (mit double-Berechnung als default, und der Möglichkeit, per Zusatzprogramm Quelltext zu erzeugen für eine Spezialisierung mit Interpolation in Tabellen, ohne double, mit wählbarer Stützweite) Die Debugvarianten machen den Quelltext in der Headerdatei nicht gerade lesbarer, sind aber sehr hilfreich, um Fehler durch Über- oder Unterläufe zu erkennen. Andere Funktionen aus <cmath> kommen erst bei Bedarf dazu. mfgkw
- das intern verwendete itoa ist jetzt thread safe (bisher statischer Puffer) - der generische cos() heißt jetzt auch so; bisher hieß er dummerweise ebenfalls sin() - falls DEBUG_FIXPOINT_CHECK_RANGE gesetzt ist, gibt es jetzt zwei statische Methoden, die den Kleinst- und Größtwert des Typs als double liefern: static double checkRangeMinLimit() static double checkRangeMaxLimit() (damit kann man nach der Rechnerei die Werte von checkRangeMin bzw. checkRangeMax vergleichen)
- für AVR kann man jetzt auch wieder kompilieren, das war verloren gegangen weil beim avr-gcc/g++ keine <limits> dabei ist ebensowenig wie <cmath>. Die habe ich jetzt frei dazu erfunden. @Blockwart :-) : Macht es nicht Sinn, die auf Dauer zu avr-libc gleich mit dazu zu packen? Ok, viele Leute nehmen nicht gerade C++ hier, aber manchmal wäre es schon nett, wenn man die AVRs gleich behandeln könnte wie andere Rechner. Resourcen kostet <limits> ja nicht, es sind nur etwas kompliziert geschriebene Konstanten.
Klaus Wachtler schrieb: > @Blockwart :-) : Macht es nicht Sinn, die auf Dauer zu avr-libc gleich > mit dazu zu packen? Ok, viele Leute nehmen nicht gerade C++ hier, aber > manchmal wäre es schon nett, wenn man die AVRs gleich behandeln könnte > wie andere Rechner. Am sinnvollsten wäre es natürlich gleich eine komplette libstdc++ für AVRs anzulegen ;-) Da es aber viel Aufwand ist und man viele Teile daraus auch gar nicht für AVRs verwenden will (wie zum Beispiel Exceptions) hat bisher noch keiner Lust dazu gehabt (mich eingeschloßen). Vielen würde aber vermutlich auch schon eine einfachste Implementierung helfen, mit ein paar wichtigen Header-Dateien, Wrappern für new/delete auf malloc/free, default-Handler für pure-virtual Aufrufe usw. Bis dahin könnte ich auch noch einige C++ Header-Dateien beitragen: http://sourceforge.net/apps/trac/xpcc/browser/trunk/src/stdc%2B%2B Die machen nicht mehr als Funktionen aus der avr-libc in den std-Namespace zu verschieben, auch hier, damit man Programme für PC und AVR compilieren kann. Gruß Fabian
Schön, daß es hier noch Mitstreiter gibt! Nur mein cmath hätte ich mir dann natürlich auch sparen können :-)
Aktualisierung: - es gibt bereits seit einiger Zeit ein Hilfsprogramm generate_sin_table. Das erzeugt C++-Quelltext mit einer Spezialisierung von cos() für eine gewünschte Kombination der template-Parameter (der cos() ist über den sin() definiert und verwendet damit ebenfalls die Spezialisierung). Dieses Hilfsprogramm ist leicht korrigiert; es fehlte ein #include <stdint.h> - http://mfgkw.dyndns.org/fixpoint_release.zip ist wieder erreichbar (war versehentlich verschwunden)
Ich habe noch eine Kopie und erlaube mir, diese hochzuladen. Ich kann jedoch nicht garantieren, dass dieses Archiv dem Original entspricht (musste das Archiv neu erstellen).
:
Bearbeitet durch User
> Der Link ist futsch! Nachdem dyndns nicht mehr mein Freund ist, gilt in Zukunft folgender Link: http://www.wachtler.de/fixpoint_release.zip Hier werde ich in Zukunft ggf. Änderungen einpflegen. > Ich habe noch eine Kopie und erlaube mir, diese hochzuladen. Danke für die schnelle Hilfe! mfgkw
:
Bearbeitet durch User
Klaus Wachtler schrieb: > Hier werde ich in Zukunft ggf. Änderungen einpflegen. Spricht etwas gegen das hisiege SVN? Dann könnte man auch Änderungen leichter nachverfolgen.
Läubi .. schrieb: > Klaus Wachtler schrieb: >> Hier werde ich in Zukunft ggf. Änderungen einpflegen. > > Spricht etwas gegen das hisiege SVN? Dann könnte man auch Änderungen > leichter nachverfolgen. Eigentlich nichts, außer daß ich es bereits in meinem svn habe und die Änderungen dort sehe :-) Eigentlich könnte ich alle Änderungen auch in eine anderes svn replizieren. Momentan bin ich aber überfordert mit der Vorstellung, was mit Änderungen dritter in eurem svn dann passiert.
PS: alle Änderungen (zumindest meine) stehen natürlich im Quelltext, also primär in fixpoint.h hinter "// History: ...".
Klaus Wachtler schrieb: > Momentan bin ich aber überfordert mit der Vorstellung, was mit > Änderungen dritter in eurem svn dann passiert Du könntest das "fremde" SVN als Branch in deinem lokalem SVN halten, so kannst du Änderungen auf dem Branch in deinen trunk mergen und umgekehrt.
So, nach einigen Rechner-, Firmen- und privaten Umzügen muß ich meinen ganzen Rechnerkram endlich neu sortieren. Meine letzen Änderungen an der fixpoint-Geschichte waren vom 10. Juli 2015. Dieser Stand ist jetzt wieder unter http://www.wachtler.de/fixpoint_release.zip zu finden. Die ganze Sache ist nicht eingeschlafen, ich brauche es demnächst selber wieder und rücke dann auch neue Stände raus, wenn sich was ändert. Die nächste Änderung wird sein, den etwas größeren Datentyp für Zwischenergebnisse (z.B. uint16_t, um zwei uint8_t zu multiplizieren) automatisch zu finden, anstatt ihn im template explizit angeben zu müssen. Dann wird sich die Struktur etwas ändern (Tests getrennt halten bspw.). Danach probiere ich das alles auch mal auf stm32 und werde ein paar Anpassungen an aktuellere C++-Entwicklungen machen.
Läubi .. schrieb: > Klaus Wachtler schrieb: >> Momentan bin ich aber überfordert mit der Vorstellung, was mit >> Änderungen dritter in eurem svn dann passiert > > Du könntest das "fremde" SVN als Branch in deinem lokalem SVN halten, so > kannst du Änderungen auf dem Branch in deinen trunk mergen und > umgekehrt. Die Frage ist natürlich erstmal, ob überhaupt jemand daran mit gestalten will. Falls nicht, geht es für mich auf meinem Server leichter. Ggf. kann aber jemand anders auch über meinen Server gehen, insofern warte ich erstmal überhaupt Bedarf besteht das in ein mikrocontroller.net-svn zu schieben. Ist das öffentlich? Oder wie kommt man da ran?
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.