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
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.
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.
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.
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.
(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.
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.
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?
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.
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.
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 NOGOFake 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.
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();
}
}
}
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.
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.
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!
(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.
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.
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,
...
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…
> 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
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:
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.
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.
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.htmlhttp://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.
●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.
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:
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.
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:>>
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.
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… ;-)
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?
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 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:
…
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.
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. ;-)
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.
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=BhgifTBUWDMhttps://www.youtube.com/watch?v=FaQa9INqZf8https://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.
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.
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.
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.
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.
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)!.
Thread beobachten
Seitenaufteilung abschalten