Hallo, ich suche ein "Taschenrechner"-Programm für Windows: - Wissenschaftlicher Taschenrechner - klein und kompakt (startet in <1s) - kein UPN - Freeware 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
Das bringt Windows doch schon mit. Also bis win 7 war das so...
:
Bearbeitet durch User
Thomas schrieb: > - Die "Qualität" des von MS mitgelieferten calc.exe Bezieht sich das nur auf den aktuelle vermurksten von Win10/11? - https://www.deskmodder.de/wiki/index.php/Alten_Taschenrechner_calc.exe_unter_Windows_10_starten - https://www.chip.de/downloads/Old-Classic-Calculator-for-Windows-10-und-Windows-11_81775847.html
Thomas schrieb:
> Bezieht sich das nur auf den aktuelle vermurksten von Win10/11?
Was ist am Taschenrechner von Windows 10 bzw. 11 vermurkst?
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.
Jochen schrieb: > Was ist am Taschenrechner von Windows 10 bzw. 11 vermurkst? Manche sind darüber unglücklich, dass er im Standard-Modus keine Punkt-vor-Strich Rechnung durchführt, sondern strikt der Reihe nach vorgeht.
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
Schlaumaier schrieb: > Das ist ein klares NOGO. Einfach gesagt ein BUG der aus der Steinzeit > kommt. It's not a bug, it's a feature. Im wissenschaftlichen Modus ist das anders. Das adressiert Personen, die zwar eine Maus schubsen können, denen aber mathematische Grundlagen wie eben jene Punkt-vor-Strich Regel abgeht. In diesem Forum stellen die aber (hoffentlich) eine Minderheit dar.
Beitrag #7332728 wurde von einem Moderator gelöscht.
Fake Friends schrieb im Beitrag #7332728: > (prx) A. K. schrieb: >> Das adressiert Personen, die zwar eine Maus schubsen können, denen aber >> mathematische Grundlagen wie eben jene Punkt-vor-Strich Regel abgeht. > > Schwachsinn. Elfenbeinturmbewohner. Solche Personen gibt es und sie nutzen PCs.
:
Bearbeitet durch User
Fake Friends schrieb im Beitrag #7332728: > 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.
Beitrag #7332744 wurde vom Autor gelöscht.
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.
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.
(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. Der Gag ist - so habe ich es vor viiielen Jahren mal aufgeschnappt -, dass im Standard-Modus die seinerzeit verbreiteten einfachen Taschenrechner nachgebildet werden sollten, welche "Punkt vor Strich" nicht beherrschten. Anders gesagt, der Standard-Modus ist absichtlich blöd programmiert worden. Das verstehe wer wolle.
> Wissenschaftlicher Taschenrechner Wissenschaftlicher Taschenrechner für Desktop: https://support.microsoft.com/en-us/office/excel-functions-alphabetical-b3944572-255d-4efb-bb96-c6d90033e188
Spricht denn grundsätzlich was gegen Windows Calc in der wissenschaftlichen Ansicht? Habe eine alte Version für Win 10 in der klassischen Optik. Läuft auch unter Win 8. Gibt es z.B. hier: https://www.chip.de/downloads/Old-Classic-Calculator-for-Windows-10-und-Windows-11_81775847.html Gruß Achim
Ja, der W10/11 Rechner ist vermurkst, kann im wissenschaftlichen Mode kein Hex. Daher einfach den Microsoft Rechner-Plus installieren.
Peter D. schrieb: > Ja, der W10/11 Rechner ist vermurkst, kann im wissenschaftlichen Mode > kein Hex. Für was braucht man das?
Hallo, an Schlaumeier und Fake Friends: Rainer Z. schrieb: > Der Gag ist - so habe ich es vor viiielen Jahren mal aufgeschnappt -, > dass im Standard-Modus die seinerzeit verbreiteten einfachen > Taschenrechner nachgebildet werden sollten, welche "Punkt vor Strich" > nicht beherrschten. Und genau so ist es. Selbst aktuelle kaufmänische Tischrechner beherrschen keine Punkt-vor-Strich-Rechnung. Und der einfache Rechner in Windows bildet das einfach nur nach. Ab man kann das Problem einfach umgehen, indem man den wissenschaftlichen Modus nutzt. rhf
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.
Peter D. schrieb: > Ja, der W10/11 Rechner ist vermurkst, kann im wissenschaftlichen Mode > kein Hex. Dafür aber im Programmierer-Modus.
:
Bearbeitet durch User
X2 schrieb: > Peter D. schrieb: >> Ja, der W10/11 Rechner ist vermurkst, kann im wissenschaftlichen Mode >> kein Hex. > > Für was braucht man das? Und braucht das der TO?
Hallo, Schlaumaier schrieb: > 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. Stimmt, und genau so hast es Mircosoft ja auch gemacht: - Rechner starten - oben links auf die 3 waagerechten Striche klicken - in erscheinenden Menü auf "Wissenschaftlich" klicken rhf P.S. Mal so nebenbei, wofür nutzt du eigentlich die Standard-Version?
Zeno schrieb: > Was ist an dem Taschenrechner unter Win10/11 so schlecht? Eigentlich alles, eine Witznummer. Aber es gibt Linderung: https://apps.microsoft.com/store/detail/realcalc-scientific-calculator/XPDNLFS3S1GN06 https://realcalc-scientific-calculator.en.softonic.com/windows/alternatives/free
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
der Windows 10 Rechner ist doch sehr brauchbar, auch Funktionsplot und Umrechnungen sind mittlerweile eingebaut. Die Quellen sind auf github, und das der Standardmode keine Punkt vor Strich macht ist gewollt und auch schon ewig so:
1 | Features |
2 | |
3 | Standard Calculator functionality which offers basic operations and evaluates commands immediately as they are entered. |
4 | Scientific Calculator functionality which offers expanded operations and evaluates commands using order of operations. |
https://github.com/Microsoft/calculator Was mir fehlt ist die TI-59 Emulation. Hatte ich mal installiert, aber nach neuem Rechner nicht wieder nachgeholt. Sollte es aber noch geben. Genau wie die HP mit UPN, die gibt es auch als Emulation, auch auf dem Smartphone.
:
Bearbeitet durch User
Hier gibt es den mit Abstand besten wissenschaftlichen Rechner für Windows und die meisten anderen Betriebssysteme: https://www.python.org/ Die Wissenschaft wird dabei mit folgendem $PYTHONSTARTUP konfiguriert:
1 | from math import * |
2 | # from cmath import * |
3 | # from mpmath import * |
4 | import numpy as np |
5 | from scipy import constants as const |
6 | # import matplotlib.pyplot as plt |
Die mit "#" markierten Zeilen (komplexe, beliebig genaue und Plot-Funktionen) sind optional und können je nach Bedarf zugeschaltet werden. Weitere Funktionen sind natürlich jederzeit nachrüstbar. Es gibt fast nichts, was es nicht gibt. Programmierbar ist der Rechner natürlich auch.
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
Der nette Onkel schrieb: > Gibt es eigentlich einen plausiblen Grund, weshalb kaufmännische > Taschenrechner kein Punkt-vor-Strich beherrschen? dürfte historisch sein, dafür braucht man ja RAM um Zwischenzuspeichern. Auch die Anzahl der Klammerebenen war limitiert, wenn die Rechner überhaupt die Klammerfunktion hatten.
> * "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 % +
Der nette Onkel schrieb: > Gibt es eigentlich einen plausiblen Grund, weshalb kaufmännische > Taschenrechner kein Punkt-vor-Strich beherrschen? Ganz einfach: Kaufleute können damit nicht umgehen. Sie haben das Rechnen auf solchen Maschinen https://upload.wikimedia.org/wikipedia/commons/d/d5/Mechanical_desktop_calculator_Walther_Multa_32.jpg (es gibt auch modernere Ausführungen) gelernt und sind es gewohnt, dass jeder einzelne Rechenschritt sofort auf dem Drucker protokolliert wird. Das ist mit algebraischer Notation nicht sinnvoll realisierbar. Aus demselben Grund haben kaufmännische Rechner i.Allg. auch keine Klammertasten. Aber darum geht is in diesem Thread gar nicht. Der TE sucht ja nach einem wissenschaftlichen Rechner ohne UPN. Solche Rechner haben praktisch ausnahmslos algebraische Notation mit Punkt vor Strich.
:
Bearbeitet durch Moderator
Danke, ein paar interessante Kandidaten sind dabei. Favorit bis jetzt: SpeedCrunsh.
Angehängte Dateien:
-
Windows_Calculator.png
110 KB
Seit wann macht Windows Taschenrechner die Funktionsanalyse? Weiß jemand?
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: > 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
Beitrag #7333148 wurde von einem Moderator gelöscht.
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; public CalculatorForm() { InitializeComponent(); } private void btnOne_Click(object sender, EventArgs e) { txtDisplay.Text = txtDisplay.Text + btnOne.Text; } private void btnTwo_Click(object sender, EventArgs e) { txtDisplay.Text = txtDisplay.Text + btnTwo.Text; } // Weitere Eventhandler für die anderen Zifferntasten private void btnAdd_Click(object sender, EventArgs e) { num1 = double.Parse(txtDisplay.Text); operation = '+'; txtDisplay.Text = ""; } private void btnSubtract_Click(object sender, EventArgs e) { num1 = double.Parse(txtDisplay.Text); operation = '-'; txtDisplay.Text = ""; } // Weitere Eventhandler für die anderen arithmetischen Operationen private void btnEquals_Click(object sender, EventArgs e) { num2 = double.Parse(txtDisplay.Text); switch (operation) { case '+': result = num1 + num2; break; case '-': result = num1 - num2; break; case '*': result = num1 * num2; break; case '/': result = num1 / num2; break; case '%': result = num1 % num2; break; case '^': result = Math.Pow(num1, num2); break; default: MessageBox.Show("Invalid operator"); return; } txtDisplay.Text = result.ToString(); } } }
Angehängte Dateien:
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.
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? ;-)
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.
Für flüchtige Berechnungen mit wenigen Rechenoperationen kann man noch den "Taschenrechner" benutzen. Aber Excel bietet die Möglichkeit, die ganze Rechnerei retrospektiv zu analysieren und Korrekturen in der "Vergangenheit" vorzunehmen.
Angehängte Dateien:
-
s-l1600.jpg
200 KB
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.
Schlaumaier schrieb: > 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. > ... > Weshalb ich halt wie oben auch erwähnt, EXCEL o. mein 1401 nehme. Na, dann mach mit Excel mal die Testrechnung -3^2. Ist das Ergebnis -9? Nein? Oder probier mal 2^2^3. Ist das Ergebnis 256? Nein? Hat Excel also gleich zweimal versagt? Schlaumaier schrieb: > Das ist ein klares NOGO. Einfach gesagt ein BUG der aus der Steinzeit > kommt. Schlaumaier schrieb: > Ist das Ergebnis falsch nutzt ich das Teil nicht. > ergo WEG DAMIT. Genau, hau dein Excel in die Tonne!
:
Bearbeitet durch Moderator
(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 macht doch jeder Taschenrechner, es sei denn, man verwender Klammern?
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.
Zeno schrieb: > ...es gibt mittlerweile Taschenrechner die schreiben die komplette > Eingabezeile hin bzw. merken sich diese und rechnen erst mit Druck auf > die = Taste. 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. Vorteile für mich: - man kann die gesamte Rechnung eintippen, - jederzeit zurückholen und editieren - benannte Variablen verwenden, - diese ändern und die Rechnung mit dem neuen Wert wiederholen, - mit komplexen Zahlen rechnen, - mit Vektoren und Matrizen rechnen, ...
:
Bearbeitet durch User
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…
Yalu X. schrieb: > Na, dann mach mit Excel mal die Testrechnung -3^2. > Ist das Ergebnis -9? Interessant! Das habe ich bis eben nie probiert...
> 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
Manfred schrieb: >> Na, dann mach mit Excel mal die Testrechnung -3^2. >> Ist das Ergebnis -9? >> Nein? > > Da bekomme ich -9, was ich Fehler ansehe. Doch, nach Konvention ist -3^2 = -(3^2): https://de.wikipedia.org/wiki/Punktrechnung_vor_Strichrechnung#Weitere_Vorrangregeln Excel liefert aber 9, was nicht der Konvention entspricht. Auch SoftMaker FreeOffice PlanMaker 2021 (rev F1060.1203) 64bit liefert bei mir 9. Manfred schrieb: >> Oder probier mal 2^2^3. >> Ist das Ergebnis 256? >> Nein? > > Da bekomme ich 64, was ich korrekt finde. Nein, nach Konvention ist 2^2^3 = 2^(2^3): https://de.wikipedia.org/wiki/Operatorrangfolge#Reihenfolge_gleichwertiger_Operatoren Hier gibt es auch eine Begründung dafür: https://en.wikipedia.org/wiki/Order_of_operations#Serial_exponentiation Dass einige Taschenrechner, Tabellenkalkulationsprogramme und Programmiersprachen von diesen und anderen Konventionen abweichen, hat teils technische, teils aber auch praktische Gründe. Bei UPN-Rechnern entfällt die diesbezügliche Verwirrung komplett, was mit ein Grund ist, warum ich solche Rechner bevorzuge.
:
Bearbeitet durch Moderator
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 |
Meine Empfehlung für Windows (nach Python): SpeQ Mathematics, https://speqmath.com/ Klein, schnell, mächtig, wird leider nicht weiterentwickelt, läuft aber seid Jahren fehlerfrei.
Norbert schrieb: > $ python3 -c "print(-3**2)" > -9 Ja, Python hält sich an die Konvention, ebenso hier:
1 | $ python3 -c "print(2**2**3)" |
2 | 256 |
Auch Haskell (eine Sprache mit einem starken mathematischen Fundament) macht es richtig:
1 | ghci> -3^2 |
2 | -9 |
3 | ghci> 2^2^3 |
4 | 256 |
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. > Ist einfacher. > > Ich benutzte das was ich selbst habe POTENZ ;) Ja, natürlich ist es sehr viel einfacher, POTENZ(3;2) statt 3^2 zu schreiben. Aus dem gleichen Grund schreibst du sicher auch SUMME(3;4) statt 3+4, PRODUKT(3;4) statt 3*4 und SUMME(3;NEG(4)) statt 3-4. Die kryptischen Operatorsymbole +, -, * sind ja schließlich des Teufels :)
Zeno schrieb: > 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. Nö, hier nich, nicht mal im Wissenschfs-Mode. :D Hängt das an Home/Pro? Ich hab ja nur Home. :´( Zeno schrieb: > Das automatische Einhalten der Rechenregeln ist zwar ein nettes Feature, > gebraucht habe ich es bisher noch nicht wirklich. Ich wüste nicht, wie ohne auskommen. Peter N. 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. > > Das macht doch jeder Taschenrechner, es sei denn, man verwender > Klammern? Nö, mein oller FX-115M beachtet die Regeln. Klammern braucht man da aber genauso ab und an.
dem netten onkel sein 5€ lidl taschenrechner benützt anscheinend die im englischen raum üblichere "polnische notation", dabei wird die rechenoperation der zahl nach gestellt . aber so richtig verstehe ich es auch nicht . ich brauche einen texas instruments ti30
Carypt C. schrieb: > englischen raum üblichere "polnische notation", dabei wird die > rechenoperation der zahl nach gestellt Die polnische Notation stellt die Operation davor, die umgekehrt polnische dahinter.
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.
Teo D. schrieb: >> Nö der Windows 7 Rechner ist da unter den Win Rechnern eine Ausnahme und >> macht auch im Standardmodus Potenz vor Punkt vor Strich. > Nö, hier nich, nicht mal im Wissenschfs-Mode. Sorry waren Fake-News. Mit Brille rechnet er richtig. :=}
Manfred schrieb: > Es müsste auch HP-Rechner in umgekehrt polnisch gegeben haben. UPN war früher typisch für HP Taschenrechner. Mir liegt diese Methode, aber da gehen die Ansichten auseinander.
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.
Hallo, Yalu X. schrieb: > Ja, natürlich ist es sehr viel einfacher, POTENZ(3;2) statt 3^2 zu > schreiben. Aus dem gleichen Grund schreibst du sicher auch SUMME(3;4) > statt 3+4, PRODUKT(3;4) statt 3*4 und SUMME(3;NEG(4)) statt 3-4. Die > kryptischen Operatorsymbole +, -, * sind ja schließlich des Teufels :) YMMD. :-))) rhf
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.
Yalu X. schrieb: > uch Haskell (eine Sprache mit einem starken mathematischen Fundament) > macht es richtig: Es gibt wohl keine Sprache mit stärkerer Anlehnung an mathematische Konzepte und Symbolik als APL. Aber nix mit Punkt vor Strich. Gerechnet wird strikt von rechts nach links, so lange keine Klammern stören. Yalu X. schrieb: > Doch, nach Konvention ist -3^2 = -(3^2): Wenn man es richtig macht, verwendet man für das Vorzeichen ein anderes Symbol als für die Negation, und schon ist der Fisch geputzt und alle Zweifel sind beseitigt: ¯3⋆2 vs −3⋆2.
:
Bearbeitet durch User
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.
J. S. schrieb: > Was mir fehlt ist die TI-59 Emulation. Hatte ich mal installiert, aber > nach neuem Rechner nicht wieder nachgeholt. Sollte es aber noch geben. Ich habe http://www.zanchetta.net/default.aspx?Categorie=CALCULATRICES&Page=TI59Emulator und bin ganz zufrieden; es scheint aber noch haufenweise andere zu geben. > Genau wie die HP mit UPN, die gibt es auch als Emulation, auch auf dem > Smartphone. Ti-59 auf dem Smartie finde ich tatsächlich wichtiger. Ein Nachteil des WIN-Calc ist der einzelne, wenngleich saldierende, Speicher.
Angehängte Dateien:
-
IMG_20230123_222828.jpg
220 KB -
IMG_20230123_222818.jpg
73 KB
vor kurzem gefunden... niggs Speicher oder gar eine "zurück-Taste" BTW, anno '69 ist man mit Rechenschiebern zum Mond geflogen.
●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.
Zeno schrieb: > Wenn ich mit Hex rechne, dann geht es eher weniger > "wissenschaftlich" zu. Ich rechne Konstanten in float aus, um Rundungsfehler zu vermeiden. Und erst zum Schluß brauche ich die ganzzahligen Bytes. Beim Rechner Plus geht das problemlos. Schaltet man aber beim Rechner ohne Plus die Ansicht um, ist der Wert weg.
:
Bearbeitet durch User
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. Eine weitere Option in der Klasse der klicki-bunti-freien Rechner ist der GHCi (ein interaktiver Haskell-Interpreter). 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 | ────────────────────────────────────────────────── |
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 |
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
Manfred schrieb: > Es müsste auch HP-Rechner in umgekehrt polnisch gegeben haben. Gab es eigentlich auch HP-Rechner ohne UPN? Ich kenne nur welche mit UPN.
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.
Krude schrieb: > Den Ausdruck (2^9999999+1) kann MicroPython Ruck-Zuck mit großer > Präzision berechnen. > >>>> (2^9999999+1) > 10000002 Der ^-Operator ist in Python XOR. Der Potenzoperator heißt hier **. Was oben gemeint ist liest sich in Python so: 2**9999999+1. Ich habe gerade einmal 2**999999+1 eingegeben, dauert wenige Sekunden. Mit einer 9 mehr dauert es mir zu lange (keine Ahnung, ob er mit Speicherüberlauf abbrechen würde. Ich muss das nicht ausprobieren, ich benötige das Ergebnis gerade nicht...).
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}') |
Nano schrieb: > 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 hatte ich bereits kommentiert: In Python ist ^ kein Potenzoperator! M.A. S. schrieb: > Der ^-Operator ist in Python XOR. Der Potenzoperator heißt hier **. > Was oben gemeint ist liest sich in Python so: 2**9999999+1. > Ich habe gerade einmal 2**999999+1 eingegeben, dauert wenige Sekunden. > Mit einer 9 mehr dauert es mir zu lange (keine Ahnung, ob er mit > Speicherüberlauf abbrechen würde. Ich muss das nicht ausprobieren, ich > benötige das Ergebnis gerade nicht...).
Nano schrieb: > Der bc wurde bisher oben nicht wirklich vorgeschlagen, sondern lediglich > zum Ausrechnen eines Wertes verwendet. Der Vorschlag kam von rbx: rbx schrieb: > Oder eben: > https://embedeo.org/ws/command_line/bc_dc_calculator_windows/ Nano schrieb: > 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. Alle drei Programme rechnen in erster Linie mit Zahlen ;-) Der bc rechnet intern im Dezimalsystem, d.h. im BCD-Format (ob gepackt oder nicht, weiß ich nicht), während Python und der GHCi m.W. rein binär rechnen. Deswegen ist der bc am langsamsten im Rechnen, dafür aber am schnellsten bei der Ausgabe, da dort keine aufwendige Konvertierung von binär nach dezimal erforderlich ist. 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. 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. Was sagt bc dazu? Kommt er auf das gleiche Ergebnis?
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
Nano schrieb:
…
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? Zu der Zeit habe
ich schon eine komplette Fakturierung auf dem PC programmiert, in 640
kB.
Wenn Speicher knapp war, dann in festverdrahteter Logik der ersten
elektronischen Rechner. Ein Speicher reichte den Kaufleuten da: Menge x
Preis = und dann M+. Damit war Rechnungen schreiben schon eine größere
Freude.
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.
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. 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. Die Berechnung wiederum ist auf einer Stack-Architektur einfacher umsetzbar, als auf einer direkt adressierenden Register-Architektur, weil Zuweisung von Zwischenspeicher automatisch erfolgt.
:
Bearbeitet durch User
J. S. schrieb: > PC zu schwach um ein paar Werte im Speicher zu halten? Versuch mal, über das Benutzerinterface eines Taschenrechners eine halbwegs realistische Formel hinzuschreiben, bei der ein Stack aus 8 Registern nicht für die impliziten Zwischenergebnisse ausreicht. Da verlierst du den Durchblick lange vor dem Taschenrechner. ;-)
:
Bearbeitet durch User
Nano schrieb: >> Was sagt bc dazu? Kommt er auf das gleiche Ergebnis? > > Keine Ahnung, probier es einfach aus. Ich war fast sicher, dass mein PC zu wenig Speicher hat und habe es deswegen zunächst nicht ausprobiert. Jetzt habe ich es dennoch gewagt:
1 | 2^99999999999999999999999999999 |
2 | Runtime error (func=(main), adr=35): exponent too large in raise |
Da ist also wohl der Exponent z groß. Der größte erlaubte Exponent scheint 2^31+1 = 2147483649 zu sein. Bei
1 | 2^2147483649 |
kommt zwar keine Fehlermeldung, aber das Ergebnis habe ich nicht abgewartet. Vermutlich würde das viele Tage dauern, wenn nicht vorher der Speicher überläuft. Python und der GHCi haben diese Beschränkung nicht. Der GHCi braucht für 2^2147483650 einschließlich der dezimalen Ausgabe 314s, die reine Berechnung dauert 15s. Der GHCi kann also mit so großen Exponenten gerade noch einigermaßen umgehen. 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. 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. 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.
:
Bearbeitet durch Moderator
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: > … > > 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.
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.
Nano schrieb: > Ich würde hier nicht von einem komplexen Parser ausgehen. Ich schon. Ein Parser ist zwingender Teil der Implementierung eines Taschenrechners in normaler Notation. Egal ob im PC simuliert oder in einem echten Taschenrechner. Egal ob mit oder ohne Vorrang. Natürlich ist er viel einfacher als ein Parser für C++, aber das ist nicht der Punkt. Es kann auch sein, dass jemand ein solches Programm entwickelt, ohne zu wissen, was ein Parser ist.
Nano schrieb: > Der FPU Stack spricht stark dafür. Cum hoc ergo propter hoc. Ob es eine FPU mit Stack gibt, oder einen in Software simulierten Stack, ist in diesem Kontext völlig unerheblich. Hinsichtlich Ressourcen war es das auch schon bei einem 8088 mit 64kB RAM.
:
Bearbeitet durch User
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.
Und was hat das mit einer FPU zu tun?
:
Bearbeitet durch User
(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.
Nano schrieb: > und übrigens auch schneller Was bei einem Taschenrechner ohne jede Relevanz ist. Zurück zur eigentlichen These: 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 spricht überhaupt nichts dagegen, eine Rechnung mit Operatorvorrang auf einer 8087 FPU durchzuführen. Genug Register hat sie. Direkte Adressierbarkeit von Registern ist dabei weder erforderlich noch vorteilhaft (obzwar vorhanden, nur eben relativ zum TOS). Nur braucht man dazu eben einen Parser, der Operatorvorrang beherrscht. Das bedeutet Arbeit für den Programmierer.
:
Bearbeitet durch User
Nano schrieb: > sondern du musst warten, bis der vollständige Term eingegeben wurde. Oder ein Teil davon abgeschlossen ist, etwa (...). Beim einfachen Punkt-vor-Strich Schema ist auch bei 2+2*3-1 mit dem "-" der Teil links davon abgeschlossen. Der effektive Unterschied liegt beim "*". Ohne Vorrang wird der bisherige Term wie bei "=" berechnet, mit Vorrang wird ebendieser erkannt und die "3" landet als dritter Wert auf dem Stack. Eine Formel vollständig einzusammeln und dann erst dann anzugehen kann sinnvoll sein, wenn der Rechner mit ausreichend grossem grafischem Display ausgestattet ist, um sie vollständig darstellen zu können, und er ggf nachträgliche Änderung zulässt. Das hat aber mit den Taschen- oder Tischrechnern der frühen Ära wenig zu tun.
:
Bearbeitet durch User
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.
rbx schrieb: > Hätte ich auch gedacht, aber sowohl die Google-Suchmaschine als auch die > WolframAlpha-Seite spucken bei -5! -120 aus. Ich hätte nichts anderes erwartet: -5! = -(5!). Problematisch wäre: (-5)!.
M.A. S. schrieb: > Ich hätte nichts anderes erwartet: > -5! = -(5!). > Problematisch wäre: > (-5)!. Zu überprüfen wäre noch -4 als Argument.
Der nette Onkel schrieb: > Qalculate: https://qalculate.github.io/ Der beste Rechner mit sinnigen UI !!!
Thread beobachten
Seitenaufteilung abschalten
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.