Thomas schrieb:

Bezieht sich das nur auf den aktuelle vermurksten von Win10/11?

Was ist am Taschenrechner von Windows 10 bzw. 11 vermurkst?

Ich sehe auch keinen Unterschied zwischen Win7 und Win 10.

Schau mal nach Graphcalc. (https://www.graphcalc.com/download/) Das ist ein Taschenrechnerprogramm, das fast den Funktionsumfang bietet, das die grafikfähigen Taschenrechner aus der Schulzeit hatten.

Thomas schrieb:

klein und kompakt (startet in <1s)

Das ist natürlich das wichtigste Kriterium. Was ist an dem Taschenrechner unter Win10/11 so schlecht? Der bietet eigenlich mehr als der alte Rechhner.

(prx) A. K. schrieb:

Manche sind darüber unglücklich, dass er im Standard-Modus keine Punkt-vor-Strich Rechnung durchführt

Das ist natürlich wirklich schlimm, da muß man sich ja selbst Gedanken über den Rechenablauf machen, damit man ein korrektes Ergebnis erhält. Da der TO einen wissenschaftlichen Taschenrechner möchte (Punkt 1 seiner Anforderung) könnte man bei dem Rechner ja "Wissenschaftlich" einstellen, dann mach er auch Punkt vor Strich. Er merkt sich sogar die Einstellungung bis zum nächsten Mal.

(prx) A. K. schrieb:

Manche sind darüber unglücklich, dass er im Standard-Modus keine Punkt-vor-Strich Rechnung durchführt, sondern strikt der Reihe nach vorgeht.

Unglücklich ???

Das ist ein klares NOGO. Einfach gesagt ein BUG der aus der Steinzeit kommt.

JEDEN Rechner mit den ich je gerechnet habe habe ich vorher auf diese Funktion getestet. Wenn ich mir Zwischensummen notieren muss, dann brauche ich kein Taschenrechner.

Ich habe das Problem so gelöst das ich entweder Excel starte oder aber mein Sharp-1401 an mache. JAJA, ist Nostalgie pur, aber der hat mich NIE im Stich gelassen, und darf als Dankbarkeit alle 3 Jahre ne neue Batterie futtern ;)

Und in seinen putzigen Programmspeicher sind immer noch meine selbstgeschriebenen Zinseszins-Programme drin und das Ohmische Gesetz-Prg.

Zeno schrieb:

Was ist an dem Taschenrechner unter Win10/11 so schlecht?

Das:

(prx) A. K. schrieb:

Manche sind darüber unglücklich, dass er im Standard-Modus keine Punkt-vor-Strich Rechnung durchführt, sondern strikt der Reihe nach vorgeht.

Es gibt Leute, die exakte Resultate brauchen. Die installieren sich dann eben den "alten" Rechner von Windows 7.

BTDT

Fake Friends schrieb:

Ein Programm, das elementare Regeln in den Wind schießt, ist kaputt. Ohne "wenn, hätte, wäre, müßte, könnte"

GENAU. !!!

Ich mag die Mathe weil sie LOGISCH ist.

Nur mit der unlogischen Rechtschreibung mit der ein paar alte Männer sich wichtig tun wollen stehe ich auf Kriegsfuß.

Was die punkt-vor-Strich-Regel angeht. Mein Taschenrechner in der Schule war zwar ein Tick teurer (10 DM und funktioniert auch heute noch).

ABER er hat mir wegen der Regel die er hatte, viele gute Noten eingebracht. Und ich höre heute noch das Gestöne "verdammt das habe ich übersehen". Ich habe nicht einmal danach gesucht, weil ich wusste das ich lange Aufgaben da einfach eintippen konnte ohne so ein Kindermist.

Ich finde http://www.speedcrunch.org/ wunderbar. Ist open-source und gibts als fertigs Binary für Win, Linux, ....

Kann eigentlich auch alles, was ich brauche und noch viel mehr.

Qalculate: https://qalculate.github.io/

Den hier habe ich auf mein Handy.

https://www.schoettler-software.com/de/calctape/windows

Gibt es für fast alle OS.

(prx) A. K. schrieb:

Manche sind darüber unglücklich, dass er im Standard-Modus keine Punkt-vor-Strich Rechnung durchführt, sondern strikt der Reihe nach vorgeht.

Hatten wir das Thema nicht schon einmal? Ich glaube, dass die Erklärung war, dass einige "kaufmännische" Rechner so arbeiten.

Gruß Simon

(prx) A. K. schrieb:

Manche sind darüber unglücklich, dass er im Standard-Modus keine Punkt-vor-Strich Rechnung durchführt, sondern strikt der Reihe nach vorgeht.

Das tut mein calc in Windows 7 allerdings auch, genau wie der in Win 10. Vielleicht wars in XP noch anders.

Peter D. schrieb:

Ja, der W10/11 Rechner ist vermurkst, kann im wissenschaftlichen Mode kein Hex.

Für was braucht man das?

Roland F. schrieb:

Ab man kann das Problem einfach umgehen, indem man den wissenschaftlichen Modus nutzt.

In jeden halbwegs brauchbaren Software gibt es den Punkt EINSTELLUNG.

Wieso also nicht auch in den Teil. Da stelle ich meine Art zu Rechnen ein, und es würde in beiden Varianten funktionieren. DAS ist die übliche Vorgehensweise.

Aber MS liefert grundsätzlich nur Mist dabei. Das einzige Sinnvolle Programm war Solitär.

Wenn man sowieso schon den PC an hat, dann kann man auch gleich Mathstudio nehmen. Welcher Taschenrechner hat sonst schon die Besselfunktionen? Und noch einiges nuetzliches mehr...

Gab es u.a. unter dem Namen "SpaceTime" auch fuer den Pocket-PC.

Thomas schrieb:

ich suche ein "Taschenrechner"-Programm für Windows:

Schau dir das mal an https://www.dreamcalc.com/

Es gibt 3 Versionen - eine davon ist "free" und hat weniger Funktionen.Ein Vergleich der 3 Versionen ist gegeben.

Ich selbst verwende nur noch eine Android-App (was du nicht willst) Hiper Scientic calculator - Top Rechner auch mit der Moeglichkeit sich sein eigenes Tastenfeld zusammenzubasteln.Unterstuetzt mikro,nano,pico,femto etc. Tasteneingaben.Extrem praktisch.Komplexe Zahlen,Binaer,Hex etc.Jeden "Mist" den man halt so benoetigen kann.Formeln lassen sich erstellen und abspeichern.Bietet selbstverstaendlich auch Integral,Differential und grafische Darstellung...selbst checken falls doch Interesse besteht

Gibt es eigentlich einen plausiblen Grund, weshalb kaufmännische Taschenrechner kein Punkt-vor-Strich beherrschen?

Ebenso ärgerlich ist die Prozent-Taste, die an jedem Taschenrechner anders und nie wie erwartet funktioniert.

