Hi, wie aus dem Titel schon ersichtlich, ist mein nächstes Projekt ein TR. Meine Herausforderung ist nicht bei der Hardware, sondern der Software. Warum noch ein Taschenrechnerprojekt? Ich besitze schon einen Taschenrechner, den Casio fx-991 DE PLUS, durch meine großen Hände und dem fehlendem Tastendruckspeicher komme ich nicht gut mit dem klar. Das Ziel ist kein direkter Nachbau, es werden deutlich weniger Funktionen benötigt. Die Hardware: Das ganze basiert auf einem Arduino Nano, der an 4 Analogpins mit je 25 Tastern+1% 470R Widerständen und 1 Analogpin mit einem Schiebepoti verbunden ist. 3 Digitalpins sind mit einem HC595 und Anoden von 8 7SegAnzeigen verbunden, 8 weitere mit den Kathoden der Segmente abcdefg(DP). Und ja, es gibt noch Widerstände und LED-Treiber. Und einen An/Aus Schalter. Hier sind alle Teile schon vorhanden, nur noch nicht alles gelötet. Wozu 4*25=100 Taster + Schiebepoti? 100 Taster, um eine 2stellige Zahl mit einem Tastendruck einzugeben. Das Schiebepoti, um den Faktor der Zahlen und eine Zweitbelegung der Tasten auszuwählen d.H. um 23.0014 einzugeben drückt man bei Faktor 1 auf die 23 und dann bei Faktor 0.0001 auf die 14. Das System ist recht praktikabel, das Schiebepoti wird mit der linken Hand und das Tastenfeld mit der rechten Hand bedient. Der geplante Funktionsumfang: - Eingabe von Zahlen - Grundrechenarten +-*/ - Verschachtelte Klammersetzung () - Potentieren und Wurzelziehen bis siebenfach, ^ und rt(a;b) - Konstanten pi und e - Abgespeicherte Formeln auf Tastendruck anzeigen - Selbst festlegbare und Änderbare Werte (im EEPROM Speichern?) - Fakultät ! (einfach intern iterativ multiplizieren) - Trigonomie sin() cos() tan() - Editieren der schon eingegebenen Formel - Zahlen mit 8 Nachkommastellen Genauigkeit - positive und negative Zahlen mit mind. 10 Stellen möglich - Scrollen innerhalb der Formel - Ausrechnen der Formel Klingt erstmal nach übertrieben viel. Ist es aber nicht. Grundrechenarten und Konstanten kann so ein µC locker, Potentieren ist wiederholte Multiplikation, Trigonomie ist schon eingebaut die Zahlenbereiche sind nicht übertrieben groß. Das schwierige ist die Klammersetzung und Editieren. Funktionen für ^, !, e, pi können als gegeben angesehen werden. Jetzt zur Frage: Ist es einfach, die sich in einem String befindliche Formel (z.B. "2+(34^2)-e") zu berechnen? Den String bearbeitbar zu erzeugen wäre für mich ohne Forenhilfe programmierbar. Oder sollte ich die Tastendrücke Speichern und daraus das Ergebnis erzeugen? Oder doch mit einem Weg, den ich noch nicht bedacht habe? Sonst noch Ideen? Und bitte lasst diesen Quatsch wie "fang erstmal damit an ne led blinken zu lassen". Das habe ich schon getan.
Paul S. schrieb: > Ist es einfach, die sich in einem String befindliche Formel (z.B. > "2+(34^2)-e") zu berechnen? Jein. Es ist einfach, wenn du mit float der Arduino sin und cos ausrechnest. Es ist nicht mal nötig, den Strong zu bilden, man kann gleich die Operatoren stacken und Operanden anwenden. Aber das sind nicht die gewünschten Ergebnisse. Eine float hat nur 6-7 Stellen und die letzten sind falsch. So schlechte rechneten die Taschenrechner in den 1970ger Jahren. Heute erwartet man, das auch 1 * 1/3 auch 1 rauskommt, heute rechnen alle Taschenrechner in BCD mit 13 Stellen von denen 3 nicht angezeigt werden sondern als Rundungs-Guard-Digits dienen, und sin und cos wird mit CORDIC Algorithmen im 10er System ausgerechnet. Und das ist SCHWER. Wie du mit 100 Tasten Zahlen von 00 bis 99 eingeben willst UND dann noch Operatoren wie + - * / sin con tan etc. befehlen willst, ist mir allerdings schleierhaft. Nicht doch 128 Tasten ?
MaWin schrieb: > Heute erwartet man, das auch 1 * 1/3 auch 1 rauskommt Ugh Heute erwartet man, das aus 3 * 1/3 auch 1 rauskommt
Tolles Vorhaben, mach hin: wirst viel dabei lernen! > Ist es einfach, die sich in einem String befindliche Formel (z.B. > "2+(34^2)-e") zu berechnen? Ja. Jedoch wird es auch Strings geben wie "2+*(34^2))-e" und da musst du merken dass es nicht geht. Oder "(-5)^-2" was zwar geht, aber eben... > Sonst noch Ideen? Ja: RPN (de: umgekehrte polnische Notation, postfix Notation) dürte ein paar Sachen vereinfachen.
@MaWin: es gibt eine zweitbelegung der Tasten, das reicht für 100 weitere Funktionen Also besser intern mit 11 stellen rechnen und die letzten 3 nicht anzeigen @Taschenrechtler: gute Idee mit rpn, das kenne ich zwar, habe aber nicht darüber im bezug auf dieses Projekt nachgedacht @Willi: gutes Stichwort, danke dafür
Potenzieren ist NICHT wiederholt multiplizieren. Beispiele: 2^0.5 Oder 2^(-1) Oder e^i Hast wohl nicht in Mathe aufgepasst. so einen Parser insbesondere in RPN lässt sich gut in Forth machen. fchk
Irrationale zahlen sind nicht gefordert, daher bin ich darauf nicht eingegangen Diese kleinen Ausnahmen sind halt extra definiert. Und 2^4=2*2*2*2, also wiederholt multipliziert so meinte ich das
Hm, der Sinn der zweistelligen Eingabe erschliesst sich mir überhaupt nicht. Schneller geht es auch nicht, wenn man auf so einem grossen Tastenfeld kreisen und suchen muss. Eingabe 758965,236 - jetzt muss man erstmal überlegen: beginne ich mit 07 oder mit 75? Oder beginnst du hinten? Dann wirds ja noch verrückter... Im Prinzip ist es aber ne schöne Sache, wo man sich gut austoben kann und auch was lernen kann. Irgendwann wollte ich das auch mal machen, habe es aber nie ernsthaft angefangen.
Man muss ja nicht das Rad neu erfinden. Vielleicht wäre das mal ein guter Einstieg. https://www.elektor.de/programmierbare-taschenrechner-selbst-gebaut-pdf
Wirth schrieb im Beitrag #4545126:
> Also lass es!
Und woran soll er wachsen?
Bevor Du Numerik aufgetischt bekommen hast, konntest auch Du keine
Numerik...
Nicht alle lernen per Einstieg in die Theorie, wobei sie sich fragen
wozu es je nützen soll; es gibt welche die stossen auf den Bedarf und
lernen es "aus Not".
> Im Prinzip ist es aber ne schöne Sache, wo man sich gut austoben kann > und auch was lernen kann. Trifft dies nicht auf 95% aller Sachen in diesem Forum zu? Nein? Also auf 98% oder doch 99,9%?
Einen einfaches Progrämmchen zur Auswertung eines als String gegebenen arithmetischen Ausdrucks in C-Syntax habe ich hier gepostet: Beitrag "Re: Weis jemand, wie man mathematische Ausdrücke in C++ auswert" Ein klassischer Taschenrechner liest allerdings nicht den kompletten Ausdruck als String ein, um ihn erst danach auszuwerten. Vielmehr geschieht die Auswertung schon währen der Eingabe mit laufender Ausgabe der Zwischenergebnisse. Dafür ist der obige Code nicht (oder nur nach Modifikation) geeignet. Die Operatoren ^ und ! müsstest du auch noch hinzufügen, was aber kein großer Aufwand ist. Bisher gibt es für die Potenzierung nur die pow-Funktion (wie in C), die Fakultät fehlt ganz. Die Schwierigkeit deines Unterfangens wird aber in der Arithmetik mit der gewünschten Genauigkeit liegen, da beim GCC für den AVR selbst double-Werte nur 32 Bit breit sind. Vor ein paar Monaten gabe es hier einen ähnlichen Thread, wo über dieses Thema lang und breit diskutiert wurde. Leider finde ich diesen Thread gerade nicht und weiß auch nicht mehr, wie die Lösung des Problems aussah. Edit: Hier ist besagter Thread: Beitrag "Taschenrechner - Algorithmen" Vielleicht findest du darin ein paar nützliche Informationen.
:
Bearbeitet durch Moderator
Paul S. schrieb: > Jetzt zur Frage: > Ist es einfach, die sich in einem String befindliche Formel (z.B. > "2+(34^2)-e") zu berechnen? Nö - aber da Du ja deutlich mehr kannst wie eine Led zum Leuchten zu bringen, wirst Du das schon schaffen. Paul S. schrieb: > Den String bearbeitbar zu erzeugen wäre für > mich ohne Forenhilfe programmierbar. Ja - war schon genannt, Stichwort "Parser". Paul S. schrieb: > Oder sollte ich die Tastendrücke Speichern und daraus das Ergebnis > erzeugen? Wie denn? Paul S. schrieb: > Oder doch mit einem Weg, den ich noch nicht bedacht habe? > Sonst noch Ideen? Diese solltest Du wohl haben oder Dich entsprechend informieren. Wenn Du etwas vorgekaut haben willst wirst Du hier nicht glücklich werden. Paul S. schrieb: > Und bitte lasst diesen Quatsch wie "fang erstmal damit an ne led blinken > zu lassen". Das habe ich schon getan. Warum fragst Du dann hier? Überleg Dir was und fang an. Wenn Du Probleme hast kannst Du immer noch nachfragen - dann aber konkret. Wenn Du kein Konzept hast werden Dich die Fragen / Antworten hier auch nicht weiter bringen. Paul S. schrieb: > durch > meine großen Hände und dem fehlendem Tastendruckspeicher komme ich nicht > gut mit dem klar. Habe ich etwas verpasst? Wozu braucht man einen "Tastendruckspeicher"? Große Hände - ja, aber ein Arduino nano Paul S. schrieb: > Das ganze basiert auf einem Arduino Nano löst auch nicht alle Probleme. Ohne Konzept und Plan (gedankliche Vorwegnahme ...) geht gar nichts (außer Led leuchten zu lassen - und auch dafür muss man ein kleines Konzept haben). Gruß Dieter
Paul S. schrieb: > durch > meine großen Hände Wie groß sind Deine Pratzen? Bedienung wäre ja auch mit einem Stift möglich...
Ist es wirklich ein Fortschritt, wenn bei 3 * 1/3 = 1 herauskommt? Mein erster Taschenrechner hat behauptet dass da 0,99999999 herauskommt und ich hatte das Gefühl, das das stimmt. Abgesehen davon gibt es dutzende Taschenrechner auf Softwarebasis.
>Sonst noch Ideen? Ja: Lass es bleiben! Deine Ausführungen bezeugen einen zu starken Mangel an Ahnung von der Materie. Selbstverständlich kann man Taschenrechner bauen, aber für alles, was über das Niveau "sehr einfach" hinausgeht, benötigst Du tiefgehende Kenntnisse in bestimmten Gebieten der Mathematik und Informatik - jedenfalls wenn Du den Ergebnissen, die auf dem Display erscheinen, am Ende des Tages auch vertrauen willst. Die Entwicklung eines korrekt funktionierenden Rechners mit den von Dir aufgezählten Features wäre ein außerordentlich ambitioniertes Projekt. >Ist es einfach, die sich in einem String befindliche Formel (z.B. "2+(34^2)-e") zu berechnen? Grundsätzlich: Ja. Unter Betrachtung des Aufwands zur erfolgreichen Lösung aller Detailprobleme: Nein.
Sebastian S. schrieb: > Ist es wirklich ein Fortschritt, wenn bei 3 * 1/3 = 1 herauskommt? > > Mein erster Taschenrechner hat behauptet dass da 0,99999999 herauskommt > und ich hatte das Gefühl, das das stimmt. Null Komma Neun periodisch ist 1! > Abgesehen davon gibt es dutzende Taschenrechner auf Softwarebasis. Vermutlich gibts nur wenige Taschenrechner die komplett ohne Software auskommen.
Einfacher wirds mit einem ARM-Prozessor, der gcc generiert code der mit "double" rechnen kann, das reicht für 14 angezeigte Stellen wenn man keinen Blödsinn macht.
Paul S. Handy schrieb: > Irrationale zahlen sind nicht gefordert, daher bin ich darauf nicht > eingegangen > Diese kleinen Ausnahmen sind halt extra definiert. > > Und 2^4=2*2*2*2, also wiederholt multipliziert so meinte ich das Schon klar, wenn einem die Mathematik dafür fehlt. x=a^b ln(x)=ln(a^b)=b*ln(a) x=exp(b*ln(a)) fchk
Frank K. schrieb: > Schon klar, wenn einem die Mathematik dafür fehlt. > > x=a^b > ln(x)=ln(a^b)=b*ln(a) > x=exp(b*ln(a)) Du hast offensichtlich noch nie einen Taschenrechner oder eine Rechnerfunktion programmiert. Die Abweichungen, die sich durch die Umformung auf Grund der realen (Un-)Genauigkeit der transzendenten Funktionen mit Binärzahlen im Computer ergeben, fallen sonst nämlich jedem Kleinkind auf. Paul S. Handy schrieb: > @MaWin: es gibt eine zweitbelegung der Tasten, das reicht für 100 > weitere Funktionen Klingt unbedienbar. 42 shift + 11 Linearschieber um 1 Stelle verschieben shift =
MaWin schrieb: > Klingt unbedienbar. Wenn man 100 Tasten für jeweils 2 Ziffern (bei "großen Pranken" muss man ja mit mindestens ca. 4 cm² rechnen 2 * 2 cm incl. Abstand analog normaler Tastatur) hat man ein mindestens 20 * 20 cm großes Tastenfeld auf dem man suchen kann (und nebenbei noch mit dem Schieberegler positionieren). Mit dem "normalen" numerischen Tastenblock bin ich mit Sicherheit um Klassen schneller - und so ein Teil gibts für wenig Geld zu kaufen. Aber ich habe mal wieder vergessen: Gestern Abend war ja fast schon Freitag ...
>Die Abweichungen, die sich durch die Umformung auf Grund der realen >(Un-)Genauigkeit der transzendenten Funktionen mit Binärzahlen im >Computer ergeben, fallen sonst nämlich jedem Kleinkind auf. Hmm... also irgendwie will mir nicht einleuchten, was Du damit sagen möchtest. Kannst Du das vielleicht nochmal anders formulieren, bitte, damit ich es verstehe?
LostInMusic schrieb: > also irgendwie will mir nicht einleuchten, was Du damit sagen > möchtest. Es ist Scheisse, wenn aus 2^4 eben 15.99998 rauskommt.
Taschenrechtler schrieb: > Ja: RPN (de: umgekehrte polnische Notation, postfix Notation) dürte ein > paar Sachen vereinfachen. Ja, RPN-Eingabelogik statt "natürlicher Eingabe" vereinfacht vieles. Nicht nur, dass man sich Tasten für "Klammer auf" und "Klammer zu" sparen kann. Da habe ich letzten im Forum von Arduino.cc. (im internationalen Teil) ein vollständiges Projekt vorgestellt gesehen. Programmiert mit der Arduino-IDE für Atmega328. Der Taschenrechner hat deutlich weniger als 100 Tasten: http://www.z9.co.za/ec/ec.jpg Der Ersteller des Projekts rechnet übrigens nicht mit einfacher 'float' Genauigkeit, sondern hat extra eine 64-Bit 'Floating-Point-Library' adaptiert und noch eine 64-Bit Math-Library für die "scientific funktions", damit trotz 8-Bit Atmega328 Controller die Ergebnisse von Rechnungen bis auf 18 signifikante Stellen (double) genau sind. Allerdings ist das Programm dadurch nun fast 32K groß, so dass, wenn man ein Arduino-Board oder einen Atmega328 mit UNO-Bootloader verwendet, als erstes den Arduino-Bootloader runterschmeißen und den Controller mit ISP-Programmer programmieren müßte, um es draufzubekommen.
:
Bearbeitet durch User
Robert S. schrieb: > Null Komma Neun periodisch ist 1! Nein. Es fehlt noch ein unendlich kleiner Teil. Das ist ein Unterschied.
MaWin schrieb: > Klingt unbedienbar. > > 42 shift + 11 Linearschieber um 1 Stelle verschieben shift = Nein. Es gibt 100 Tasten (00-99) und einen Linearschieber. Bei einer Position von diesem werden die Tasten als Zahlen eingegeben, bei einer weiteren ALLE Tasten als Shiftwert. H.Joachim S. schrieb: > kreisen und suchen Mit etwas Übung fällt das weg. Und der Mittelpunkt ist hervorgehoben, sodass dieser blind findbar ist (ja hatte ich noch nicht geschrieben). H.Joachim S. schrieb: > Eingabe 758965,236 - jetzt muss man erstmal überlegen: beginne ich mit > 07 oder mit 75? Oder beginnst du hinten? Dann wirds ja noch > verrückter... Ist doch egal womit du beginnst. Wirth schrieb im Beitrag #4545111: > Du hast überhaupt keine Ahnung und davon reichlich. So eine Aussage würde ich nicht einfach so schreiben. Est ist ein unverschämter Vorwurf mit dem du dich > vollkommen lächerlich machst. Wirth schrieb im Beitrag #4545126: > Also lass es! Nö. Wozu habe ich das hier sonst geschrieben, wenn ich es eh lasse? Yalu X. schrieb: > Einen einfaches Progrämmchen zur Auswertung eines als String gegebenen > arithmetischen Ausdrucks in C-Syntax habe ich hier gepostet: > > Beitrag "Re: Weis jemand, wie man mathematische Ausdrücke in C++ > auswert" > Ein klassischer Taschenrechner liest allerdings nicht den kompletten > Ausdruck als String ein, um ihn erst danach auszuwerten. Vielmehr > geschieht die Auswertung schon währen der Eingabe mit laufender Ausgabe > der Zwischenergebnisse. Dafür ist der obige Code nicht (oder nur nach > Modifikation) geeignet. Das war mit noch gar nicht bekannt, aber ist natürlich zeitsparender so. Auf einem µC mit 8MHz ist Zeit aber recht unkritisch, wenn die Berechnung maximal etwa 1-2s dauern soll. > Die Operatoren ^ und ! müsstest du auch noch > hinzufügen, was aber kein großer Aufwand ist. Bisher gibt es für die > Potenzierung nur die pow-Funktion (wie in C), die Fakultät fehlt ganz. > Die Schwierigkeit deines Unterfangens wird aber in der Arithmetik mit > der gewünschten Genauigkeit liegen, da beim GCC für den AVR selbst > double-Werte nur 32 Bit breit sind. Vor ein paar Monaten gabe es hier > einen ähnlichen Thread, wo über dieses Thema lang und breit diskutiert > wurde. [...] > Beitrag "Taschenrechner - Algorithmen" > > Vielleicht findest du darin ein paar nützliche Informationen. Oh ja, der Thread ist gut. Wäre es also einfacher die Genauigkeit um 2 Stellen herabzustufen (von 8 auf 6) und die Ergebnisse leicht zu runden (z.B. 3.99999999 wird zu 4)? Diese Änderung wäre für mich nicht zu dramatisch. Mani W. schrieb: > Bedienung wäre ja auch mit einem Stift möglich... Meinst du jetzt den alten oder den neuen Rechner? Klar, man kann sich einen Stift nehmen und damit die Tasten drücken und zerkratzen. Wenn du damit meinst eine Stifteingabe in den neuen Einzubauen, halte ich das für begrenzt sinnvoll. - Stiftverlust macht das Gerät unbrauchbar, Fingerverlust ist unwarscheinlicher - so ein Display mit Stifteingabe müsste ich erst noch anschaffen - in der Größe wird das schon teurer Jürgen S. schrieb: > Der Taschenrechner hat deutlich weniger als > 100 Tasten: Dafür aber keine Doppelzahleneingabe mit einem Tastendruck. Jürgen S. schrieb: > Der Ersteller des Projekts rechnet übrigens nicht mit einfacher 'float' > Genauigkeit, sondern hat extra eine 64-Bit 'Floating-Point-Library' > adaptiert und noch eine 64-Bit Math-Library für die "scientific > funktions", damit trotz 8-Bit Atmega328 Controller die Ergebnisse von > Rechnungen bis auf 18 signifikante Stellen (double) genau sind. Das klingt relativ komplex. Jürgen S. schrieb: > Ja, RPN-Eingabelogik statt "natürlicher Eingabe" vereinfacht vieles. Das ist momentan ebenfalls meine favorisierte Eingabemöglichkeitsoption. Dieter F. schrieb: > Wenn man 100 Tasten für jeweils 2 Ziffern (bei "großen Pranken" muss man > ja mit mindestens ca. 4 cm² rechnen 2 * 2 cm incl. Abstand analog > normaler Tastatur) hat man ein mindestens 20 * 20 cm großes Tastenfeld > auf dem man suchen kann (und nebenbei noch mit dem Schieberegler > positionieren). Die gesamten Tasten werden auf ein 10x13 cm großes Feld kommen, daneben noch der Schieberegler. Jede Taste hat dann 1.3 cm² Platz, was immer noch besser ist als die 0.6*0.9 cm (0.4*0.7 cm bei Funktionstasten) bei meinem altem. Dieter F. schrieb: > Habe ich etwas verpasst? Wozu braucht man einen "Tastendruckspeicher"? Der die Tastendrücke bis zur abarbeitung speichert. Mit nem schnellem µC ist sowas überflüssig, bei meinem altem aber sinnvoll. > Große Hände - ja, aber ein Arduino nano sooo klein ist der ja doch wieder nicht... Jetzt mal zur eigentlichen Frage. Mein bisheriger Plan mit RPN sieht so aus: Zahleneingabe in array Speichern Wenn Enter gedrückt nächstes arrayelement befüllen. Wenn Rechenoperation gedrückt, jedes Element durchgehen die Operation mit jedem Element ausführen array leeren und das ergebnis hineinschreiben Wenn Ergebnis anzeigen gedrückt Ergebnis anzeigen Sonst bisher eingegebene Formel anzeigen
Paul S. schrieb: > Jede Taste hat dann 1.3 cm² Platz, was immer > noch besser ist als die 0.6*0.9 cm (0.4*0.7 cm bei Funktionstasten) bei > meinem altem. Ich habe hier einen HP-48GX. Jede Taste hat 1,4 * 1,2 cm Platz = 1,68 cm², also deutlich mehr wie Dein Vorhaben. Wie schon geschrieben - Freitag ...
Dieter F. schrieb: > Freitag ... Freitag...Wochenende...Bauzeit! Und ich besitze deinen Rechner nicht, es bringt mit also nichts wenn der größere Tasten hat. Und wenn nicht wegen der Tastengröße, dann baue ich es halt eben aus Spaß. Und außerdem: Platz!=Tastengröße
:
Bearbeitet durch User
Paul S. schrieb: > Wenn Enter gedrückt > Wenn Ergebnis anzeigen ENTER drücken UND ERGEBNIS ANZEIGEN drücken ? Da hast du ja zielgenau die beiden schlechtesten Punkte von RPN und algebraischer Eingabe zusammengeholt. Ein RPN Rechner zeigt nach der Operation direkt das Ergebnis ab, ein algebraischer Rechner erfordert kein Enter. Es ist nicht mehr 1969, als man keinen Platz im ROM hatte für eine Umsetzung algebraisch->Stack, man kann heute durchaus algebraische Eingabe mache, wie sie auch dein Formelstring zeigt, mit Klammern. RPN muss man sich nicht antun, aber wer es will, kann ja bei Modi implementieren. Bei algebraischer Eingabe gibt es einen Stack (bei RPN auch) und zu jeder Stackebene ist ein Operator vermerkt (bei RPN nicht), z.B. - oder * oder (. Bei jeder Eingabe eines Operators ob der Operator eine höhere Präzedenz hat als der oben auf dem Stack gespeichert, oder ausgeführt, = räumt alle ab. Das ist kinderleicht. Man muss heute die Überprüfung von Operatorreihenfolgen nicht mehr auf den Anwender abwälzen weil der Prozessor zu dumm ist. Eingabe Stack 123 123 + 123+ 34 123+ 34 * 123+ 34* 5 123+ 34* 5 - 293- 2 293- 2 = 291
Paul S. schrieb: > Und ich besitze deinen Rechner nicht, es bringt mit also nichts wenn der > größere Tasten hat. Es geht nicht um die Tasten sondern um die Tasten incl. Abstand (wegen der großen "Pranken"). Bei Deinem Taschenrechner sind das etwas mehr als ca. 1,3 * 1,1 cm = mind. 1,4 cm² und damit immer noch mehr wie das, was Du jetzt (angeblich) vorhast. -> Freitag - Troll-Tag
Paul S. schrieb: > Und außerdem: Platz!=Tastengröße Ja, aber: Platz muss für "Prankengröße" ausreichen - die Tastengröße ist dabei zweitrangig!
MaWin schrieb: > ENTER drücken UND ERGEBNIS ANZEIGEN drücken ? > > Da hast du ja zielgenau die beiden schlechtesten Punkte von RPN und > algebraischer Eingabe zusammengeholt. ups... MaWin schrieb: > RPN muss man sich nicht antun, aber wer es will, kann ja bei Modi > implementieren. Kann man machen. Wird aber garantiert kompliziert (aber für später eine gute Idee). MaWin schrieb: > Eingabe Stack > 123 123 > + 123+ > 34 123+ > 34 > * 123+ > 34* > 5 123+ > 34* > 5 > - 293- > 2 293- > 2 > = 291 Gutes Beispiel. Was ich noch nicht verstanden habe ist "Punkt vor Strich" und die Berechnung dann. Beispiel: 123+5*3=123+(5*3)=123+15=138 Eingabe Stack 123 123 + 123+ 5 123+ 5 * 123+ 5* 3 123+ 5* 3 Von oben nach unten wäre das (123+5)*3, was falsch ist.
Tony schrieb: > Robert S. schrieb: >> Null Komma Neun periodisch ist 1! > > Nein. Es fehlt noch ein unendlich kleiner Teil. Das ist ein Unterschied. Nein, 0,999... == 1. # B = 0,999... # 9*B = 10*B - B = 10*0,999... - 0,999... = 9,999... - 0,999... = 9 # 9*B = 9 ==> B=1 # QED.
Moment da habe ich gerade eine Idee.
Da 3*5*5=(3*5)*5 ist:
Eingabe Stack
123 123
+ 123+
5 123+
5
Ü 123+
5
* 123+
5*
3 123+
5*
3
Ü 123+
15
Ü bezeichnet hier die Überprüfung. Sie überprüft, ob der von unten erste
Operator wichtiger als der zweite ist, wenn nein lässt die den Stack so,
wenn ja führt sie die letzten 2 Zeilen aus. Dies kann einfach bei der
Eingabe gemacht werden.
Die Funktion Ü kann einfach aus einem switch oder elseif bestehen, da
bekannt ist, welche über welchen stehen.
Ich habe mir einem wissenschaftlichen Tischrechner mit RPN-Eingabe und vierzeiligem LCD gebaut, der vom Funktionsumfang vom HP 11C inspiriert ist. Programmierbar ist er allerdings nicht. Die Programmstruktur ist ein Automat, der Tastendrücke verarbeitet und zwischen den beiden Zuständen "innerhalb" und "außerhalb" einer Zahleneingabe wechselt. Mir war BCD-Arithmetik mit möglichst vielen Stellen wichtig. Für die Grundrechenarten reicht die in C geschriebene Bibliothek decNumber. http://speleotrove.com/decimal/decnumber.html Damit kommt man auf 34 BCD-Stellen - auf dem Schulhof in den 80er-Jahren hätte man damit ganz vorne gelegen. ;-) Für alles weitere habe ich mir die Bibliotheken angepasst, die im Rahmen des Taschenrechnerprojekts WP 34s erstellt wurden: https://sourceforge.net/projects/wp34s/ Dann brauchte ich allerdings einen Arduino Mega (-Clon), damit das Programm noch in den Speicher passte. Mir hat es auf jeden Fall großen Spaß gemacht. Viel Erfolg!
Das ist ja ne ganz schön umfangreiche Bibliothek - erleichtern wird es das aber auf jeden Fall. Allein schon die einfache Deklaration der Stellenanzahl ist schon einiges wert. Nen Mega habe ich allerdings nicht, allerdings die LCD-Ansteuerung ebenfalls. Aus Platzgründen werde ich aber vmtl. nur etwas kleinere Längen nehmen, das wird schon passen.
Für die Überprüfung braucht es keine extra Eingabe. Die Überprüfung soll bei jedem eingegebenen Operator ausgeführt werden. Ggf. separate Stacks für Operatoren und Operanden führen... Etwa so:
1 | while get input: |
2 | if input is "(":
|
3 | push "("
|
4 | else if input = ")": |
5 | while last operator on stack != "(":
|
6 | calculate last operator on stack with last to numbers |
7 | replace with result |
8 | end while |
9 | remove "(" from stack
|
10 | else if input is number: |
11 | push number |
12 | else if input is operator: |
13 | while prio is lower than or equal to last operator on stack: |
14 | calculate last operator on stack with last two numbers |
15 | replace with result |
16 | end while |
17 | push operator |
18 | end if |
19 | end while |
1+2*3-4*(5+6) sieht dann etwa so aus (T bedeutet einde eingabe (terminator)):
1 | input action stacks |
2 | 1 push [1] [] |
3 | + push [1] [+] |
4 | 2 push [2 1] [+] |
5 | * push [2 1] [* +] |
6 | 3 push [3 2 1] [* +] |
7 | - calc [6 1] [+] |
8 | calc [7] [] |
9 | push [7] [-] |
10 | 4 push [4 7] [-] |
11 | * push [4 7] [* -] |
12 | ( push [4 7] [( * -] |
13 | 5 push [5 4 7] [( * -] |
14 | + push [5 4 7] [+ ( * -] |
15 | 6 push [6 5 4 7] [+ ( * -] |
16 | ) calc [11 4 7] [( * -] |
17 | pop [11 4 7] [* -] |
18 | T calc [44 7] [-] |
19 | calc [-37] [] |
Die Ausnahmebehandlung vom Ende des Inputs braucht man nicht wenn Der
Operatorstack mit einem "(" vorgefüllt wird und man das Ende als ")"
behandelt.
:
Bearbeitet durch User
Paul S. schrieb: > Von oben nach unten wäre das (123+5)*3, was falsch ist. Nein, von oben nach unter wäre das 123+5*3, oder mit Klammern 123+(5*3) und das Ergebnis steht bis zum Minuszeichen deswegen auf dem Stack, weil er ja nicht weiss, ob noch ein höherpriorisierter Operator wie ^ kommt. 123+5*3^2 wäre ja 123+(5*(3^2)) Erst als dann das - eingetippt wird, wird alles bis zur Strichrechnung ausgerechnet.
Eric B. schrieb: > while get input: > if input is "(": > push "(" > else if input = ")": > while last operator on stack != "(": > calculate last operator on stack with last to numbers > replace with result > end while > remove "(" from stack > else if input is number: > push number > else if input is operator: > while prio is lower than or equal to last operator on stack: > calculate last operator on stack with last two numbers > replace with result > end while > push operator > end if > end while Das ist so ganz nicht auf den Arduino übertragbar. Soweit bin ich gekommen:
1 | int stack[]={}; |
2 | int stackOperator[]={}; |
3 | |
4 | void setup(){ |
5 | // hier deklaration der pins als input/output
|
6 | }
|
7 | void loop(){ |
8 | // hier die abfrage, ob knopf gedrückt, wenn ja, aufruf von buttonPressed mit jedem zeichen einzeln
|
9 | }
|
10 | |
11 | void buttonPressed(input){ |
12 | if(input=="("){ |
13 | stackOperator[sizeof stackOperator]+="("; |
14 | }else if(input==")"){ |
15 | while(last operator on stack != "("){ |
16 | calculate last operator on stack with last to numbers//Auf Deutsch? |
17 | replace with result |
18 | }
|
19 | stackOperator[sizeof stackOperator-1]+=""; |
20 | }else if(isNumber(input)){ |
21 | stack[sizeof stack]+=input; |
22 | }else if(isOperator(input)){ |
23 | while(prio is lower than or equal to last operator on stack){//Was meint das? |
24 | calculate last operator on stack with last two numbers//Und was das hier? |
25 | replace with result |
26 | }
|
27 | stackOperator[sizeof stackOperator]+=operator; |
28 | }
|
29 | }
|
30 | void isOperator(in){ |
31 | int is=false; |
32 | switch (in){ |
33 | case "*": |
34 | case "+": |
35 | case "-": |
36 | case "/": |
37 | case "^" |
38 | is=true; |
39 | break; |
40 | }
|
41 | return is; |
42 | }
|
43 | |
44 | void isNumber(in){ |
45 | int is=false; |
46 | switch (in){ |
47 | case "1": |
48 | case "2": |
49 | case "3": |
50 | case "4": |
51 | case "5" |
52 | case "6": |
53 | case "7": |
54 | case "8": |
55 | case "9": |
56 | case "0": |
57 | is=true; |
58 | break; |
59 | }
|
60 | return is; |
61 | }
|
So was ähnliches findet sich noch hier: http://www2.lawrence.edu/fast/GREGGJ/CMSC270/Infix.html http://stackoverflow.com/questions/20696085/infix-calculator Mal sehen ob ich da abschreiben kann
:
Bearbeitet durch User
Eric B. schrieb: > Tony schrieb: >> Robert S. schrieb: >>> Null Komma Neun periodisch ist 1! >> >> Nein. Es fehlt noch ein unendlich kleiner Teil. Das ist ein Unterschied. > > Nein, 0,999... == 1. siehe auch hier: https://de.wikipedia.org/wiki/0,999%E2%80%A6
Tony schrieb: > Robert S. schrieb: >> Null Komma Neun periodisch ist 1! > > Nein. Es fehlt noch ein unendlich kleiner Teil. Das ist ein Unterschied. Nope. 0.9p(eriodisch) = 9/9 = 1. https://www.wolframalpha.com/input/?i=0.9periodic
Nen paar Anregungen zu nem einfachen Taschenrechnerprogramm gibts hier: http://www.fritzler-avr.de/spaceage2/soft_tasch.htm http://www.fritzler-avr.de/spaceage2/down_software.htm
>Es ist Scheisse, wenn aus 2^4 eben 15.99998 rauskommt.
Ach so meintest Du das. Stimmt. Das kommt aber nicht vom Rechnen mit
Binärzahlen, sondern vom Rechnen mit Fließkommazahlen. Und mit
transzendenten Funktionen hat es eigentlich auch nichts zu tun, denn der
Effekt träte ja z. B. auch bei sqrt (Quadratwurzel) auf, obwohl das
keine transzendente Funktion ist.
Ich habe mal spaßeshalber meinen gewöhnlichen (wissenschaftlichen)
Casio-TR die 5-te Wurzel aus 3077056399 ausrechnen lassen, und siehe da,
er schrieb "79" ins Display. Also nicht 78.9999996 oder sowas in der
Art. Eigentlich ist das erstaunlich. Wird da eine Integer-Rückrechnung
nachgeschaltet? Also das Ergebnis ganzzahlgerundet, per Integer-Rechnung
in die 5-te Potenz erhoben und das Resultat mit der Ausgangszahl
verglichen? Oder wie wird es sonst gemacht?
LostInMusic schrieb: > Wird da eine Integer-Rückrechnung nachgeschaltet? Nein, wie schon geschildert rechnen die in BCD und mit guard-digits.
Bin mal zum Programmieren gekommen. Sind noch nicht alle Funktionen drin. Sieht jemand einen offensichtlichen Fehler, oder kann das so funktionieren?
1 | int klammern=0; |
2 | int maxklammern=0; |
3 | int currentChar=0; |
4 | int maxChar=ausdruck.length; |
5 | int j=0; |
6 | int klammernCount=0; |
7 | int zwischenergebnis=0; |
8 | string zoperator=""; |
9 | int faktor=0; |
10 | |
11 | void berechne(){ |
12 | do{ |
13 | klammernCount=0; |
14 | maxklammern=0; |
15 | klammern=0; |
16 | currentChar=0; |
17 | maxChar=ausdruck.length; |
18 | for(int i=0;i<ausdruck.length;i++){ |
19 | if(ausdruck[i]=="(")klammern++; |
20 | if(maxklammern<klammern)maxklammern=klammern; |
21 | if(ausdruck[i]==")")klammern--; |
22 | }
|
23 | for(j=0;j<ausdruck.length;j++){ |
24 | if(ausdruck[j]=="(")klammernCount++; |
25 | if(klammernCount==maxklammern){ |
26 | currentChar=j+1; |
27 | ausdruck[j]=""; |
28 | break; |
29 | }
|
30 | }
|
31 | for(j=currentChar;j<ausdruck.length;j++){ |
32 | if(ausdruck[j]==")"){ |
33 | maxChar=j-1; |
34 | ausdruck[j]=""; |
35 | break; |
36 | }
|
37 | }
|
38 | zwischenergebnis=0; |
39 | zoperator=""; |
40 | faktor=0; |
41 | for(j=currentChar;j<maxChar;j++){ |
42 | if(j==currentChar){//erster durchlauf |
43 | if(ausdruck[j]=="-")faktor=-1,break; |
44 | if(ausdruck[j]=="+")break; |
45 | if(isInteger(ausdruck[j]))zwischenergebnis=ausdruck[j].toInt(),break; |
46 | //alles hier ist Fehlerhaft
|
47 | }else{ |
48 | if(isOperator(ausdruck[j])){ |
49 | zoperator=ausdruck[j]; |
50 | break; |
51 | }
|
52 | if(isInteger(ausdruck[j])){ |
53 | if(zoperator=="+")zwischenergebnis+=ausdruck[j],break; |
54 | if(zoperator=="-")zwischenergebnis-=ausdruck[j],break; |
55 | if(zoperator=="*")zwischenergebnis*=ausdruck[j],break; |
56 | if(zoperator=="/")zwischenergebnis/=ausdruck[j],break; |
57 | if(zoperator=="!")zwischenergebnis=fak(zwischenergebnis),break; |
58 | //alles hier ist Fehlerhaft
|
59 | }
|
60 | }
|
61 | ausdruck[j]=""; |
62 | }
|
63 | ausdruck[currentChar]=zwischenergebnis; |
64 | }while(!keineklammern); |
65 | }
|
66 | |
67 | void isOperator (a){ |
68 | switch(a){ |
69 | case "+": |
70 | case "-": |
71 | case "*": |
72 | case "/": |
73 | case "!": |
74 | a=true; |
75 | default:
|
76 | a=false; |
77 | break; |
78 | }
|
79 | return a; |
80 | }
|
81 | |
82 | void isVorzeichen (a){ |
83 | switch (a){ |
84 | case "+": |
85 | case "-": |
86 | a=true; |
87 | break; |
88 | default:
|
89 | a=false; |
90 | break; |
91 | }
|
92 | return a; |
93 | }
|
94 | |
95 | void isInteger (a){ |
96 | if(a.toInt()==0&&a!=="0"){ |
97 | return false; |
98 | }else{ |
99 | return true; |
100 | }
|
101 | }
|
102 | |
103 | int fak(int n){ //vom c++-forum, leicht modifiziert |
104 | if(n==0||n>12){ |
105 | return 0; |
106 | }else{ |
107 | return n * fak(n-1); |
108 | }
|
109 | }
|
Also, erst wird die Tiefste Klammer gefunden und dann aufgelöst, dann die nächsttiefste u.s.w. bis keine Klammern mehr da sind und sich das ganze auf eine Zahl reduziert hat. Ausdruck ist ein Array, mit jeder Zahl und jedem Operator auf einem eigenem Feld z.B. ["2","*","72"]//2*72
Paul S. schrieb: > Das System ist recht praktikabel, lol :-) Da habe ich so meine Zweifel ... Paul S. schrieb: > - Verschachtelte Klammersetzung () Paul S. schrieb: > - Editieren der schon eingegebenen Formel Paul S. schrieb: > - positive und negative Zahlen mit mind. 10 Stellen möglich > - Scrollen innerhalb der Formel > - Ausrechnen der Formel Und das Ganze mit If's und Switch-Cases? Schon mal nach "Parser" und "Rekursion" ge-google't? Sei mir nicht böse - aber an Deiner Stelle würde ich erstmal mit den 4 Grundrechenaren anfangen.
> Nein, wie schon geschildert rechnen die in BCD und mit guard-digits.
Mal eine Verständnisfrage: Guard-Digits kann ich einsehen. Aber was ist
der Vorteil von BCD wenn es um rationale Zahlen geht, die im Nenner
etwas anderes als 2 oder 5 haben? Das kann man dann auch nicht exakt
darstellen. Im Binärsystem fällt halt die 5 auch noch weg, aber was
soll's. Da wird eh nie ein Schuh draus.
Dieter F. schrieb: > Sei mir nicht böse - aber an Deiner Stelle würde ich erstmal mit den 4 > Grundrechenaren anfangen. Genau das ist da ja eingebaut (+Fakultät). Scrollen hat übrigens nix damit zu tun, dafür speichere ich einen Startindex (erste Stelle am Display), der sich nur verschiebt. Also nix mit if und switch. Dieter F. schrieb: > Rekursion Was hat die damit zu tun? Was würdest du Rekursiv umsetzen wollen?
Paul S. schrieb: > Was würdest du Rekursiv umsetzen wollen Das Parsen - für Einsteiger: https://de.wikipedia.org/wiki/Parser
Cube_S schrieb: > Mal eine Verständnisfrage: Guard-Digits kann ich einsehen. Aber was ist > der Vorteil von BCD wenn es um rationale Zahlen geht, die im Nenner > etwas anderes als 2 oder 5 haben? Der einzige Vorteil der BCD-Darstellung besteht darin, dass damit Zahlen, die im Dezimalsystem nur begrenzt viele Nachkommastellen haben, exakt darstellbar sind. Das ist aber allenfalls für Kaufleute wichtig. Für Wissenschaftler und (echte) Ingenieure spielt das keine Rolle, da fast alle reellen Zahlen sowieso keine endliche Darstellung haben, weder in BCD- noch im Dualdarstellung. Da sind andere Dinge wie die numerische Auflösung bei gegebener Bit-Breite und die Rechengeschwindigkeit sehr viel wichtiger als Kosmetik. Und hier liegt das Dualsystem ganz klar vorn. Das ist jetzt aber etwas offtopic, und es gab hier auch bereits Threads zu diesem Thema.
>die im Dezimalsystem nur begrenzt viele Nachkommastellen haben
Begrenzt!
Das ist der Punkt, denn damit wird es zur Integer-Arithmetik. Frage:
Macht heute wirklich noch irgend jemand in BCD?
Cube_S schrieb: > Aber was ist der Vorteil von BCD wenn es um rationale Zahlen geht Da die Zahlen Ein- und Ausgabe immer im 10er System erfolgt spart man sich die Umwandlung und damit Umwandlungsfehler, denn es gibt nicht zu jeder eingegebenen Dezimalzahl eine exakte float-Zahl sondern nur eine nächstliegende. Der Fehler schleppt sich durch die Berechnungen, verstärkt sich manchnal, und bei der Rückwandlung muss man wieder die nächstliegende Dezimalzahl nehmen - die dann nicht unbedingt das erwartete Ergebnis ist wie wenn man es zu Fuss mit Blatt und Papier rechnen würde. Erstes Beispiel ist 10*(1/10). Daher verwendet jede Banksoftware Dezimalarithmetik.
> Dezimalarithmetik
hilft bei 3*(1/3) 7*(1/7) 11*(1/11) usw. auch nicht. Also fast nie. In
.NET ist ein decimal interessanterweise intern denn auch binär soweit
ich das weiß
Bei Taschenrechnern ist es einfach üblich, daß sie dezimal rechnen, es wird erwartet. Wenn ein Taschenrechner auf 5*(1/5) nicht mit 1 antwortet, fliegt er sofort als unzuverlässig in den Müll. 3*(1/3)=0,9999... kann man ihm dagegen verzeihen, weil es für den Menschen, der das Rechnen im Dezimalsystem gewohnt ist, verständlich ist, wie die Abweichung zustandekommt. Da der Taschenrechner relativ interaktiv ist und viele Zwischenergebnisse anzeigen kann, ist es auch sinnvoll, den Aufwand der Umrechnung in ein anderes Zahlensystem einzusparen. Beim Computer ist das anders: da liegen im allgemeinen mehr Rechenschritte zwischen Ein-und Ausgabe, daher lohnt sich die Zahlensystem-Umrechnung, wenn dadurch das eigentliche Rechnen effizienter wird. Mag sein, daß den Ingenieuren dezimale berechnete Nachkommastellen egal sind. Aber auch Kaufleute haben ein Recht auf Taschenrechner, die für ihren Anwendungszweck korrekt rechnen; immerhin bilden sie einen signifikanten Kundenkreis. Nicht umsonst wird von den HP-Taschenrechnern der 80er Jahre einzig das kaufmännische Modell noch hergestellt. Genaugenommen können wir froh sein, daß kaufmännische Rechenmaschinen nach dem Komma nicht mehr Zwanzigstel, Zwölftel und Viertel anzeigen müssen. :)
> Mag sein, daß den Ingenieuren dezimale berechnete Nachkommastellen egal > sind. Aber auch Kaufleute haben ein Recht auf Taschenrechner, die für > ihren Anwendungszweck korrekt rechnen; immerhin bilden sie einen > signifikanten Kundenkreis. Nicht umsonst wird von den HP-Taschenrechnern > der 80er Jahre einzig das kaufmännische Modell noch hergestellt. Nur unter Kaufleute finden sich soviele, welche zwar einen Computer vor der Nase haben, damit aber nicht rechnen können und nach einem Taschenrechner verlangen. Ingenieure können "mit allem" Rechnen, auch mit dem Computer und oft auch sogar noch Kopfrechnen, ganz ohhne Strom und mehr als die Grundrechenarten. (hab noch kein Kaufmann mit Rechenschieber getroffen, ausser der der solche verkauft)
Taschenrechtler schrieb: > (hab noch kein Kaufmann mit Rechenschieber getroffen, ausser der der > solche verkauft) Der müsste in der heutigen Zeit auch einen an der Waffel haben :-) Taschenrechtler schrieb: > Nur unter Kaufleute finden sich soviele, welche zwar einen Computer vor > der Nase haben, damit aber nicht rechnen können und nach einem > Taschenrechner verlangen. > > Ingenieure können "mit allem" Rechnen, auch mit dem Computer und oft > auch sogar noch Kopfrechnen, ganz ohhne Strom und mehr als die > Grundrechenarten. Ja, nur Chuck Norris ist besser ... Chuck Norris kann Strich vor Punkt rechnen :-)
Angehängte Dateien:
-
wrongulator.jpg
60 KB
Nosnibor schrieb: > Wenn ein Taschenrechner auf 5*(1/5) nicht mit 1 > antwortet, fliegt er sofort als unzuverlässig in den Müll. Nein, der wird nur anders vermarktet. ;-)
psst, hier ein Rechner f. echte Kaufmänner: <http://www.rechnerlexikon.de/artikel/Precisa_108>; Hab so einer in meiner Sammlung: der kann nichtmal alle 4 Grundrechenarten, sondern nur + und - (also f. alle die wie Chuck Norris Strich vor... vor... egal: keine Punktrechnung möglich!) Und wer's nur mit Strom will: hab auch das Folgemodell 208: Aussehen & Funktionsumfang identisch aber mit 230V~ Antrieb anstelle der Handkurbel.
Taschenrechtler schrieb: > b so einer in meiner Sammlung: der kann nichtmal alle 4 > Grundrechenarten, sondern nur + und - (also f. alle die wie Chuck Norris > Strich vor... vor... egal: keine Punktrechnung möglich!) > > Und wer's nur mit Strom will: hab auch das Folgemodell 208: Aussehen & > Funktionsumfang identisch aber mit 230V~ Antrieb anstelle der > Handkurbel. Hatte 1962 den Vorteil, dass Kaufmänner für ihre Berechnungen bzw. Buchungen nicht interpolieren mussten, sondern die Preise / Beträge korrekt nennen konnten. Die haben auch sehr selten Triogonometrie, Wurzeln, etc. genutzt. Was für ein Vergleich ... Zeig doch mal, was es 1962 an wissenschaftlichen Tischrechnern gab. Würde mich wirklich interessieren.
> Zeig doch mal, was es 1962 an wissenschaftlichen Tischrechnern gab.
Tut mir leid: in Tisch grösse hab ich nichts... ;-)
Moment! Ich weiss dass es Analogrecher gab, in der Grösse ~Aktenkoffer,
zu programmieren durch stecken von Kabel...
(Jahreszahl, Marke/Modell weiss ich leider nicht - hab keinen davon, nur
mal 'n Foto von gesehen)
Dieter F. schrieb: >... > Zeig doch mal, was es 1962 an wissenschaftlichen Tischrechnern gab. > Würde mich wirklich interessieren. Wohl eher kaufmännisch aber passte auf den Tisch : http://www.technikum29.de/de/rechnertechnik/elektronenroehren
Taschenrechtler schrieb: > Tut mir leid: in Tisch grösse hab ich nichts... ;-) Ich meinte damit "auf einen Tisch passend" ..." und nicht in "Tischgrösse" :-) . Natürlich gab es da nichts - daher verstehe ich die Häme Taschenrechtler schrieb: > der kann nichtmal alle 4 Grundrechenarten, sondern nur + und - auch nicht. Ich habe 1976 noch mit einem mechanischen(!) Tischrechner multipliziert - und kann - oh Wunder - auch Kopfrechnen. Auch ein Rechenschieber ist mir nicht unbekannt, obwohl ich kein Ingenieur bin. Das hat nichts mit Ingenieur etc. zu tun sondern mit "Generation Elektronik" (Smartphone & Co.) ... dass gewisse Fähigkeiten (Kopfrechnen und "Abschätzen" von Ergebnissen) verschwinden. Nix für ungut - ich finde es auch bedauerlich - aber die Welt dreht sich halt weiter ...
The D. schrieb: > Wohl eher kaufmännisch Ja, etwas anderes gab es wohl auch nicht (der Markt bestimmt das Angebot ...)
Dieter F. schrieb: > The D. schrieb: >> Wohl eher kaufmännisch > > Ja, etwas anderes gab es wohl auch nicht (der Markt bestimmt das Angebot > ...) Wohl eher die technischen Möglichkeiten. Aber wunderschön anzusehen.
The D. schrieb: > Wohl eher die technischen Möglichkeiten. Nö 1932: Der Mathematiker WILHELM CAUER löst an der Universität Göttingen lineare Gleichungssysteme mit bis zu zehn Variablen mittels speziell dafür konstruierter Analog-Rechenanlagen.
Dieter F. schrieb: > The D. schrieb: > >> Wohl eher die technischen Möglichkeiten. > > Nö > > 1932: Der Mathematiker WILHELM CAUER löst an der Universität Göttingen > lineare Gleichungssysteme mit bis zu zehn Variablen mittels speziell > dafür konstruierter Analog-Rechenanlagen. Und das passte dann auf einen Schreibtisch?
Taschenrechtler schrieb: > (hab noch kein Kaufmann mit Rechenschieber getroffen, ausser der der > solche verkauft) Ich habe auch noch keinen Bäcker mit einer Rohrzange arbeiten gesehen. Es ist einfach nicht das richtige Werkzeug für diese Art Arbeit. Und damit man mit dem Computer vor der Nase rechnen kann, muß darauf auch eine geeignete Software laufen, und zwar genau in dem Moment, wenn man etwas zu rechnen hat. Beim Taschenrechner kann man sich darauf verlassen, daß er wie erwartet funktioniert, wann immer man ihn einschaltet. Kein "updating antivirus..."-Popup; kein automatisches Update, das einem die Tasten umsortiert...
Eric B. schrieb: > Nein, 0,999... == 1. > > # B = 0,999... > # 9*B = 10*B - B = 10*0,999... - 0,999... = 9,999... - 0,999... = 9 > # 9*B = 9 ==> B=1 > # QED. Dann ist pi = 3
Karl schrieb: > Eric B. schrieb: >> Nein, 0,999... == 1. >> >> # B = 0,999... >> # 9*B = 10*B - B = 10*0,999... - 0,999... = 9,999... - 0,999... = 9 >> # 9*B = 9 ==> B=1 >> # QED. > > Dann ist pi = 3 Wie denn das? Nicht nur behaupten, beweisen!
Einen Taschenrechner zu bauen ist eine nicht ganz einfache Aufgabe. Das weiß ich aus Erfahrung. Den Arbeitsaufwand habe ich erheblich unterschätzt. Doch als Einführung kann ich dieses Buch empfehlen. https://www.elektor.de/programmierbare-taschenrechner-selbst-gebaut-pdf Viel Glück beim bauen. -- Jens
Hi >Hab so einer in meiner Sammlung: der kann nichtmal alle 4 >Grundrechenarten, sondern nur + und - (also f. alle die wie Chuck Norris >Strich vor... vor... egal: keine Punktrechnung möglich!) Mein Großvater hatte eine Mercedes-Euklid: http://www.rechnerlexikon.de/artikel/Mercedes_Euklid_Geschichte Modell 9 Bj.1924. Die konnte auch Multiplikation und Division. War bis zur Wende im Geschäft meiner Eltern im Gebrauch. MfG Spess
Eric B. schrieb: > Tony schrieb: >> Robert S. schrieb: >>> Null Komma Neun periodisch ist 1! >> >> Nein. Es fehlt noch ein unendlich kleiner Teil. Das ist ein Unterschied. > > Nein, 0,999... == 1. > > # B = 0,999... > # 9*B = 10*B - B = 10*0,999... - 0,999... = 9,999... - 0,999... = 9 > # 9*B = 9 ==> B=1 > # QED. Ich bin ebenfalls der Meinung, das 0,999... nicht 1 ist. Ich denke dies ist eine Limitation des Reellen Zahlenraums, in welchem man keinen unendlich kleinen Anteil darstellen kann. Nimm einfach einen anderen Zahlenraum: https://en.wikipedia.org/wiki/Infinitesimal#Number_systems_that_include_infinitesimals
Zurueck zum Rechner. Ich wuerd der einfachheit halber erst eine Rechner App fuer ein Smartphone programmieren.
Daniel A. schrieb: > Ich bin ebenfalls der Meinung, das 0,999... nicht 1 ist. Ich denke dies > ist eine Limitation des Reellen Zahlenraums, in welchem man keinen > unendlich kleinen Anteil darstellen kann. Nimm einfach einen anderen > Zahlenraum: > https://en.wikipedia.org/wiki/Infinitesimal#Number_systems_that_include_infinitesimals Blah. Jetzt schreib mir bitte in diesem Zahlenraum einen Beweis dass 0,9... nicht 1 ist. Meinungen haben in der Mathe nichts verloren.
Jens G. schrieb: > Einen Taschenrechner zu bauen ist eine nicht ganz einfache Aufgabe. Dann schaut euch doch mal den WP34S an, der basiert auf einem ARM Prozessor, also etwas, das hier durchaus reinpaßt. W.S.
Einen Rückblick zur Historie vom WP34S findet man hier. ftp://ftp.heanet.ie/disk1/sourceforge/w/wp/wp34s/HHC2011/wp34s-HHC2011.p df Das Projekt setzt auf vorhandene Hardware auf (HP-20b and HP-30b business calculators).
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.