ubuntuusers.de

Moin, folks

Auf die Gefahr hin, daß ich hier als absoluter DAU in die Geschichte des WWW eingehe: Die bash gefällt mir immer mehr, aber nach sage und schreibe jetzt 4h suchen im WWW finde ich richtig nix passendes...

wie kann ich in der bash mit floats rechnen und die Ergebnisse als Variablen einlesen, ausgeben und auch wieder übergeben,

z.Bleistift (SUBSUBtrivial) : Mein allererstes shell script

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

#!/bin/bash  
echo "Kugelberechnung"

echo -n "Gib den Durchmesser an "

read  D

echo  "D ist also:   $D , dann ist V demnach: ??"


gawk '{print 4/3 * 3.1412  * $D/2 * $D/2 * $D/2 }' <<<$D   

ok. Wert stimmt.

und wie kriege ich jetzt das errechnete Volumen in eine neu Variable z.B. V???

DENK: wenn mit <<< Variablen eingelesen werden, dann werden Sie logischerweise mit >>> ausgegeben. Also

1

gawk '{print 4/3 * 3.1412  * $D/2 * $D/2 * $D/2 }' <<<$D  >>>$V 

Pustekuchen (wär auch irgendwie echt ZU einfach... oder so:

1

$V =  2 x (gawk '{print 4/3 * 3.1412  * $D/2 * $D/2 * $D/2 }' <<<$D   ) 

oder

1

gawk'{print 4/3 * 3.1412  * $D/2 * $D/2 * $D/2 }' <<<$D   := V

ich finde nirgendwo was zu gawk – nur zu awk. Dat isses aber nicht.

Und wie kriege ich z.B. eine zweite Variable in GAWK ??

mit | bc hab ich auch schon experimentiert, das scheitert daran, daß z.B. a/b den ganzen teil angibt und a%b einen fehler. Ich will aber floats ..

Interaktiv ..

eingabe rechung ausgabe weiterrechnen. Ausgabe

Dafür muß man doch kein programm schreiben, oder?

Das KANN nicht so schwer sein im Jahr 2011, wir fliegen zum Mars, transplantieren Lebern und Augen, ganze Häute von Schweinen werden bald Politikern ein neues Antlitz geben, wenn deren alternde von grauem Zigarrenqualm zerfurchte Haut dereinst rissig wird und unsere 2,8Ghz Rechner verstehen nur integer .. ich geb auf ..

bin zu blöd 😢

... ach diese schönen bunten Pillen überalll ☺

1 handbuch auf Deutsch - mann das wär mal was... aber neee, wir sind ja indaneschnell..☺)))

Also, grundsätzlich gibt es zum rechnen von Floats nur bc und awk, das siehst Du schon richtig.

Variablen an eine Pipe verfüttern würde ich am ehesten mit echo:

d=7.1
echo -n "Bei einem Durchmesser von $d ist das Volumen "
echo "scale=4; 4/3*3.1412/8*$d^3"  |  bc

Beachte, dass bc immer einen Dezimalpunkt benutzt.

Oder, bei awk kann man Variablen direkt in das Skript einbetten:

d=7.1
awk "BEGIN{print \"Bei einem Durchmesser von $d ist das Volumen \" 4/3*3.1412/8*$d^3 }"

Mit "BEGIN" braucht awk keine Eingabe, sonst müsste man es mit echo anfüttern.
Die inneren Gänsefüßchen für awk müssen escaped werden, damit die Shell sie nicht interpretiert.

LG,

track