Bsp.:

• "Wissenschaftlicher" Taschenrechner von LIDL für 5 €: 200 + 10% Ergebnis: 2100; nach Gleichtaste: 210 WTF!? ** noch besser: 123 + 10% Ergebnis: 1330; nach Gleichtaste: 133, wo kommt denn bitte schöt diese Zahl her???

• Windows10-Rechner (Standard, der wiss. scheint wohl aus gutem Grund gleich auf die Prozenttaste zu verzichten): 200 + 10% Ergebnis: 20; nach Gleichtaste 220

• Kaufmännischer Großtasten-Rechner: 200 + 10% Ergebnis: 220 sofort; na immerhin!

• Samsung-App: 200 + 10% Ergebnis: 220 sofort

• RealCalc-App: 200 + 10% Ergebnis: 20; nach Gleichtaste 220

• "Wissenschaftlicher" Taschenrechner von LIDL für 5 €: 200 + 10% Ergebnis: 2100; nach Gleichtaste: 210 WTF!?

Das ist kein "Fuck" sondern ein Casio im Tarnanzug. Bei denen geht das so:

200 * 10 % +

Danke, ein paar interessante Kandidaten sind dabei. Favorit bis jetzt: SpeedCrunsh.

Ich hatte in Erinnerung, dass der Taschenrechner von Win7 auch nicht rechnen konnte, bzw kein Punkt-vor-Strich.

die Funktionsanalyse?

Kann die auch mehr als simple Polynome?

Weiß jemand?

Mein Name ist Sch*lz, und ich kann mich nicht erinnern.

Schlaumaier schrieb:

JEDEN Rechner mit den ich je gerechnet habe habe ich vorher auf diese Funktion getestet. Wenn ich mir Zwischensummen notieren muss, dann brauche ich kein Taschenrechner.

Ja wenn man zu doof ist Klammern und/oder Speicher zu benutzen, dann muß man sich natürlich die Zwischenergebnisse der Rechnungen notieren. Gleiches trifft natürlich zu wenn sich vor Beginn der Rechnung keine Gedanken über den Lösungsweg macht. Ist aber heutzutage offensichtlich völlig normal, da ist Mitdenken ein Schlaumaier schrieb im Beitrag #7332708:

klares NOGO

Fake Friend schrieb:

Es gibt Leute, die exakte Resultate brauchen.

Ach wie haben wir denn früher gerechnet, als der Großteil der Rechner so etwas noch nicht konnte? Ich kann mich noch an Zeiten erinnern, da war man froh überhaupt einen Taschenrechner sein eigen nennen zu dürfen. Mein allererster Taschenrechner konnte 4 Grundrechenarten und einfache Klammern - damit erhielt man durchaus exakte Ergebnisse und das Ganze schneller als diejenigen die mit Bleistift und Papier unterwegs waren. Ganze Generationen von Ingenieuren haben mit dem Rechenschieber gerechnet und deren Resultate waren immerhin so exakt, daß es die Menschheit voran gebracht hat. Leider hat es am Ende dazu geführt, das heutzutage viele zu faul sind ihr eigenes Hirn zu nutzen. Tu Dich mal mit dem Schlaumaier zusammen - ihr währt ein Dreamteam.

(prx) A. K. schrieb:

denen aber mathematische Grundlagen wie eben jene Punkt-vor-Strich Regel abgeht.

so isses

Thomas schrieb:

Hallo,

e

Bitte keine Diskussion über :-)

• die Vor- und Nachteile von UPN
• Windows vs. anderes OS
• Software- vs. Hardware Taschenrechner
• Die "Qualität" des von MS mitgelieferten calc.exe

Hat jemand einen guten Tipp?

Gruß, Thomas

Hier eine Idee als C# Code. Anpassen, übersetzen und Spaß haben :) using System; using System.Windows.Forms;

namespace Calculator { public partial class CalculatorForm : Form { double num1, num2, result; char operation;

1

    public CalculatorForm()

2

    {

3

        InitializeComponent();

4

    }

5

6

    private void btnOne_Click(object sender, EventArgs e)

7

    {

8

        txtDisplay.Text = txtDisplay.Text + btnOne.Text;

9

    }

10

11

    private void btnTwo_Click(object sender, EventArgs e)

12

    {

13

        txtDisplay.Text = txtDisplay.Text + btnTwo.Text;

14

    }

15

16

    // Weitere Eventhandler für die anderen Zifferntasten

17

18

    private void btnAdd_Click(object sender, EventArgs e)

19

    {

20

        num1 = double.Parse(txtDisplay.Text);

21

        operation = '+';

22

        txtDisplay.Text = "";

23

    }

24

25

    private void btnSubtract_Click(object sender, EventArgs e)

26

    {

27

        num1 = double.Parse(txtDisplay.Text);

28

        operation = '-';

29

        txtDisplay.Text = "";

30

    }

31

32

    // Weitere Eventhandler für die anderen arithmetischen Operationen

33

34

    private void btnEquals_Click(object sender, EventArgs e)

35

    {

36

        num2 = double.Parse(txtDisplay.Text);

37

38

        switch (operation)

39

        {

40

            case '+':

41

                result = num1 + num2;

42

                break;

43

            case '-':

44

                result = num1 - num2;

45

                break;

46

            case '*':

47

                result = num1 * num2;

48

                break;

49

            case '/':

50

                result = num1 / num2;

51

                break;

52

            case '%':

53

                result = num1 % num2;

54

                break;

55

            case '^':

56

                result = Math.Pow(num1, num2);

57

                break;

58

            default:

59

                MessageBox.Show("Invalid operator");

60

                return;

61

        }

62

63

        txtDisplay.Text = result.ToString();

64

    }

65

}

}

Diek schrieb:

Das tut mein calc in Windows 7 allerdings auch

Nö der Windows 7 Rechner ist da unter den Win Rechnern eine Ausnahme und macht auch im Standardmodus Potenz vor Punkt vor Strich. XP macht es so wie Win 10/11. Das automatische Einhalten der Rechenregeln ist zwar ein nettes Feature, gebraucht habe ich es bisher noch nicht wirklich. Gehöre allerdings auch noch zu der Generation, wo es zumindest in der Schulzeit noch keine Taschenrechner gab, weshalb das alles bis zum Abwinken geübt wurde. Das ist so in Fleisch und Blut übergegangen, das das mittlerweile mittlerweile ein Automatismus ist und ich eigentlich nicht mehr drüber nachdenke.

Im Studium hatte ich dann den Rechner auf dem Bildle, für die damalige Zeit (Mitte der Siebziger) konnte der auch enorm viel, außer eben Punkt vor Strich - ich war trotzdem froh das ich diesen Rechner hatte. Der funktioniert auch heute noch, alledings nutze ich den mittlerweile recht wenig. Wenn ich jetzt einen Rechner brauche, dann nehme ich meist den HP35 oder den in Win eingebauten.

