Oh, interessant, muß ich ausprobieren.
/ralph
Oh, interessant, muß ich ausprobieren.
/ralph
dc(1) und bc(1) sind etwas beschränkt, Octave ist ein fettes Teil. Gibt es da irgendwas dazwischen?
Wenn ich am PC sitze schieb ich das immer mit:
echo "<numerischer Ausdruck>" | bc -l
rein. Das hat den Vorteil das man das Ergebnis auch sofort in einer weiteren Pipe weiter verarbeiten kann.
Tschau, Jörg (Du bist hier nicht der einzige Nerd, Du! *gg*)
Na guck, man lernt auch nach Jahren noch Neues hinzu. Und ich Trottel hab ich lange damit herum geärgert. Ich wollte gerade ein wenig herum schimpfen dass dass nicht in der Dokumentation steht, aber es steht. :-)
Danke!
Tschau, Jörg
Da die bc -h und dc -h wenig verbose sind, helfen vielleicht die:
Ich meine damit, daß die by default installiert sind und man nicht erst suchen muss.
Gerrit
Ja, stimmt... UPN ist gerne von Flüchen begleitet.
Gerrit
YMMD;-)
Olaf
Hi Hergen,
Vielen Dank für den Tip. Hab gerade nachgeschaut und mal installiert, weil ChampCalc ebenso wie RealCalc auf Tracker verzichtet und auch ohne GooglePlay auskommt. Zwei Dinge, die mir einfach auch was wert sind.
Warum eine der meistbenutzten Tasten (1/x) auf einer second function Taste gelegt wird, bleibt mir unverständlich. Bei RealCalc kann man das leicht in den Settings umstellen. Das habe ich bei ChampCalc nicht gefunden. Dafür kommt die % Taste prominent zum Einsatz, eine Taste, deren Sinn sich mir nie erschlossen hatte.
Was der Hype mit dutzenden von Stellen an Genauigkeit soll, habe ich nie verstanden. Wer braucht sowas eigentlich? Im Alltag begrenzen Modellgenauigkeiten und reale Toleranzen die sinnvollen Auflösungen doch ohnehin nach der vierten oder fünften Stelle. Marte
Am 22.09.25 um 08:28 schrieb Marte Schwarz:
Irgendwas ist halt immer... Tipp: Du kannst die Zweitfunktion auch durch langes Drücken einer Taste erreichen.
Prozentrechnung ist im Alltag doch recht häufig und die %-Taste spart ein paar Tastendrücke. 30+5% sind zwei Tasten weniger als 30*1.05
Bei manchen Berechnungen können Rundungsfehler sehr störend sein und es kann daher nicht schaden, wenn der Taschenrechner ein paar (nicht zwingend angezeigte) Stellen in Reserve hat. Das haben bessere Taschenrechner schon vor Jahrzehnten getan.
Bei modernen Computer-CPUs kommt hinzu, das deren Hardware-Fließkommafunktionen auf Basis von Binärbrüchen arbeiten und damit zwingend immer ungenau sind. Allein die Tatsache, das die Hardwarefunktionen NICHT benutzt werden (sondern irgend eine High-Precision-Methematik-Bibliothek) stellt bereits ein großes Plus dar.
Deine Bank wird sich freuen, wenn du "Toleranzen" beim Kontostand akzeptierst ^_-
Am 22.09.2025 um 08:28 schrieb Marte Schwarz:
[...]
Der Leo - das war jetzt einfach...
Dazu habe ich kürzlich woanders etwas geschrieben:
Die Anzahl der benötigten Stellen hängt von der Anwendung ab. Schockierend, ich weiß.
Bei physikalischen Messungen beschränkt sich die erreichbare Genauigkeit typischerweise auf wenige signifikante Stellen. Dies betrifft die meisten Bereiche der Elektrotechnik, des Maschinenbaus und des Bauingenieurwesens. Es mag einige physikalische Experimente geben, die an die Zehn-Stellen-Grenze alter HP-Taschenrechner stoßen – wie hoch ist die aktuelle Genauigkeit bei der Messung der Erde-Mond-Distanz mittels Laserinterferometrie?
Zählbare Größen sind eine ganz andere Kategorie. Ein naheliegendes Beispiel sind Finanzzahlen. Ich kenne mich zwar nicht mit den Buchhaltungsregeln aus, aber ich denke, egal wie hoch Ihr Kontostand ist, er sollte auf den Dollar (oder Cent?) genau sein und niemals auf Tausender oder so gerundet werden. Okay, Ihr Kontostand wird wahrscheinlich nicht mehr als zehn Stellen haben. Mittlerweile haben Computer- und Massenspeicher beeindruckende Größen erreicht. Kürzlich las ich eine Meldung über neu eingeführte 30-TB-Festplatten, als mir klar wurde, dass ich mich nicht einmal an die Größe meiner großen Datenträger-Dump-Festplatte erinnerte. Mal sehen, die Anzahl der
512-Byte-Sektoren beträgt ... 39063650304. Ups, ich kann diese Zahl nicht in meinen HP-15C eingeben. Um die ungefähre Größe der Festplatte zu berechnen, kann ich sie auf 3,91*10^10 schätzen. Ein Dateisystem muss jedoch alle Sektoren adressieren und die Größe einer Datei, die die gesamte Festplatte bedecken könnte, aufs Byte genau aufzeichnen können. Daher sollte es besser mit Zahlen wie 20000588955648 umgehen können. Deshalb verwenden wir heutzutage 64-Bit-Zahlen für solche Dinge, und man braucht 20 Dezimalstellen, um 2^64 darzustellen.Dann gibt es noch die Zahlentheorie. Um festzustellen, ob eine gegebene
100-stellige Zahl eine Primzahl ist, kann man sie nicht runden, man braucht alle Ziffern. Weit hergeholt? Es gibt Anwendungen in der Kryptographie. Während ich dies schreibe, verfügt die Website hpmuseum.org über ein TLS-Zertifikat mit einem einfachen öffentlichen RSA-2048-Schlüssel. Dabei handelt es sich um eine 2048-Bit-Zahl, die durch Multiplikation zweier großer Primzahlen entsteht (Multiplikation ist einfach, Faktorisierung hingegen schwierig). 2048 Bit würden 617 Dezimalstellen erfordern. Beachten Sie, dass ich dies mit 2048*log10(2) berechnen musste, da 2^2048 den verfügbaren Zahlenbereich meines Rechners sprengt.Marte Schwarz snipped-for-privacy@gmx.de schrieb oder zitierte:
Meßgenauigkeiten sind natürlich in der Regel begrenzend.
Aber ich kann Beispiele nennen:
Wenn man es sich einmal recht überlegt, kommen schwere Gegenstände doch schneller unten an, weil ein fallender Gegenstand ja auch die Erde zu sich hin beschleunigt und ein schwerer Gegenstand beschleunigt sie stärker, so daß er sie früher trifft.
Der Unterschied ist meist zu klein, um gemessen werden zu können, aber man kann einmal neugierig fragen, wie groß er denn theoretisch wäre.
Das folgende Programm soll die Zeit bis zum Auftreffen bei einer Fallhöhe von einem Meter und einer Masse von einem beziehungsweise zehn Gramm berechnen. Dabei wurde der Radius "r" (Abstand zum Erdmittelpunk) und somit die Beschleunigung "a" während des Falls näherungsweise als konstant angesehen.
# G = 6,67430(15) 10⁻¹¹ m³ kg⁻¹ s⁻² # r = 6,371 Mm = 6,371 10⁶ m # M = 5,9722 10²⁴ kg
from decimal import Decimal, getcontext import math prec = 30 getcontext().prec = prec
G = Decimal( 6.6743015E-11 ) r = Decimal( 6.371E6 ) M = Decimal( 5.9722E24 )
def a( m ): return G*( M + m )/ r**Decimal( 2 )
def t( s, m ): return( Decimal( 2 )*s / a( m )).sqrt()
print( f"{t( Decimal( 1 ), Decimal( 1/1000 )):.{prec}}" ) print( f"{t( Decimal( 1 ), Decimal( 10/1000 )):.{prec}}" )
0.451286685669097620869896105560 0.451286685669097620869896105220Man sieht hier einen Unterschied (ganz am Ende der beiden Ziffernfolgen), der mit gewöhnlichen Amateur-Programmiersprachen nicht mehr darstellbar wäre. Eine Vollprofi-Sprache wie Python kann den Unterschied in den hinteren Stellen jedoch darstellen!
Binärcomputer speichern Dezimalwerte wie "0.1" normalerweise nur näherungsweise. Einfach Anfängerprogrammersprachen verstecken die Abweichung, aber mit einer authentischen Fortgeschrittenensprache wie Python kann man den genauen Wert der internen Dualdarstellung anzeigen, was für Lehrzwecke praktisch sein kann.
(Letzte Zeile ist die Ausgabe in der Python-Konsole.)
|>>> from decimal import Decimal |>>> Decimal(0.1) |Decimal('0.1000000000000000055511151231257827021181583404541015625')
Ein Läufer läuft mit 1 m/s auf einem Laufband, das selber mit 1 m/s läuft. Wie schnell bewegt sich der Läufer relativ zum Fußboden?
Hier veranschaulicht das erste Ergebnis wie groß man sich relativistische Effekt im Alltag vorstellen kann, das zweite, wie schwierig es ist, die Lichtgeschwindigkeit zu erreichen.
Wer BASIC oder Pascal verwendet, muß hier wohl passen. Aber für einen Python-Programmierer ist so etwas kein Problem:
(Für das zweite Ergebnis muß man eventuell einige Minuten warten, da hier ein Algorithmus verwendet wird, der 299.792.458 Multiplikationen mit hoher Genauigkeit hintereinander ausführt.)
# v = ((k²-1)/(k²+1))c # k = sqrt((1+v/c)/(1-v/c))
from decimal import Decimal, getcontext
# Die Präzision der Berechnungen getcontext().prec = 99
l = Decimal(1) Z = Decimal(2) c = Decimal(299_792_458) s = 99
def sqrt(x, scale): getcontext().prec = scale a = Decimal(0) b = x.sqrt() while a != b: a = b b = x / a b = b + a b = b / Z return a
def v(k): k2 = k * k k2p = k2 + l k2m = k2 - l k2mk2p = k2m / k2p k2mk2pc = k2mk2p * c return k2mk2pc
def k(v): vc = v / c vcp = l + vc vcm = l - vc vcpvcm = vcp / vcm vcpvcmq = sqrt(vcpvcm, s) return vcpvcmq
def x(x): return Decimal(x)
def pow_decimal(a, n): r = Decimal(1) for i in range(n): r = r * a return r
def pow_decimal(a, n): r = Decimal(1) for i in range(n): r = r * a return r
if __name__ == "__main__": print(v(k(Decimal(1)) * k(Decimal(1)))) print(v(pow_decimal(k(Decimal(1)), 299_792_458)))
Ausgabe (hier gekürzt):
1.999999999999999977746998878927... 228320184.012...Diese Werte dürfte mit normaler Genauigkeit nicht mehr berechenbar sein.
Schließlich gibt es manchmal Simulationen oder Ähnliches, wo sich kleine Fehler durch geringe Stellenanzahl aufsummieren oder bei bestimmten Rechnungen vergrößern könnten, und man vielleicht gerne etwas "Genauigkeitsreserve" hat - vermute ich (ich bin kein Spezialist auf diesem Gebiet).
snipped-for-privacy@zedat.fu-berlin.de (Stefan Ram) schrieb oder zitierte:
Und diese Geschwindigkeit des letzten Segments unterscheidet sich deutlich von der Summe aller Geschwindigkeit /schon in der zweiten Stelle/ ("22" statt "29" am Anfang).
Dies ist also ein Beispiel, wo sich das /Endergebnis/ deutlich unterscheidet, aber sich nur korrekt ergibt, weil alle /Zwischenwerte/ mit erhöhter Genauigkeit berechnet werden!
Hi Hergen,
Mit den 8 gültigen Stellen des ollen fx-82 käme ich gut aus. Wenn die führenden Stellen sechsstellig überschreiten sollten, könnte ich auf die cents gut verzichten, Du nicht? Ich glaube, sechs gültige Stellen gerundet würden mir keine schlaflosen Nächte bereiten, Dir etwa?
Marte
Ich habe einen Casio fx-50F, der war für mich ausreichend, hatte als nettes Feature ein paar Naturkonstanten wie Lichtgeschwindigkeit, Elektronenmasse oder auch die Gravitationskonstante gespeichert.
Holger
Am 23.09.2025 um 08:50 schrieb Holger Schieferdecker:
Nur kann er nicht komplex rechnen - oder?
Am 23.09.25 um 01:27 schrieb Marte Schwarz:
Ja, je nachdem wie oft und in welche Richtung gerundet wird, kämen da durchaus ärgerliche Summen zusammen. Kurz vor der Rente hat man sich dann doch ein sechsstelliges Sümmchen beiseite gelegt, denn die Rente ist bekanntlich sicher. Nicht.
Auch der private Häuslebauer wird wenig begeistert sein, wenn die Bank die Restschuld des Kredits jeden Monat großzügig auf sechs gültige Stellen aufrundet.
Und spätestens in der Wirtschaft oder Politik wäre eine Rundung von Geldbeträgen auf sechs oder acht gültige Stellen für irgendwen SEHR profitabel.
Beispiele aus der Technik, wo genaue Zwischenergebnisse gebraucht werden, wurden ja bereits zahlreich genannt.
Hi Hergen,
Selbst wenn die täglich meinen Kontostand auf sechs gültige Stellen runden würden, wäre das ein Fall für den Statistiker, der dann beim Rundungsprozess ruhig schlafen würde. Bei nur 1% Zins p.a. sind das bei 100.000 € 2,74 € am Tag, die verbucht würden, aufgerundet auf volle € ;-) OK, irgendwann wird sich das Rundungsblatt wenden und Du würdest die Abrundung spüren. Im Ernst, machen die 365 € denjenigen arm? Über die Zeit mittelt sich das ohnehin aus.
Du kennst den Unterschied von runden und aufrunden?
Nein, es wäre schlicht egal.
Und kein einziges davon konnte mich überzeugen.
Marte
Städtische Mitarbeiter in Köln werden von oben angehalten, genau so zu denken. Aus diesen Cents der Monatsgehälter wurden gerade 20 k an die Hamas überwiesen.
An kanadischen Kassen steht (vermutlich stand) eine Schale Wechselgeld. Wer beim Bezahlen eine Centsumme brauchte, griff rein, wer Cents Wechselgeld herausbekam warf sie hinein. Auf die Weise blieb der Saldo der vielen Rundungen allen immer im Blick.
Have something to add? Share your thoughts — no account required.
Ask the community — no account required