Edit:
Du suchst Manuals zu diesen Befehlen ? - versuch's mal mit man bc (oder dem Linux Kompendium bc)
oder man awk (oder der awk-Einleitung, oder guck mal im Nachbarstrang: http://forum.ubuntuusers.de/post/3330752/ )

Um es kurz zu machen: Man kann mit der Bash nicht wirklich rechnen; tust Du ja auch nicht! Du nutzt awk. Wenn Du wirklich rechnen willst, dann erlerne eine universelle Sprache oder eine mathematische Scriptsprache.

Und wegen der Doku: Englisch kannst Du beim Programmieren nicht vermeiden - technisches Englisch ist jedoch nicht so schwer, wie man denkt. Also quäl Dich durch die Doku und lerne die Dir unbekannten Vokabeln. Du wirst dann schnell Fortschritte beim Lesen machen ☺

Statt sich ein Pi zurechtzuklamüsern empfehle ich die libmath zu laden (bc -l) und dann 4*arcussinus (1) (oder was ist a(1)?) zu verwenden, und, mit scale, festzulegen, wie genau man es möchte (p ist hier Pi).

1

echo "scale=4;p=4*a(1); 4/3*p/8*$D^3" |  bc -l

Für kl. adhoc-Rechnungen kann man natürlich auch die Zahlen entsprechend der benötigten Genauigkeit aufblasen, und immer schön multiplizieren bevor man dividiert, aber muß dann wissen, wie man sie wieder zurückmanipuliert, was bei 2-3 Multiplikationen noch kein Akt ist, aber bei komplizierteren Aufgaben dann zu einer Aufgabe für sich wird.

1
2
3
4

echo "scale=4;p=4*a(1); 4/3*p/8*$D^3" |  bc -l
44593.8240
echo $((3141*4*$D**3/(3*8)))
44593824

Wer rechnen kann, kann überall rechnen, auch in der bash. ☺

Teil 2 der Frage - das Ergebnis wieder in eine Variable stecken:

1
2
3

kugelvolumen=$(echo "scale=4;p=4*a(1); 4/3*p/8*$D^3" |  bc -l)
# bzw.
kugelvolumen=$((3141*4*$D**3/(3*8000)))

Vielen Dank für die Antworten.

Es ging mir um das generelle einlesen und ausgeben... Mathe kann ich und Englisch eigentlich auch ☺

Vielen Dank an alle, hat mir weitergeholfen

als nächstes werden Dateinamen ein und ausgelesen ..

user unknown schrieb:

..

... tigten Genauigkeit aufblasen, und immer schön multiplizieren bevor man dividiert, ...

Ähhh?? weshalb das denn?? Punkt vor Strich ist OK, Klammern geht vor, aber erst multiplizieren, dann dividieren ??? Noch nie davon was gehört.

Das verstehe ich nicht so ganz .. (ich gehe davon aus, daß Du mir nicht Nachhilfe in Mathe geben wolltest ..??)

rappelkiste schrieb:

(ich gehe davon aus, daß Du mir nicht Nachhilfe in Mathe geben wolltest ..??)

Doch, wollte er. Und wohl nicht ganz zu Unrecht. 😀

Wenn Du zuerst multiplizierst und dann dividierst, dann werden die (internen) Zwischenergebnisse größer, und der Fehler beim Runden oder abschneiden von Nachkommastellen ist kleiner.
Das ist eine der ersten Sachen, die man in Informatik lernt. Stichwort "Rundungsfehler".

Guckstu:

track@lucid:~$ echo "scale=4; 3.1415 / 1000 * 1000"  |  bc
3.1000

LG,

track

track schrieb:

rappelkiste schrieb:

(ich gehe davon aus, daß Du mir nicht Nachhilfe in Mathe geben wolltest ..??)

Doch, wollte er. Und wohl nicht ganz zu Unrecht. 😀

Wenn Du zuerst multiplizierst und dann dividierst, dann werden die (internen) Zwischenergebnisse größer, und der Fehler beim Runden oder abschneiden von Nachkommastellen ist kleiner.
Das ist eine der ersten Sachen, die man bei angewandter Informatik lernt.

Guckstu:

track@lucid:~$ echo "scale=4; 3.1415 / 1000 * 1000"  |  bc
3.1000

LG,

track

Hammer.

bei meinem Taschenrechner kommt das gleiche raus. Sollte es auch.

Wo kommen wir denn da hin, wenn die Rechenregeln umgekrempelt werden (Informatik hin, Informatik her), nur weil der Rechner keinen Coproz hat (was glaube ich ALLE PC seit spätestens 496er haben...) Und die werden bei solchen Lappalien nicht genutzt. Ist ja unfassbar ... Ist ja in etwa so, als ob ln(A/B) unter linux nicht Ln(A)-ln(B) ist, sondern ln(A)-ln(B+x) mit x als Ubuntu-failFaktor 😉 Gilt das auch, wenn ich ne Programmiersprache benutze?

Sachen gibt es ...

Gibt es im PC etwa sowas wie "float bits" (also 0, 1 und 0,237) oder woran liegt das? Ein Taschenrechner (für 3,2€ bei Aldi mit 25kB Speicher) rechnet doch auch mit 0 und 1 ???

mein alter HP48GX hat 128kB und war ne Kanone - damals.. 1988 und rechnet noch immer richtig und zwar auf 12 Stellen genau und das bei zig fachem hin und her gerechne ...

ähhh ... komisch.

und ein 5, 6, 7 ,886 oder was weiß x86 Prozessor 20 Jahre später mit 3,2Ghz und 8Gb Ram soll das nicht hin bekommen?? (mein 16MHz-286er neat (BJ 1987) hatte wahnsinnige 640kB !!! und rechnete auch falsch, bis der 287 drin saß dann ging's jedenfalls unter Fortran77 ...)

Hmm .. Wo ist der Fortschritt frag ich mich. Das können keine Ingenieure gewesene sein, wahrscheinlich haben das Banker entwickelt.

Oder die Lehmann Brothers die runden gern zu ihren Gunsten 😊

sorry - mußte sein ...

Tja, Du hast da was mit *nix, dem Prinzip und der Mathematik nicht verstanden. 😀

*nix macht nach soweit möglich ganz exakt das was Du ihm sagst. Und hier haben wir ihm gesagt, er soll nur mit 4 Nachkommastellen rechnen (scale=4). - und das tut er dann auch, mit größter Sorgfalt, und ohne Mogeln. Dass Dein Taschenrechner das "richtige" anzeigt, ist ja sowieso teilweise zurecht gemurkst. (probier mal 10 / 3 * 3 → da muss 9.9999999 rauskommen, sonst hat er gemogelt !)

Klar kannst Du auch bc sagen, er soll mit 700 Stellen rechen, und Dir am Ende nur 4 Stellen anzeigen. Kein Problem. Kannst ihn ja mal fragen, wo seine Grenzen sind:

echo limits  |  bc

😀
Es geht ums Prinzip. Und das heißt in jedem Fall: wenn Du Fehler minimieren willst, dann erst multiplizieren und danach dividieren. Dann werden die Fehler minimal. Egal, ob hinter der 2. oder der 702. Stelle nach dem Komma.

track

Edit:
Ach ja, Du wolltest Pi auf 702 Stellen genau wissen ? Klar, bitte sehr: 😀 😀

echo "scale=702; 4*a(1)"  |  bc -l

track schrieb:

rappelkiste schrieb:

(ich gehe davon aus, daß Du mir nicht Nachhilfe in Mathe geben wolltest ..??)

Doch, wollte er. Und wohl nicht ganz zu Unrecht. 😀

Nein. Ich erinnere mich nicht mehr an die Grundschulmathematik, aber meine, dass man dort entweder präparierte Zahlen bekommt, die immer hübsch aufgehen (8/2, 9/3, 12/3, ...), dann mit explizitem Rest rechnet (8/3=2 Rest 2), dann zu gemischten Brüchen übergeht (8/3 = 2+2/3) und dann zu Dezimalbrüchen übergeht (2,(6-Periode)), und das Runden lernt (2,7 oder 3).

An keiner Stelle wurd beim Rechnen dumpf abgeschnitten, und wenn man davon noch nie gehört hat, würde ich das nicht 'nicht verstanden' sondern 'nicht erfahren' nennen - außer ich wüßte, dass derjenige schon davon gehört hat.

Also: Im Computerwesen wird oft mit Ganzzahldivision derart gearbeitet, dass das Ergebnis wieder eine Ganzzahl ist, die aber nicht gerundet wird, sondern abgeschnitten, d.h. 1/2=0, 1/10=0, 9/10=0, 99/100 = 0.

Das ist das Resultat einer Optimierung. Die Ganzzahldivision ist irrsinnig schnell, entgegen der Fließkommadivision. Man muss eben vorher wissen, ob man damit leben kann, oder ob man Fießkommazahlen braucht.

Wenn Du zuerst multiplizierst und dann dividierst, dann werden die (internen) Zwischenergebnisse größer, und der Fehler beim Runden oder abschneiden von Nachkommastellen ist kleiner.

Mit Rundungsfehlern hat man es ja fast immer zu tun.

Das ist eine der ersten Sachen, die man in Informatik lernt. Stichwort "Rundungsfehler".

Rundungsfehler gibt es natürlich auch, aber mir ging es um Fehler durch Abschneiden, die ja oft eklatant werden.

Gibt es im PC etwa sowas wie "float bits" (also 0, 1 und 0,237) oder woran liegt das? Ein Taschenrechner (für 3,2€ bei Aldi mit 25kB Speicher) rechnet doch auch mit 0 und 1?

Wenn man 8bit-Rechnern zu 64-Bit-Rechnern und von 1Mhz zu 8x4 Ghz wechselt, hat man dennoch irrsinnige Geschwindigkeitsvorteile, wenn man mit abschneidender Ganzzahlarithmetik arbeitet, die proportional wohl der auf kleinen, langsamen Rechnern entspricht. Außerdem stellt sich für die Nutzbarkeit die Frage: Wie viele Stellen sollen berechnet werden, wie viele Stellen angezeigt werden? Wenn man sagt, wir wollen per default mit k Stellen nach dem Komma rechnen, und n Stellen anzeigen, und wer es anders will, kann ja Parameter angeben oder Environmentvariablen setzen. Nun ja - dann kann man auch, je nach Bedarf, unterschiedliche Programme verwenden: Die Bash für Ganzzahloperationen, für elaboriertere Aufgaben bc.

Bezüglich der Fähigkeiten des Aldirechners empfehle ich (7⁷)⁷ zu rechnen, und mit

echo "7^7^7" | bc  

zu vergleichen.

Ich wollte noch nachtragen:

Ja es gibt unterschiedliche Darstellungen und Operationen für das Rechnen mit Ganzzahlen und Brüchen im Rechner.

Das Binärsystem ist recht leicht zu erklären - es arbeitet wie das 10er System, was ganze Zahlen betrifft, aber nicht mit einem Zeichenvorrat von 10 Zeichen (0-9), sondern mit 2 Zeichen (0-1).

Wenn man im Dezimalsystem einen Überlauf hat, weil man auf 9 eine 1 addiert, so bekommt man wieder ein 0 hinten, und die nächste Ziffer auf einer Position weiter vorne, wo man sich eine 0 vorstellen darf:

1
2
3

09  = 9 
01+ = 1
10  = 10

Im Binärsystem passiert der Überlauf so früh, dass es im ersten Moment unpraktisch scheint:

1
2
3

01  = 1
01+ = 1
10  = 2

Es ist aber sehr leicht in Elektrische Schaltungen umsetzbar, und man erkennt Muster des Dezimalrechnens darin wieder. Eine beliebig komplizierte und lange Zahl, wie 343454019 kann man leicht mit 10 multiplizieren, in dem man alle Ziffern um eins nach links schiebt, und eine 0 an die letzte Position setzt. "Schieben" ist dabei eine ungewöhnliche Vokabel, weil man Zahlen ja selten als Scrabblebausteine vor sich in Kästchen hat, aber ich denke es ist leicht verständlich.

Im Binärsystem hat man das gleiche bei der multiplikation mit 2: 101101010001101 mal 2 ist 1011010100011010.

Die Größe darstellbarer Zahlen ist aber eine Herausforderung. Im Speicher liegen die Bits - zumindest kann man sich das vereinfacht so vorstellen - nebeneinander. Wenn die Zahl nun größer wird - soll man sie nach links wachsen lassen? Könnte man machen, aber vielleicht liegt da schon eine Zahl? Nun - vielleicht sind alle Bits 0, weil da keine Zahl liegt, aber vielleicht liegt da ja die Zahl 0, die dezimal-0 bedeuten soll, und noch gebraucht wird?

Man belegt also pro Variable einen konstanten Speicher, und der Nutzer muss wissen, ob der Speicher auch ausreicht. Die kleinste, gängige Größe ist ein Byte oder auch 8 Bit. Die Zahl oben passt da schon nicht rein. Größere Einheiten heißen - aber nicht einheitlich - z.B. Short, Int, Long für 16, 32 und 64 bit. Die 1011:0101:0001:1010 benötigt also ein derartiges Short (die : dienen nur der Lesbarkeit, und bilden 4er-Gruppen), um gespeichert zu werden, aber würde von vielen Systemen schon als negative Zahl interpretiert, d.h. 2* 0101:1010:1000:1101 läßt sich auch nicht mehr korrekt abbilden.

Von der 1. Stelle, die bei negativen Zahlen gesetzt ist, abgesehen, kann man aber auch bei Binärzahlen leicht sehen, welche von 2 Zahlen größer ist, in dem man von links beginnend schaut, welche zuerst eine Ziffer hat, die größer ist. 35196 und 35274 kann man anhand der 3. Ziffer von links unterscheiden, ohne auf den Rest der Zahl zu achten, und bei 1001:1010 und 1010:0101 ist das genauso.

Viele Wissenschaftler nutzen für sehr große Zahlen oder sehr kleine eine Wissenschaftliche Notation der Form 6,14e23 oder 9,32E-12 was 6,14*10 ^23 heißt, also 614 mit 21 Nullen hintendran, bzw. 9,32, aber das Komma um 12 Stellen nach links verschoben. Ähnlich gibt es das auch für Zahlen im Computer, aber auch auf die Basis 2, bzw. 1/2 bezogen. Genaueres gibt es bei Wikipedia. Man kann damit quasi alle Anwendungsgebiete erschlagen, außer der Mathematik, die nicht vor Zahlen halt macht, die größer sind als die Zahl der Atome im Universum, oder kleineres berechnet als Atome, Protonen und Quarks.

Und für Finanzarithmetik taugt es auch nichts, weil sich viele Brüche und Dezimalzahlen nicht verlustfrei darstellen lassen, und das Finanzwesen eigene Rechenvorschriften hat - oft konkurrierende, je nach dem ob Banken rechnen, oder das Finanzamt, und je nach Nation.

1/3 kann zum Beispiel näherungsweise als Summe der Potenzen von 1/2: (1.0/2 - 1.0/4 + 1.0/8 - 1.0/16 + 1.0/32)=0.34375 dargestellt werden (und mit weiteren Stellen besser), aber nicht genau.

Es gibt daher wieder gesonderte Programme um den Regeln der Finanzmathematik entsprechend zu arbeiten.

Geiler thread!

Danke - wollt ich immer schon mal wissen.

Also. Der Rechner schneidet also einfach was ab.

Da hat er doch nun 64 bit (nach 64bit wär mir schlecht -ich trink immer nur maximal 5 ☺ )

Weshalb rechnet er dann nicht damit? Der langweilt sich doch eh nur; während ich diesen Text schreibe hat der wieviel Takte durchgeheizt =⇒ 2,8Ghz x 2 cores x 10min = 3,36 E12 Takte, da hätte er aber schon bißchen genau sein könne, gell?

ts..

was mich so erstaunt ist, daß der schon bei nur 4 Nachkommastellen derartige "große" Rundungsfehler macht und das bei dem doch recht trivialen beispiel von .. trac:

1
2

track@lucid:~$ echo "scale=4; 3.1415 / 1000 * 1000"  |  bc
3.1000

DAS macht mein Hp48 wirklich deutlich besser und braucht auch nicht so viel Saft.

Wir haben in Mechanik und Thermodynamik (da darf es mitunter schon mal genauer sein) und was weiß ich wo auch grundsätzlich mit z.B. 2/Wurzel 3 etc. gerechnet, erst ganz zum Schluß dann ausgewertet, weil - solange man analytisch korrekt bleibt z.B. bei Bewegunsgleichungen etc. gibt es auch keine Rundungsfehler.

Aber: daß das mit zuerst multiplizieren und danach dividieren zu tun hat wußte ich nicht. Hat uns auch nie einer gelehrt - dazu gibt es ja Informatiker ☺

Da fällt mir dann wieder ein:

Wie macht das denn dann z.B. Mathematika oder Matlab? Die rechnen doch analytisch z.B. können die sogar Differentialgleichungen analytisch lösen (und nicht nur die einfachsten) - oder lieg ich da falsch?? Und die laufen auf der gleichen Maschine wie meine bash (oder eben bc)

Das wär doch mal was für den Kernel ☺

Danke an alle, wirklich sehr nette, informative Ausführungen. Wieder schlauer geworden.

Also - ich werde mich bemühen ☺ erst x dann / ☺

Frei nach Gauß:

Die Unkenntnis in Mathematik gibt sich in nichts so sehr zu erkennen, wie durch übermäßige Genaugkeit im Zahlenrechnen.

(Mein Mathe-Lieblingsspruch. )

Um das Ding jetzt schließen: die Bash-rechnungen sollen "nur" max. 2 Nachkommastellen haben, (eigentlich reicht sogar eine..) es handelt sich hier weder um was zeitkritisches, noch um was genaues.

Denn (siehe oben) bei 5m³ Inhalt z.B. einer Kugel sind 0,223 ccm scheißegal ... da ist schon die Volumenabweichung bedingt das Rückstellmomnet der Elastomere (wer zieht wie fest an??) eine größere Abweichung

Gruß, Rrrrrappelkiste ☺

ach so - eins ist mir aufgefallen, dann ist aber wirklich Schluß: -unabhängig von der Richtigkeit der Formel ...

Mache ich folgendes:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

#!/bin/bash
# Mein allererstes Shell Script...
pi=3.14125926
echo
echo "Kugelvolumen: "
echo "---------------"
echo "Gib den Druchmesser an !"
read d
echo
echo
echo -n "Bei einem Durchmesser von $d ist das Volumen "
echo "scale=4; 4/3*$pi*($d/2)^3"  |  bc -l
echo "                       --------             --------------"
V_kugel=$(echo "scale=4; 4/3*$pi / 8*$d^3" |  bc -l)
echo 
echo
echo "Nochmal zur Sicherheit: Vol ist gleich 4/3 D³/8 mal $pi ergo: $V_kugel ... "

ergibt sich folgendes:

''
hupatz@rappelkiste:~$ ./hurz4

Kugelvolumen: 
---------------
Gib den Druchmesser an !
2


Bei einem Durchmesser von 2 ist das Volumen 4.18824097
                       --------             --------------


Nochmal zur Sicherheit: Vol ist gleich 4/3 D³/8 mal 3.14125926 ergo: 4.1880 ... 
hupatz@rappelkiste:~$ 
''

Frage:

weshalb nimmt der Meister Tux im ersten Statement "Bei einem Durchmesser ..." die 4 Stellen von scale nicht an, im zweiten "Nochmal zur Sicherheit " dagegen schon ..??

... Die Wege der Rechner sind unergründlich ... oder die user zu doof +Tschüß

Da hat er doch nun 64 bit (nach 64bit wär mir schlecht -ich trink immer nur maximal 5 ☺ ) Weshalb rechnet er dann nicht damit?

Weil er nicht vorher weiß was Du willst, wie genau Du es brauchst, und ob Du es nicht lieber schnell hättest, und weil seine Vorfahren groß, schwer und langsam waren.

Außerdem - wann rechnet man schon? Wenn, dann ist es ja nicht schwer, bc zu verwenden.

was mich so erstaunt ist, daß der schon bei nur 4 Nachkommastellen derartige "große" Rundungsfehler macht und das bei dem doch recht trivialen beispiel von .. trac:

1 2	track@lucid:~$ echo "scale=4; 3.1415 / 1000 * 1000" | bc 3.1000

Wenn Du ihm sagst, er soll so große Rundungsfehler machen, dann macht er die auch. Wenn Du 3.1415 / 1000 rechnest, kommt 0.0031415 raus - auf 4 Stellen gerundet ist das 0.0031, und das mal 1000 ist 3.1 . Wenn Du es genauer willst, dann sag es einfach:

1
2

echo "scale=40; p=4*a(1); p / 1000 * 1000"  |  bc -l 
3.1415926535897932384626433832795028841000

Die 3 Nullen am Ende kommen aus dem gleichen Effekt zustande.

Um das Ding jetzt schließen: die Bash-rechnungen sollen "nur" max. 2 Nachkommastellen haben, (eigentlich reicht sogar eine..) es handelt sich hier weder um was zeitkritisches, noch um was genaues.

Du willst am Ende nur eine Nachkommastelle ausgeben, was eine ganz andere Angelegenheit ist. Man kann ja Pi als 3.14000 ausgeben, und damit mit 5 Nachkommastellen - gerundet aber auf 2 Nachkommastellen.

Frage:

weshalb nimmt der Meister Tux im ersten Statement "Bei einem Durchmesser ..." die 4 Stellen von scale nicht an, im zweiten "Nochmal zur Sicherheit " dagegen schon ..??

Also,

1. ist das nicht Meister Tux, und auch nicht Deine tolle 64-Bit-CPU mit ihrer enormen integrierten 128-Bit FPU, sondern einzig und allein die Rechenkunst von bc wovon wir hier reden.

2. Bei Deinen beiden Berechnungen benutzt Du verschiedene Algorithmen. Das ist auch der Grund für die verschieden Ergebnisse:

   1. (scale=4) 4/3=1.333 *$pi=4.18824097 *($d)^3=4.18824097
      (bc schneidet offenbar nur bei bestimmten Operationen ab, und abweichend zu man bc nicht bei Multiplikation.)

   2. (scale=4) 4/3=1.333 *$pi=4.18824097 /8=0.5235 *$d^3=4.1880
      (der entscheidende Unterschied ist das Abschneiden nach der Division durch 8 !)

track