Peter D. schrieb:

Ja, der W10/11 Rechner ist vermurkst, kann im wissenschaftlichen Mode kein Hex.

Ja man kann immer ein Haar in der Suppe finden. Dafür gibt es den Programmierermodus und da kann er dann wiederum mehr als der alte Rechner. Wenn ich mit Hex rechne, dann geht es eher weniger "wissenschaftlich" zu. Eigentlich brauche ich das nur um schnell zwischen den Zahlensystem umzurechnen. Das kann aber bei Dir natürlich ganz anders sein, weshalb es für Dich eben ein Mango ist.

Schlaumaier schrieb:

Wenn ich mir Zwischensummen notieren muss, dann brauche ich kein Taschenrechner.

Zu doof für die Tasten MS, MR, (2.Z.v.o, bei calc.exe) ?!

Roland F. schrieb:

Mal so nebenbei, wofür nutzt du eigentlich die Standard-Version?

Ich nutze die Software gar nicht. Wie weite oben geschrieben mache ich immer bei einen neuen Rechner eine Testrechnung. Ist das Ergebnis falsch nutzt ich das Teil nicht.

Der Rechner ist im Normal-Mode aufgegangen, Testrechnung ging schief ergo WEG DAMIT.

Weil mir immer noch nicht einleuchtet was "wissenschaftlich" mit Grundlagen der Mathematik aus meiner Grundschulzeit zu tun hat.

Zeno schrieb:

Gleiches trifft natürlich zu wenn sich vor Beginn der Rechnung keine Gedanken über den Lösungsweg macht.

Falsch. Entweder ich reche ALLEINE wie in der Grundschule ohne Rechner ODER ich nutze ein Rechner von den ich erwarte das er mir das denken + rechnen abnimmt. Ansonsten kann ich auch ein Rechenstab oder ein Abakus nutzen. Wobei ich zugeben muss das ich mit den Abakus nicht umgehen kann :)

Zeno schrieb:

Gehöre allerdings auch noch zu der Generation, wo es zumindest in der Schulzeit noch keine Taschenrechner gab, weshalb das alles bis zum Abwinken geübt wurde. Das ist so in Fleisch und Blut übergegangen, das das mittlerweile mittlerweile ein Automatismus ist und ich eigentlich nicht mehr drüber nachdenke.

Genau wie ich. Im Geschäft rechne ich an der Kasse bis auf 1 Euro genau aus was ich im Wagen habe. Genau so wie Rabatte und ähnliches Zeug.

Einen Rechner nutzt ich meist nur bei komplizierten Kettenrechnungen. Und da liebe ich ein laufendes Display wo ich meine Eingaben kontrollieren kann. Rechnen kann ich, aber gegen Tippfehler habe ich noch nix 100% entwickelt. ;(

Weshalb ich halt wie oben auch erwähnt, EXCEL o. mein 1401 nehme.

Mir hat dieser Taschenrechner von 1978 http://mycalcdb.free.fr/main.php?l=0&id=555 (den verwende ich heute noch) eine Klausur in Elektrische Antriebe gerettet, Aufgabe war u.a die Berechnung der Stromversorgung einer 3~Asynchronmaschine (Spannungsabfall; Wirk-Blindleistung usw.) Am Ende meiner Rechnung stellte ich fest, dass ich die √3
vergessen hatte. Also alles nochmal, ging nur, weil der Rechner kplx. Zahlen in Komponenten rechnen kann.

Jens G. schrieb:

Zeno schrieb:

Das kann aber bei Dir natürlich ganz anders sein, weshalb es für Dich eben ein Mango ist.

Ist er Gärtner? ;-)

Hast ja recht, es sollte Manko heißen.

Schlaumaier schrieb:

Wobei ich zugeben muss das ich mit den Abakus nicht umgehen kann

Dachte ich es mir.

Elektrofan schrieb:

Mir hat dieser Taschenrechner von 1978 http://mycalcdb.free.fr/main.php?l=0&id=555 (den verwende ich heute noch) eine Klausur in Elektrische Antriebe gerettet,

Zu der Zeit waren bei uns noch Taschenrechner in Klausuren verboten, weil viele noch keinen ihr Eigen nennen konnten. Wer ein paar DM übrig hatte, ist in den (Inter)Shop gegangen und hat sich so einen Privileg (s. Bildle) geholt. Konnten aber auch nicht viele. Demzufolge wurde schriftlich, mit dem Rechenschieber oder dem Tafelwerk gerechnet. In theoretischer Elektrotechnik wurden wir allerdings mal dazu angehalten uns für eine Hausarbeit einen Rechner auszuleihen bzw. uns gegenseitig zu helfen, damit die Ergebnisse ausreichend genau waren.

Elektrofan schrieb:

Also alles nochmal, ging nur, weil der Rechner kplx. Zahlen in Komponenten rechnen kann.

Konnte mein Sharp auch.

Yalu X. schrieb:

Genau, hau dein Excel in die Tonne!

nö. Ich habe noch nie das ^ Zeichen benutzt. Ist einfacher.

Ich benutzte das was ich selbst habe POTENZ ;)

Peter N. schrieb:

Das macht doch jeder Taschenrechner, es sei denn, man verwender Klammern?

Jein, es gibt mittlerweile Taschenrechner die schreiben die komplette Eingabezeile hin bzw. merken sich diese und rechnen erst mit Druck auf die = Taste. Diese Rechner beachten in aller Regel die Rechenregeln, also Punkt vor Strich. Bei vielen einfachen Rechnern, insbesondere die Älteren berechnen bei jeder Operatoreneingabe das Zwischenergebnis und benutzen dieses dann für die weiteren Berechnungen. Beide Varianten haben Vor und Nachteile. In beiden Fällen muß ich halt Klammern setzen, wenn ich eine andere Berechnungsweise möchte.

Yalu X. schrieb:

Excel nutze ich nicht, habe den PlanMaker-free von Softmaker.

Na, dann mach mit Excel mal die Testrechnung -3^2. Ist das Ergebnis -9? Nein?

Da bekomme ich -9, was ich Fehler ansehe. Das hoch_2 geht in diesem Fall nicht vor, weil das Minus Bestandteil der Eingabezahl ist.

Oder probier mal 2^2^3. Ist das Ergebnis 256? Nein?

Da bekomme ich 64, was ich korrekt finde. Die beiden hoch_2 sind gleichwertig, also der Reihe nach.

Hat Excel also gleich zweimal versagt?

Nur einmal?

Peter N. schrieb:

Manche sind darüber unglücklich, dass er im Standard-Modus keine Punkt-vor-Strich Rechnung durchführt, sondern strikt der Reihe nach vorgeht.

Das macht doch jeder Taschenrechner, es sei denn, man verwender Klammern?

Ein Sharp 'Scientific calculator EL-506P' von 1986 macht das: 7x7+3x2=55, also berücksichtigt Punkt-vor-Strich.

