PureBoard

Hier noch eine Version, die eigentlich recht fix und bugfrei sein sollte:

Hallo und vielen Dank. Warum ich den ganzen Thread überhaupt eröffnet hatte, ist genau gesagt folgendes Problem: Wenn z.B. das Ergebnis x den Wert 12.23 hat und ich dieses Ergebnis im Textgadget dartstellen will, dann gibt mir StrF(x) das Ergebnis mit sechs Nachkommastellen wieder statt mit zwei: Ich finde das SEHR ärgerlich und da bin ich auf keinen Fall der einzige. Klar, wenn x NUR Ergebnisse mit zwei Nachkommastellen liefert, kann ich einfach StrF(x,2) einstellen, aber mein Programm bildet für x nunmal laufend verschiedene Ergebnisse mit 0 bis 4 Nachkommastellen, und nicht mehr und nicht weniger erwarte ich dann auch mit StrF(x), denn es kann ja wohl nicht Kult sein, wie StrF arbeitet. Es bleibt also zu hoffen, daß die Entwickler von PB auch in diesem Forum mitlesen und deren Produkte verbessern.

PB42

nun ja, aber im endeffekt sind deine ergebnisse IMMER auf 4 nachkommastellen genau,
also wäre es sowieso die 'mathematischere' lösung, sie immer mit StrF(x,4) zu ermitteln.

die hinteren nullen sind keinesfalls überflüssig, sondern geben an, daß dein ergebnis eben so genau ist.

wenn du 1,2 schreibst, kann das auch 1,2035 sein, aber 1,2000 ist genau 1,2000

Desweiteren willst du ja eventuell auch genau 1.20 ausgeben und nicht 1.2 - denke nur einmal an die Währungsformatierung (obwohl ich hier selbstverständlich niemals Floats verwenden würde), Listenausgaben mit rechtsbündigem Text und dergleichen wo eben die exakte Ausgabe mit abschließenden Nullen erwünscht ist.

Völlig richtig, Kaeru Gaman, aber heutzutage ist man es einfach gewöhnt, daß ein Ergebnis von z.B. 15,1 wirklich genau ist und man nicht zur eigenen Zufriedenheit 15,10000 sehen will. Mir geht das jedenfalls so. Str(x,4) hatte ich schon eingestellt, klar, aber in meinen Augen ist das ein Kompromiß. Ich muß mich halt daran gewöhnen.

PB42

nun, was man gewöhnt ist, und was mathematisch korrekt ist, ist nicht immer das gleiche.

auch im hinblick auf FDs einwand:
grundsätzlich scheint mir eine einheitliche formatierung der regelfall zu sein,
eine solche anwendung, wie du sie möchtest, eben eher die ausnahme.
(ich selbst habe es noch nie gebraucht, in über 20 jahren)

insofern gilt wie üblich: besondere lösungen muss man selber coden.

der code von frogger ist da wirklich schick, aber auch alleine solltest du das coden können,
daß dir ne routine die endnullen von nem string abschneidet...

Hallo freedimension, was würdest Du denn statt Floatzahlen nehmen, um z.B. Währungsformatierung darzustellen?

PB42

darf ich auch antworten?

nun, eben ganzzahlen, nur eben um cents zu berechnen, keine euros,
für die darstellung wird dann das komma eingefügt.
(das verfahren nennt man fixkomma, eben in gegensatz zu fließkomma (float))

es ist übrigens IMMER die bessere lösung, mit fixkomma zu arbeiten,
wenn man fixkomma hat, eben weil es genauer ist als float.

Hallo Kaeru Gaman, ich hab mir in der Tat ne eigene Routine gecodet, welche zuverlässig die unschicken Nachkomma-Nullen so abschneidet, wie ich das will, aber ... die klappt nur bei Zahlen bis xxx.1234 ... Sobald ich auf Zahlen wie xxxy.1234 wechsle, geht das nämlich nicht mehr und das liegt dann wohl wieder an diesen vier Bytes. Aber wie schon gesagt: Auch ich gewöhne mich nun langsam daran, daß die Egebnisse in meiner Anwendung immer mit vier Nachkommastellen ausgewiesen werden, auch ganze Zahlen wie 12.0000

PB42

Fixkomma ist ein gutes Stichwort, aber wenn ich mit Kommazahlen arbeiten will, weiß ich keine andere Möglichkeit als xyz.f, unf zack bin ich wieder bei den Floatzahlen.

PB42