MATHE mit BASIC

Es gibt 12 Antworten in diesem Thema, welches 3.813 mal aufgerufen wurde. Der letzte Beitrag (18. Dezember 2023 um 06:52) ist von BIF.

  • Z10: GROSSES EINMALEINS:

    Bitte melde dich an, um diesen Anhang zu sehen.


    Bitte melde dich an, um diesen Anhang zu sehen.

    Das Thema Mathe in Basic ist natürlich auch ein Basic-Thema.

    Daher habe ich hier einmal das Grosse Einmaleins im Stile einer Tabellencalkulation programmiert.

    Die Eingabe erfolgt mit den Zifferntasten, Cursortasten und Return.

    Hat der Nutzer alle Werte richtig ausgerechnet erfolgt ein Neustart.

    Der 10-Zeiler zeigt eine Zellenorientierte Tabellenkalkulation in nur 10 Basiczeilen.

    PS. beim Listing fehlt am Ende ein Return, was ich noch bemerkt habe.

    Schönen Gruß.

  • Bin schwer beeindruckt wie knapp der Code hierzu ist.

    Aber der hat's auch in sich- so optimiert und ohne Kommentare kann ich kaum folgen.

    Müsste ich das schreiben, wäre es locker 10x länger und 5x langsamer. Respekt!

  • Müsste ich das schreiben, wäre es locker 10x länger und 5x langsamer. Respekt!

    Würdest Du den Code schreiben dann wären am Zeilenbegin bestimmt keine Doppelpunkte vorhanden,

    demnach wäre Dein Code da 10x kürzer und 5x schneller. LOL28

    Bitte melde dich an, um diesen Anhang zu sehen. :verehr: .: Mit Bitte melde dich an, um dieses Bild zu sehen.wäre das nicht passiert! :. :prof:  Bitte melde dich an, um diesen Anhang zu sehen.

    :syshack: .: Meine 3D-Drucker Teile auf :. Bitte melde dich an, um diesen Link zu sehen. :strom:

  • Danke für das Lob.

    Selbstverständlich kann oobdoo auch seine 5x schnellere und 10 mal kürzere Version posten. Das wäre dann rein rechnerisch ein Einzeiler.

    Schönen Gruß.

  • Hier nochmal die Bitte melde dich an, um diesen Link zu sehen. mit 10-Zeilern veranschaulicht.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Code
    10 PRINT"{CLR}"TAB(9)"KAPREKAR3 FOR 1 TO 999{DOWN}"
    20 FOR N=1TO999:Z=N:IF Z/111=INT(Z/111)GOTO100
    30 Z$=RIGHT$("00"+MID$(STR$(Z),2),3):PRINT Z$" ";
    40 FOR I=1TO3:Z(I)=VAL(MID$(Z$,I,1)):NEXT
    50 FOR I=2TO1 STEP-1:FOR J=1TO I:T=Z(J+1)
    60 IF Z(J)>T THEN Z(J+1)=Z(J):Z(J)=T
    70 NEXT J,I:G$="":K$=""
    80 FOR I=1TO3:G$=STR$(Z(I))+G$:K$=K$+STR$(Z(I)):NEXT
    90 T=VAL(G$)-VAL(K$):IF Z<>T THEN Z=T:GOTO30
    100 PRINT:NEXT

    Bitte melde dich an, um diesen Anhang zu sehen.

    Code
    10 PRINT"{CLR}"TAB(8)"KAPREKAR4 FOR 1 TO 9999{DOWN}"
    20 FOR N=1TO9999:Z=N:PRINT"{LEFT}";:IF Z/1111=INT(Z/1111)GOTO100
    30 Z$=RIGHT$("000"+MID$(STR$(Z),2),4):PRINT " "Z$;
    40 FOR I=1TO4:Z(I)=VAL(MID$(Z$,I,1)):NEXT
    50 FOR I=3TO1 STEP-1:FOR J=1TO I:T=Z(J+1)
    60 IF Z(J)>T THEN Z(J+1)=Z(J):Z(J)=T
    70 NEXT J,I:G$="":K$=""
    80 FOR I=1TO4:G$=STR$(Z(I))+G$:K$=K$+STR$(Z(I)):NEXT
    90 T=VAL(G$)-VAL(K$):IF Z<>T THEN Z=T:GOTO30
    100 PRINT:NEXT
  • KAPREKAR reloaded!

    Ich bin mir ziemlich sicher, dass ich vor etwa einer Woche in einem Mainstream-Medium (Spiegel? Süddeutsche?) einen Artikel zum Thema Kaprekar-Konstanten gelesen habe, doch jetzt finde ich ihn leider nicht mehr. :sad:

    Bei Kaprekar-Konstanten geht es, kurz gesagt, um Folgendes: Man sortiert die Ziffern einer Zahl der Größe nach, dann noch einmal andersherum, dann bildet man aus den beiden die Differenz und fängt damit wieder von vorne an. In vielen Fällen landet man dann erstaunlicherweise bei derselben Zahl oder zumindest bei einem immer wiederkehrenden Zyklus von Zahlen.

    Näheres hier bei Bitte melde dich an, um diesen Link zu sehen..

    Auf jeden Fall hat mich das dazu inspiriert, das auch einmal auf dem C64 umzusetzen. Möglicherweise etwas umständlich, aber es läuft!

    Bilder:

    Bitte melde dich an, um diesen Anhang zu sehen.Bitte melde dich an, um diesen Anhang zu sehen.

    Bitte melde dich an, um diesen Anhang zu sehen.Bitte melde dich an, um diesen Anhang zu sehen.

    Viel Spaß beim Ausprobieren! :smile:

    Dateien

    Bitte melde dich an, um diesen Link zu sehen. - Ratespiel • Bitte melde dich an, um diesen Link zu sehen. - BASIC-Erweiterung • Bitte melde dich an, um diesen Link zu sehen. - Sprite-Editor • Bitte melde dich an, um diesen Link zu sehen. - Zeichensatz-Editor Bitte melde dich an, um diesen Link zu sehen. - 2048 Blöcke

  • PLUS-RECHNEN

    Bitte melde dich an, um diesen Anhang zu sehen.

    Hallo, hier noch ein 10-Zeiler-Beitrag.
    Mathe, Rechnen mit großen Zeichen.

    Die Bedienung erfolgt mit den Zifferntasten.
    Löschen oder Neueingabe mit der DEL- oder Leertaste.

    Schönen Gruß.

  • Mir ist gerade aufgefallen, dass BASIC V2 wieder was kann, was der Windows-Taschenrechner alias calc.exe nicht kann. Letztes Mal war es Punkt-vor-Strich-Rechnung im Standardmodus, und da gab es unterschiedliche Meinungen; manche hielten es für legitim, es in diesem Modus nicht zu berücksichtigen. Diesmal bezieht es sich aber auch auf den wissenschaftlichen Modus. Die Rede ist von "-x^y ist gleich -(x^y) und ist nicht gleich (-x)^y". BASIC V2 errechnet korrekt -(x^y). Calc.exe errechnet (-x)^y. Zwar gibt es auch dazu wieder unterschiedliche Meinungen, aber ich vertrete die, die ich gelernt habe und auch von den Mathematik-Lehrern auf YT so Bitte melde dich an, um diesen Link zu sehen. wird. Auch der Google-Taschenrechner setzt nach Eingabe von -3^2 zur Verdeutlichung der Hierarchie Klammern um 3^2, während calc.exe Klammern um -3 setzt. Dabei ist es sogar egal, ob zwischen dem Minus und der 3 Leerzeichen stehen.

  • Die Rede ist von "-x^y ist gleich -(x^y) und ist nicht gleich (-x)^y". [...] Mathematik-Lehrer[...] auf YT [...]

    Lebhafte Erinnerung an die Schulzeit, mit ganz klarer Ansage damals™: wenn das Minus-Zeichen explizit als Vorzeichen gemeint ist, gehört dieses - mit der Zahl (oder Variable) dahinter - gefälligst in Klammern. Damit ist dann auch im Zusammenhang mit der Potenzierung die Priorität eindeutig festgelegt.

    Bei Mißachtung dieser Regel wurde gleich mal die ganze Zeile rot angestrichen. :bgdev

    Davon abgesehen ist die Potenzierung für beliebige reelle Exponenten auch nur dann eindeutig definiert, wenn die Basis-Zahl positiv ist. Für negative Basis-Zahlen muß man sich auf entweder auf ganzzahlige Exponenten beschränken, damit man das Ergebnis auch noch reell definieren kann, andernfalls muß man mit komplexen Zahlen rechnen.

    CBM BASIC betreibt tatsächlich den Aufwand, diese Bedingung (Exponent ganzzahlig?) für negative Basis-Zahlen abzuprüfen! PRINT (-1)^2 und PRINT (-1)^3 sind z.B. erlaubt, PRINT (-1)^2.1 nicht und liefert ?ILLEGAL QUANTITY ERROR (siehe $BF8F..$BF99 in Bitte melde dich an, um diesen Link zu sehen. - bei nicht ganzzahligem Exponenten wird der Branch bei $BF99 ausgeführt, ist die Basis dann negativ, wirft das Logarithmieren dann den genannten Fehler).

    Noch zur Ergänzung: der Teilausdruck (-1)^n wird häufig genutzt, um ein alternierendes Vorzeichen, z.B. bei Reihenentwicklungen, auszudrücken. Selbst da wird explizit die (-1) in Klammern geschrieben, obwohl man theoretisch aus dem Kontext erkennen könnte, daß "-1^n" nur als (-1)^n und nicht als -(1^n) gemeint sein kann, da letzteres ja immer als -1 ausgerechnet würde und die Potenzierung damit sinnlos wäre.

  • CBM BASIC betreibt tatsächlich den Aufwand, diese Bedingung (Exponent ganzzahlig?) für negative Basis-Zahlen abzuprüfen! PRINT (-1)^2 und PRINT (-1)^3 sind z.B. erlaubt, PRINT (-1)^2.1 nicht und liefert ?ILLEGAL QUANTITY ERROR (siehe $BF8F..$BF99 in AAY64 - bei nicht ganzzahligem Exponenten wird der Branch bei $BF99 ausgeführt, ist die Basis dann negativ, wirft das Logarithmieren dann den genannten Fehler).

    Nicht schlecht; wusste ich noch nicht. Das sollte man dann besser auch im Hinterkopf behalten, wenn man im Programm ein schnödes a^b hat, bei dem aber a negativ und b krumm werden könnte.

    ---

    Mist, neulich hatte ich beim BASIC V2 noch einen heftigen Ungenauigkeitsfehler, den man so nicht unbedingt erwartet hätte. Aus Zeitgründen aber leider nicht notiert oder gespeichert. Vielleicht komme ich noch mal wieder darauf.

  • Calc.exe errechnet (-x)^y.

    Kommt darauf an, wie man es eingibt - hast Du die Taste mit dem Vorzeichen "+/-" benutzt? Diese Taste macht was anderes als das Minuszeichen und bezieht sich direkt auf die Zahl, also so, als ob sie geklammert ist. Wenn ich das mit der Minustaste eingebe, steht dann auch -9 in der Anzeige.

    Also Eingabe: [-] [3] [xy] [2] = ergibt bei mir -9

    Und Eingabe [3] [+/-] [xy] [2] ergibt 9.

    Getestet gerade mit Version 11.2307.4.0, wissenschaftlicher Modus

    P.S.: Damit man besser erkennt, welche Tasten ich gedrückt habe, habe ich diese in eckigen Klammern gesetzt.

  • Meine Feststellung bezog sich auf den Taschenrechner von Windows 7. Wenn ich [-] [3] [xy] [2] eingebe, steht bei mir in der Befehlszeile "0 - 3 ^ 2", was erwartungsgemäß 0 - 9 = -9 ergibt.

    Gebe ich [3] [+/-] [xy] [2] ein, wird auch bei Win7 als Ergebnis eine 9 ausgegeben. Finde ich an dieser Stelle schon etwas problematisch, sofern keine Klammern benutzt werden. In der allgemeinen mathematischen Notation ist das m.W. nicht zulässig. Zumal man die Minuszeichen dann optisch unterscheiden können müsste. Denn, was man beim Schreiben mal gemeint hat, steht ja nicht dran.

    Das Problem entsteht hier wahrscheinlich dadurch, dass das einerseits bei einem Taschenrechner normal ist, wenn ich erst eine -3 eingebe und dann potenziere, und andererseits hier oben im Rechner eine Notation stattfindet, die dann falsch aussieht. Im Grunde müssten dann im Moment der Potenzierung entweder automatisch Klammern um die -3 gesetzt oder eben dennoch eine -9 ausgerechnet werden.

    Mein Vergleich mit dem C64 bezog sich allerdings auf keine der beiden Eingabearten. Vielmehr hatte ich "- 3 ^ 2" mit der Tastatur direkt in die Befehlszeile geschrieben, die man nach F2 oder Doppelklick editieren kann. Davon mache ich des Öfteren Gebrauch, um längere Berechnungen nachträglich variieren zu können. Aber selbst, wenn man Leerzeichen zwischen dem Minus und der 3 macht, wird eine 9 errechnet.

    Bitte melde dich an, um diesen Anhang zu sehen.

    <edit> Ok, man darf/soll es wahrscheinlich gar nicht als Befehlszeile verstehen, sondern als editierbare Protokollierung von Tastendrücken. Das muss man aber auch erst mal so sehen. Aber auch dann hätte man eben den Unterschied mit dem Leerzeichen machen sollen. Denn bei der Eingabe von [3] [+/-] klebt das Minus direkt vor der 3 und bei [-] [3] wird es mit einem Leerzeichen getrennt.

  • Ja, jeder Computer, aber natürlich auch Algorithmus hat gegebenfalls seine Eigenarten oder Bugs.

    Daher ist es immer besser alles zu überprüfen.

    Schönen Gruß.