Das tut auch Windows calc.exe in der Wissenschaftlichen Ansicht und ebenso mein Texas TI-30 III.

Wo ich gerade dabei bin, auch mein Planmaker gibt 55 aus. Im Regelfall verlasse ich mich nicht darauf und setze Klammern.

Thomas schrieb:

Hat jemand einen guten Tipp?

ghci. Musst halt noch die ein oder andere Bib-Funktion einfliegen. Oder abwarten, bis ChatGPT eine Wolfram Alpha-Engine intus hat. ( https://writings.stephenwolfram.com/2023/01/wolframalpha-as-the-way-to-bring-computational-knowledge-superpowers-to-chatgpt/ )

Oder eben: https://embedeo.org/ws/command_line/bc_dc_calculator_windows/

Manfred schrieb:

Excel nutze ich nicht, habe den PlanMaker-free von Softmaker.

Na, dann mach mit Excel mal die Testrechnung -3^2. Ist das Ergebnis -9? Nein?

Da bekomme ich -9, was ich Fehler ansehe. Das hoch_2 geht in diesem Fall nicht vor, weil das Minus Bestandteil der Eingabezahl ist.

Oder probier mal 2^2^3. Ist das Ergebnis 256? Nein?

Da bekomme ich 64, was ich korrekt finde. Die beiden hoch_2 sind gleichwertig, also der Reihe nach.

Sehe ich eigentlich genau so.

Manfred schrieb:

Ein Sharp 'Scientific calculator EL-506P' von 1986 macht das: 7x7+3x2=55, also berücksichtigt Punkt-vor-Strich.

Im Gegensatz zum EL-5001 ist der ja auch schon ein zwei Generationen weiter.

Manfred schrieb:

Im Regelfall verlasse ich mich nicht darauf und setze Klammern.

Was dann auch der beste Weg ist.

Kein Problem sehen ist etwas anderes als kein Problem haben. Der Exponentialoperator ist RECHTS-ASSOZIATIV!

Norbert schrieb:

Der Exponentialoperator ist RECHTS-ASSOZIATIV!

Und das jetzt mal bitte für Leute, die nicht Mathematik studiert haben.

Manfred schrieb:

Norbert schrieb:

Der Exponentialoperator ist RECHTS-ASSOZIATIV!

Und das jetzt mal bitte für Leute, die nicht Mathematik studiert haben.

Man löst sie von rechts nach links auf…

Thomas G. schrieb:

Na, dann mach mit Excel mal die Testrechnung -3^2. Ist das Ergebnis -9?

Halte ich für richtig, das Vorzeichen bezieht sich auf den Ausdruck "3^2"; -(3^2). (-3)^2 ergibt +9

Das Vorzeichen bezieht sich auf die Mantisse. Schön zu sehen bei:

1

$ echo "-3^2" | bc

2

9

3

$ echo "0-3^2" | bc

4

-9

5

6

$ echo "-3^3" | bc

7

-27

8

$ echo "0-3^3" | bc

9

-27

Nur der Vollständigkeit halber, eine weitere Interpretationsmöglichkeit eines ›Unary -‹ ist zB. bei Python und auch bei anderen Sprachen zu sehen:

1

$ python3 -c "print(-3**2)"

2

-9

3

$ python3 -c "print(-3**3)"

4

-27

Interessant, dass Octave/MATLAB noch nicht genannt wurden. Finde ich beide schöner zu bedienen als Python.

Ansonsten ist der calc.exe imo wirklich gut. Ist ne recht moderne uwp App mit viel Funktionen. Ist doch gut, dass er mehrere Modi hat. Wissenschaftlichen Modus bekommt man übrigens direkt nach dem Starten auch mit alt+3 oder 4. Finde auch die programmier Ansicht richtig gut. Zum Anklicken der einzelnen Bits z.B. Praktisch für Registergefummel. Und verschiedene Bitbreiten kann er auch, allerdings „nur“ signed glaube ich.

(prx) A. K. schrieb:

Die polnische Notation stellt die Operation davor, die umgekehrt polnische dahinter.

Umgekehrt polnisch war bei mechanischen Rechenwerken mit Drucker üblich, vermutlich mögen Kaufleute diese Art der Eingabe heute noch.

Es müsste auch HP-Rechner in umgekehrt polnisch gegeben haben.

M.A. S. schrieb:

Ich habe mir angewöhnt, für irgendwelche schnellen Nebenrechnungen immer einen Matlab-Clone wie Scilab oder Gnu Octave am PC offen zu haben und darin zu rechnen.

(+1) Gnu Octave ist auch super.

Yalu X. schrieb:

Doch, nach Konvention ist -3^2 = -(3^2)

Gerade noch mal nachgelesen im schlauen Kompendium der Mathematik und da muß man Yalu recht geben. Wenn man eine negative Zahl potenzieren möchte, so muß man sie in Klammern setzen.

Teo D. schrieb:

Ich wüste nicht, wie ohne auskommen.

Ist halt Gewohnheit - früher mußte es gehen.

Thomas schrieb:

Hat jemand einen guten Tipp?

GNU basic calculator https://de.wikipedia.org/wiki/Bc_(Unix)

Der erfüllt alle deine Anforderungen. Im Gegensatz zum hier genannten Rest kann er auch so etwas wie 2^9999999+1 berechnen und braucht auch keine Ewigkeit zum starten. Die Genauigkeit ist beliebig präzise, da er nicht mit Registerbreiten rechnen. Mit Hexwerten rechnen geht ebenfalls.

Mit den entsprechenden Bibliothekserweiterungen kann er viele Funktionen und kennt auch diverse Konstanten. http://x-bc.sourceforge.net/extensions_bc.html http://x-bc.sourceforge.net/scientific_constants_bc.html

Und natürlich kann man ihm auch eigene Funktionen beibringen, er ist programmierbar.

Hier gibt es eine Anleitung: https://www.shell-tips.com/linux/how-to-use-bc/

In msys2 ist er enthalten und kann so leicht für Windows installiert werden. https://www.msys2.org/

Auf Linux Systemen ist er recht leicht über das Paketsystem installierbar.

Tipp: Wenn du noch git for windows installierst, dann kannst du ihn bequem aus einer bash Shell starten. Die ist für GNU bc etwas besser geeignet als cmd.exe.

Außerdem kann er direkt von einer Shell aus benutzt werden. Man muss da also nicht zur Maus greifen, wenn man gerade mit der Shell arbeitet.

Er funktioniert auch in der PowerShell.

Schlaumaier schrieb:

(prx) A. K. schrieb:

Manche sind darüber unglücklich, dass er im Standard-Modus keine Punkt-vor-Strich Rechnung durchführt, sondern strikt der Reihe nach vorgeht.

Unglücklich ???

Das ist ein klares NOGO. Einfach gesagt ein BUG der aus der Steinzeit kommt.

JEDEN Rechner mit den ich je gerechnet habe habe ich vorher auf diese Funktion getestet. Wenn ich mir Zwischensummen notieren muss, dann brauche ich kein Taschenrechner.

Ich habe mir angewöhnt grundsätzlich Klammern zu setzen, dadurch wird immer richtig gerechnet, egal welchen Rechner ich benutze.

Übrigens, wer keinen Taschenrechner installiert hat, kann auch Google benutzen. Die Suchmaschine kann auch rechnen. https://www.google.com/search?q=2%252B2%5E34-1

Und wer einen Leistungsfähigeren online Rechner braucht, kann die Suchmaschine von Wolfram Alpha verwenden. https://www.wolframalpha.com/input?i=f%28x%29%3Dx%5E3%2B1

Einziger Nachteil, die Suchmaschinen brauchen zum Rechnen eine Internetverbindung.

●DesIntegrator ●. schrieb:

BTW, anno '69 ist man mit Rechenschiebern zum Mond geflogen.

Ich hab's damals live sehen dürfen, die sind ohne Zweifel mit einer Rakete und einer Raumkapsel geflogen!

●DesIntegrator ●. schrieb:

vor kurzem gefunden...

niggs Speicher oder gar eine "zurück-Taste"

BTW, anno '69 ist man mit Rechenschiebern zum Mond geflogen.

Die sind auch viel genauer und wesentlich schneller.

●DesIntegrator ●. schrieb:

vor kurzem gefunden...

niggs Speicher oder gar eine "zurück-Taste"

BTW, anno '69 ist man mit Rechenschiebern zum Mond geflogen.

Die sind auch viel genauer und wesentlich schneller.

Der größte Vorteil ist der Langzeitspeicher.

Yalu X. schrieb:

Schlaumaier schrieb:

Yalu X. schrieb:

Genau, hau dein Excel in die Tonne!

nö. Ich habe noch nie das ^ Zeichen benutzt.

Vermutlich, weil du diesen Operator gar nicht kanntest.

Selbstverständlich kenne ich den.

ABER, der winzige Haken ist bei meinen nicht mehr so guten Augen schnell zu übersehen. Besonders wenn ich Formeln überprüfen muss. Ergo schreibe ich Potenz und weiß das ich es richtig gemacht habe.

Lesbarkeit geht mir über alles.

In den Zeiten als man noch Listings abgetippt hat, habe ich in ca. 2000 Datazeilen mal ein Komma zu viel gemacht, was ich nach 3 Tagen immer noch nicht gesehen habe. Ich habe sogar beim Verlag angerufen ob da ein Tippfehler wäre. Gefunden hat in für 5 DM meine Schwester die das überprüft hat. Achja, es was der erste Schnelllader auf einen C=64 den ich aus der C64 Abgetippt hatte.

Weshalb ich als "gebranntes Kind" mich davor scheue, so winzige Zeichen zu benutzen. Selbst bei SQL-Befehlen setze ich nach jeden Komma ein Leerzeichen damit ich das Teil besser sehe.

Den Ausdruck (2^9999999+1) kann MicroPython Ruck-Zuck mit großer Präzision berechnen.

1

>>> (2^9999999+1)

2

10000002

Schlaumaier schrieb:

Achja, es was der erste Schnelllader auf einen C=64 den ich aus der C64 Abgetippt hatte.

Da musste man doch aber dauernd Kommas eingeben:

Bei C usw. kann man auch mal Semikolons übersehen. Was aber hilft, ist Übung und der Compiler hilft auch ein wenig.

https://www.spektrum.de/lexikon/psychologie/mustererkennen/10194 https://www.spektrum.de/lexikon/psychologie/pop-out-effekt/11678

rbx schrieb:

Da musste man doch aber dauernd Kommas eingeben:

Genau und ich habe 1 ZU VIEL eingegeben. Was dazu führte das die Schleife da eine 0 gelesen hat und den Rest eine Speicherstelle verschoben hat.

Weshalb ich (um zum Thema zurück zu kommen) bis heute Taschenrechner mit Rechenweg-Display vorziehe.

Bei meine Sharp-1401 z.b. ist das eine sehr lange scrollbare Zeile wenn ich den in den Basic-Mode schalte.

Die einzige Funktion die ich bei meinen Super-Taschenrechner aus der Schule vermisst habe. Das War ein Privileg LC-1070 SR. Der hatte sogar Statistik-Funktionen und was ich besonders geliebt habe, Zeit-Umrechnungsfunktionen.

Die hat noch nicht einmal das heiß gelobte EXCEL. Was ich immer noch sehr bedauere.

Yalu X. schrieb:

Nano schrieb:

GNU basic calculator https://de.wikipedia.org/wiki/Bc_(Unix)

Der erfüllt alle deine Anforderungen. Im Gegensatz zum hier genannten Rest kann er auch so etwas wie 2^9999999+1 berechnen und braucht auch keine Ewigkeit zum starten.

Was meinst du mit dem "hier genannten Rest"? Der bc wurde schon genannt, ebenso Python, das im Wesentlichen alles kann, was bc kann, und noch viel mehr.

Der bc wurde bisher oben nicht wirklich vorgeschlagen, sondern lediglich zum Ausrechnen eines Wertes verwendet.

Verfügt denn Python von Haus aus, also ohne das man das erst programmieren muss, die Möglichkeit mit Zeichenketten zu rechnen? bc verwendet, wie ich bereits erwähnte nämlich eben keine festen Datentypen in Registerbreite, sondern der verwendet Zeichenketten um beliebig große Zahlen zu ermöglichen.

Alle drei (bc, Python und GHCi) können den obigen Ausdruck (2^9999999+1) exakt berechnen, Es gibt aber große Unterschiede in der Rechenzeit:

1

> Rechner      Laufzeit / s auf i5-6267U @ 2.9GHz

2

>           Berechnung   dezimale Ausgabe >/dev/null

3

> ──────────────────────────────────────────────────

4

> bc           120s                 <0,1s

5

> Python      <0,1s                  134s

6

> GHCi        <0,1s                  0,5s

7

> ──────────────────────────────────────────────────

8

>

Das zeigt, dass bc mit Zeichenketten rechnet und bei Python vielleicht doch feste Datentypen mit fester Breite verwendet werden. Das bedeutet dann aber auch, dass der Zahlenbereich, mit dem Python rechnen kann, endlich ist.

Versuch mal größere Zahlen, z.B. 2^99999999999999999999999999999

GHCi ist also sehr viel schneller als bc und Python, zudem geht die Definition eigener Funktionen leichter von der Hand. Beispiel:

1

> bc:      define f(x,y){return 2*x+3*y}

2

> Python:  def f(x,y):return 2*x+3*y

3

> GHCi:    f x y=2*x+3*y

4

>

Ja, das mag sein. BC ist allerdings auch älter und wenn man den Umgang mit bc gewohnt ist, dann braucht man für gewöhnlich nichts anderes. Aber der Threadstarter ist ja noch auf der Suche, dann kann er ja die anderen zwei nehmen, gesetzt den Fall, der Zahlenbereich ist nicht endlich.

Es ist gefühlt schon immer so, dass der Windows-Rechner nicht richtig rechnen kann. Definitiv seit Windows XP, vielleicht auch schon bei Windows 3.1

Krude schrieb:

Den Ausdruck (2^9999999+1) kann MicroPython Ruck-Zuck mit großer Präzision berechnen.

(2^9999999+1) 10000002

Das Ergebnis ist komplett falsch. Bitte beachte, die 9999999 sind ein Exponent!

Das richtige Ergebnis ist viel zu lang um es hier zu posten, es beginnt aber mit 452490865318 und endet auf 93554689

Im Terminal sind das Gefühlt vermutlich ca. 5000 Zeilen bei denen jede mit 68 Ziffern belegt ist, damit der Wert reinpasst, deswegen poste ich das hier jetzt auch nicht.

MicroPython rechnet also schon einmal falsch oder du hast den Fehler gemacht, die Rechnung richtig in MicroPython Syntax zu übertragen. Probiere mal zweimal den Sternoperator anstatt ^.

Nano schrieb:

Das bedeutet dann aber auch, dass der Zahlenbereich, mit dem Python rechnen kann, endlich ist.

Na dann probier doch den hier mal und berichte… ;-)

1

#!/usr/bin/python3

2

# -*- coding: UTF-8 -*-

3

n = 1

4

for i in range(1_000_000):

5

    n = n * 2

6

print(f'{i}: {n}')

Wer alte Taschenrechner geliebt hat, kann sie emuliert online nutzen

https://archive.org/details/calculatordrawer

Yalu X. schrieb:

Der bc rechnet intern im Dezimalsystem, d.h. im BCD-Format

Ja, genau das meinte ich. Und das BCD Format sind halt aneinandergekettete Werte, also keine Datentypen mit fester breite.

während Python und der GHCi m.W. rein binär rechnen.

Und was machen die, wenn der Binärwert nicht mehr ins Register passt?

Der Wertebereich der Integerzahlen ist bei allen drei Programmen nur durch die Speichergröße begrenzt. Der durch eine Variable belegte Speicher passt sich dynamisch der Größe der Zahl an. In Python ist bei der Konvertierung von Integers in dezimale Strings die Stellenzahl auf 4300 Ziffern begrenzt, um Denial-of-Service-Attacken zu verhindern. Die Begrenzung kann aber erhöht oder auch ganz aufgehoben werden. Das habe ich beim obigen Test auch getan, da das Ergebnis 3010300 Stellen hat.

Ok.

Nano schrieb:

Versuch mal größere Zahlen, z.B. 2^99999999999999999999999999999

Nichts leichter als das:

14069306185920013413899835338678923..99545946690011303871870040893554688

Dazwischen stehen noch 30102999566398119521373889402 weitere Ziffern, die vermutlich die maximal erlaubte Länge eines Forenbeitrags sprengen würden. Wenn du mir einen ausreichend großen USB-Stick zukommen lässt, werde ich dir die komplette Zahl liefern.

Ich überprüfe jetzt nicht ob das Ergebnis stimmt, die Rechnung dauert auf meinem alten Rechner mir auch zu lange.

Was sagt bc dazu? Kommt er auf das gleiche Ergebnis?

Keine Ahnung, probier es einfach aus.

Simon schrieb:

(prx) A. K. schrieb:

Manche sind darüber unglücklich, dass er im Standard-Modus keine Punkt-vor-Strich Rechnung durchführt, sondern strikt der Reihe nach vorgeht.

Hatten wir das Thema nicht schon einmal? Ich glaube, dass die Erklärung war, dass einige "kaufmännische" Rechner so arbeiten.

Gruß Simon

Nein, der Grund liegt eher daran, weil die 8087 FPU (der Co-Prozessor) stackbasiert ist und somit keine klassischen individuell ansprechbaren Register wie die Haupt CPU (8086) hat. Die Daten kommen beim x87 auf den Stack der FPU und werden daher der Reihe nach verrechnet und CALC.EXE nutzt sehr wahrscheinlich den 8087 Co-Prozessor wenn der da ist. https://en.wikipedia.org/wiki/Intel_8087#Registers

Das ist so, seit der ersten Windows 1.0 Version, wie man hier leicht online ausprobieren kann: https://www.pcjs.org/software/pcx86/sys/windows/1.00/

Der wissenschaftliche Modus, der richtig rechnet, wurde erstmals in Windows 3.0 eingeführt: https://www.pcjs.org/software/pcx86/sys/windows/3.00/

Man hat also lediglich das Standardverhalten beibehalten um niemanden zu verwirren und an das sich alle gewöhnt haben. Das gilt dann auch für Neuimplementierte Versionen in Windows 10. Und die Ursache warum die erste Version, die noch auf dem 8086 und 8087 lief, das so machten liegt an der Art und Weise, wie der x86 Co-Prozessor die Werte ablegt, nämlich auf seinem Stack.

Wollte man mit dem Stack die Punkt vor Strich Rechnung beachten, dann muss das speziell behandelt werden, es würde also kompliziert werden und der Taschenrechner bräuchte mehr Code und somit mehr RAM. Und damals war das in Zeiten von Windows 1.0, welches noch im Real Mode lief, sehr knapp. Immerhin musste der Nutzer erst DOS booten und dann Windows starten, da blieb nicht mehr viel Speicherplatz im Real Mode für Anwendungen übrig. Der Real Mode bot maximal nur 640 KiB konventionellen Speicherplatz, lediglich mit Tricks wie EMS/XMS war etwas mehr möglich, aber Windows im Protected Mode gab es erst ab Windows 3.0 im Standard bzw. Erweiterten Modus.

Im Real Mode war also nicht genug RAM vorhanden und wenn der Taschenrechner dann nur eine Unterstützung für eine andere laufende Anwendung sein sollte, dann durfte der natürlich nicht viel RAM benötigen.

Die Geschichte mit "kaufmännische" Rechner kann man daher zu den Urban Legenden zählen.

Nano schrieb:

Die Daten kommen beim x87 auf den Stack der FPU und werden daher der Reihe nach verrechnet

Bzw. nach dem FIFO Prinzip.

Ach ja, Dateigröße von CALC.EXE

in Windows 1.0 CALC EXE 24352 7-11-85 3:43p

in Windows 3.0 ohne Hilfedatei: CALC EXE 26038 5-01-90 3:00a

Nano schrieb:

Die Geschichte mit "kaufmännische" Rechner kann man daher zu den Urban Legenden zählen.

Herzlichen Dank für diese ausführliche Erklärung!

Lieben Gruß, Simon

Nano schrieb:

Nein, der Grund liegt eher daran, weil die 8087 FPU (der Co-Prozessor) stackbasiert ist

Sofern der überhaupt vorhanden war. Laut dem Wiki-Artikel zum 8087 kam man zuerst ganz gut ohne aus, (weiß ich noch, beim Samplen war das eher ein Gimmick, um eine bessere Auflösung zu bekommen). (https://www.amazona.de/history-sounds-e-mu-emulator-ii-video-doku/)

Dann gab es Softwareansätze, vorzugsweise als TSR-Programm: https://de.wikipedia.org/wiki/Intel_8087

Zeno schrieb:

(prx) A. K. schrieb:

Manche sind darüber unglücklich, dass er im Standard-Modus keine Punkt-vor-Strich Rechnung durchführt

Das ist natürlich wirklich schlimm, da muß man sich ja selbst Gedanken über den Rechenablauf machen, damit man ein korrektes Ergebnis erhält. Da der TO einen wissenschaftlichen Taschenrechner möchte (Punkt 1 seiner Anforderung) könnte man bei dem Rechner ja "Wissenschaftlich" einstellen, dann mach er auch Punkt vor Strich. Er merkt sich sogar die Einstellungung bis zum nächsten Mal.

Ich finde das schon wirklich schlimm. Er schreibt ja sogar im Display "20-5*" was den Eindruck vermittelt das er noch wartet was multipliziert werden soll und nicht vorab schon 20-5 ausrechnet.

20-5*5=75 laut Microsoft...

Naja.

@ STM32 User (Gast)

Meiner sagt -5! (!0 pr0 64 byte!

So what?

Grüße vom Rechner

Rechner schrieb:

Meiner sagt -5!

-120? -5*-4*-3*-2*-1

(das spuckt Google auf nem Rechner-GUI aus, wenn man -5 als Suche eingibt) (dieser Google-Rechner ist auch gar nicht so übel) -5 * (8+16)^2 -> ..

rbx schrieb:

Nano schrieb:

Nein, der Grund liegt eher daran, weil die 8087 FPU (der Co-Prozessor) stackbasiert ist

Sofern der überhaupt vorhanden war. ... Laut dem Wiki-Artikel zum 8087 kam man zuerst ganz gut ohne aus, ...

Ja, der Co-Prozessor musste nachträglich gekauft und dann eingebaut werden und die meisten Anwendungen und Anwender kamen auch ohne aus. Nur mit war es halt in den Fällen, wo die Anwendung davon Gebrauch machte und profitierte, schneller. Die meisten Nutzer dürften keinen Co-Prozesser gehabt haben, mein 286er hatte auch keinen, in dem Fall wurden solche Rechnungen dann in Software mit dem Hauptprozessor berechnet, das dauerte entsprechend länger, aber wenn der Co-Prozessor vorhanden war und die Anwendung den unterstützte, dann ging es natürlich schneller. Die Anwendung musste für den natürlich entsprechend programmiert sein und ihn unterstützen, wovon ich bei CALC.EXE mal ausgehe.

Ein Disassembly von CALC.EXE dürfte hier genauer Aufschluss geben. Ohne Einwilligung des Herstellers dürfte das aber nicht in Deutschland erlaubt sein. https://www.gesetze-im-internet.de/urhg/__69e.html

Standardmäßig war eine FPU erst ab dem 486DX im Hauptprozessor enthalten. Beim 486SX war die FPU bei den ersten Versionen zwar enthalten, aber deaktiviert. Die 486er Mainboards waren deswegen die letzten Mainboard, wo man einen Co-Prozessor nachrüsten konnte, also ein extra Sockel vorhanden war. Besitzer eines 486SX konnten dann einen 487 Co-Prozessor nachrüsten.

Dann gab es Softwareansätze, vorzugsweise als TSR-Programm: https://de.wikipedia.org/wiki/Intel_8087

Ja, die Berechnung über eine Emulation eines x87 war allerdings langsamer als eine reine direkte Berechnung in Software mit der Haupt-CPU.

Hier gibt es einen direkten Geschwindigkeitsvergleich zwischen einem 8086 ohne 8087 und einem 8086 mit 8087:

https://www.youtube.com/watch?v=BhgifTBUWDM

https://www.youtube.com/watch?v=FaQa9INqZf8

https://www.youtube.com/watch?v=SGCUErENKBA

J. S. schrieb:

Nano schrieb im Beitrag #7334605: …

Absurd. Die Softwerker waren damals also zu dumm für einfache Mathematik und ein PC zu schwach um ein paar Werte im Speicher zu halten?

Das habe ich nicht gesagt, aber es wäre der einfachste Weg die FPU zu nutzen.

Windows 1.0 war damals im Microsoft Haus noch kein besonderes wichtiges Programm und die Zusatzgimmicks eher Spielerrei, während ein guter Programmierer mit guten Assemblerkenntnissen pro Stunde einen Haufen Geld kostete. Den setzt du eher woanders ein, als bei so einem Gimmick.

(prx) A. K. schrieb:

Nano schrieb:

Nein, der Grund liegt eher daran, weil die 8087 FPU (der Co-Prozessor) stackbasiert ist und somit keine klassischen individuell ansprechbaren Register wie die Haupt CPU (8086) hat.

Es besteht mit Sicherheit kein Zusammenhang zwischen dem Taschenrechner von Windows und dem Befehlssatz des optionalen 8087 Koprozessors.

Wenn du die Operanden Quick & Dirty einfach auf den FPU Stack schiebst, dann schon. Der FPU Stack spricht stark dafür.

Und wie in meinem vorherigen Posting erwähnt, gehe ich nicht davon aus, dass sich jemand lange mit der ersten Version von CALC.EXE beschäftigt hat. Das war mehr Spielerrei, als eine wichtige Applikation für die man viele teure Stunden eines Fähigen Programmierers ansetzt.

Und wenn das nur eine Spielerrei ist um Windows 1.0 zu zeigen, dann passieren genau solche Vereinfachungen. Und die Stackbasierte Funktionsweise des x87 lässt den Programmierer auf diese Vereinfachung geradezu hinarbeiten, weil es am schnellsten zu implementieren geht.

Obendrein: Operator-Vorrang wie Punkt vor Strich muss im Parser berücksichtigt werden, also der Interpretation der Eingaben, unabhängig von der Umsetzung in die Berechnung.

Ich würde hier nicht von einem komplexen Parser ausgehen. Eher von einem einfachen Parser, der verbotene Eingaben, wie bspw. Buchstaben aussortiert und dann die Operanden gleich auf den Stack schiebt. Quick and Dirty eben.

CALC.EXE war, wie bereits gesagt nur ein Gimmick für Windows 1.0 um etwas zeigen zu können, das ist kein Excel.

Yalu X. schrieb:

Python braucht für die Berechnung sogar nur 10s, die Ausgabe habe ich aber nicht abgewartet, weil sie nach meinen bisherigen Erfahrungen wohl Tage dauern würde.

Ok, dann muss man für große Exponenten in Zukunft Python nehmen.

Nano schrieb:

Nein, der Grund liegt eher daran, weil die 8087 FPU (der Co-Prozessor) stackbasiert ist und somit keine klassischen individuell ansprechbaren Register wie die Haupt CPU (8086) hat.

Du glaubst doch nicht allen Ernstes, dass calc.exe in Hardcore-Assembler mit direktem Zugriff auf die 80387-Register geschrieben wurde?

Nein, der Rechner ist mit ziemlicher Sicherheit in C geschrieben worden, wo der Programmierer mit der zugrunde liegenden Hardwarearchitektur gar nicht in Berührung kommt. In C kannst du sehr viel mehr double-Variablen anlegen als der Koprozessor Register hat. Des Weiteren läuft calc.exe auch auf PCs ohne Koprozessor, weswegen die Software sogar ganz ohne FP-Register auskommen muss.

Doch, weil in Zeiten von Windows 1.0 noch viel in Assembler im Haus von Microsoft programmiert wurde. C only wurde im MS Haus erst bei Windows NT und auf Win32 und Win32s basierte Anwendungen zwingend.

Bei Windows 1.0 aber, welches im April 1987 erschien, war Speicherplatz immer noch knapp und gerade auf Windows sollten ja Programme aufsetzen, die dann unter Windows laufen sollten. Da durfte Windows und seine Gimmickprogramme selbst gar nicht viel Speicherplatz verbrauchen, damit die Programmierer von Drittanbietern bereit waren, ihre Anwendung für Windows zu programmieren.

Die Lösung war also, dass man Windows 1,0 und seine Gimmicks überwiegend in Assembler programmierte.

Und viele Drittanbietersoftware für Windows < 3.0 bzw. Windows im Real Mode gab es dann ja auch nicht, die meisten Dritthersteller hatten damals schon unter DOS mit dem knappen Speicherplatz zu kämpfen und programmierten ihre Anwendung daher lieber direkt für DOS.

Die Vorteile die für Windows sprachen kamen erst mit Windows 3.0, das den Protected Mode und somit Zugriff auf sehr viel Speicher erlaubte und bei dem sich der Programmierer nen Haufen Arbeit durch die Abstraktion durch Windows sparte. Mit dem Enhanced Mode von Windows 3.0 waren dann die Weichen gestellt, WfW lief nur im Enhanced Mode und machte sich nicht einmal mehr die Mühe den Standard Mode zu unterstützen. Dafür war dann ein 386er notwendig und der erlaubte auch linearen Zugriff auf den Speicher ohne 64 KiB Segmentierung. Ab Windows 3.0 wird meines Wissens nach der Co-Prozessor sogar emuliert, falls keiner vorhanden ist.

Zu Zeiten von CALC.EXE, welches mit Windows 1.0 erschien, war das aber noch nicht so. Übrigens rechnet CALC.EXE von Windows 1.0 die Werte sofort aus, es wartet nicht darauf, bis man den ganzen Term ausgerechnet hat, sondern es bildet sofort die Summe, nach dem man zwei Operanden und den Operator dazwischen eingegeben hat.

So etwas ist auf der FPU kindereinfach zu realisieren.

Ganz abgesehen davon haben auch Rechner mit algebraischer Eingabe (also auch calc.exe) einen Stack (sei es in Hardware oder in Software). Er wird für Zwischenergebnisse benötigt, die entstehen, wenn die Auswertung nicht strikt von links nach rechts, sondern auf Grund von Klammern oder der Punkt-vor-Strich-Regel in einer anderen Reihenfolge erfolgt.

Ja, dieses Punkt vor Strich musst du aber entsprechend behandeln, das kriegst du nicht geschenkt.

CALC.EXE von Windows 1.0 ist sogar noch älter, wie der ABOUT Dialog zeigt. Da steht Copyright 1985 dran.

rbx schrieb:

Rechner schrieb:

Meiner sagt -5!

-120? -5*-4*-3*-2*-1

Fakultät mit negativen Ganzen Zahlen? Da müßte eigentlich ein Fehler kommen, da die Fakultätsfunktion nur für den Bereich der Natürlichen Zahlen deiniert ist(s. hier https://de.wikipedia.org/wiki/Fakultät_(Mathematik)).

(prx) A. K. schrieb:

Nano schrieb:

Wenn du die Operanden Quick & Dirty einfach auf den FPU Stack schiebst, dann schon. Der FPU Stack spricht stark dafür.

Du weiss, was ein Parser ist? Entweder kann der Operator-Vorrang, oder er kann nicht. Die natürliche Basis eines einfachen Parsers mit direkter Ausführung ist eine Stack-Maschine. Eine Akku- oder Registermaschine macht die Sache komplizierter.

Mit direkter Ausführung, wenn du aber Punkt vor Strich beachten willst, dann kannst du eben nicht direkt ausführen, sondern du musst warten, bis der vollständige Term eingegeben wurde. Und dann musst du den Term parsen. Dieser Parser ist komplexer als einer, der nur darauf achten muss, dass erlaubte Zeichen eingegeben werden und sie dann auf den Stack schiebt, wobei sie dort dann sofort verrechnet werden.

(prx) A. K. schrieb:

Und was hat das mit einer FPU zu tun?

Sie hat von Haus einen Stack und bietet bspw. mit FSQRT dem Wurzeloperator einen etwas komplexeren Operator an, der von CALC.EXE ohne großen Aufwand benutzt werden könnte. CALC.EXE kann im einfachen Modus die Wurzel ziehen, das muss also irgendwie implementiert worden sein, lediglich so Sachen wie Expontent und trigonomische Funktionen fehlen in diesem Modus noch.

Mit komplexeren Operator ist hier gemeint, dass man bei einem normalen Prozessor den in Software schon aufwendiger mit den Grundrechenarten programmieren müsste. Das Heron-Verfahren zum Wurzel Ziehen müsstest du bspw. unter Verwendungen des klassischen Hauptprozessors in Software implementieren, das kriegst du also nicht geschenkt. Mit der FPU ist das Wurzelziehen quasi geschenkt. Es bietet sich also an, die FPU dafür zu nutzen.

Und ja, natürlich musst du die Software Implementierung trotzdem machen, für die Rechner, die keine FPU haben, aber wenn sie eine haben, dann wird es mit der FPU ganz einfach und übrigens auch schneller. Das nimmst du als Programmierer also nebenbei mit.

Zeno schrieb:

Fakultät mit negativen Ganzen Zahlen? Da müßte eigentlich ein Fehler kommen,

Hätte ich auch gedacht, aber sowohl die Google-Suchmaschine als auch die WolframAlpha-Seite spucken bei -5! -120 aus.

Mal was interessantes: https://www.youtube.com/watch?v=5mBw7tnRx1c