Hab nun Vax Basic auf meiner VaxStation 3100.
Die Installation hat eine halbe Stunde gedauert.
Das Basic ist aber offenbar recht mächtig, es hat einen Interpreter und einen Compiler, kann Graphik = GKS usf.
Hab nun Vax Basic auf meiner VaxStation 3100.
Die Installation hat eine halbe Stunde gedauert.
Das Basic ist aber offenbar recht mächtig, es hat einen Interpreter und einen Compiler, kann Graphik = GKS usf.
Du könntest mir einen Gefallen tun, nämlich das folgende Programm laufen lassen:
Auf dem PET ergibt das die Werte 129,81,65,56,50,46,43,41,39,38,36,35,34,33,33,32,31,31,30:
Andere CBMs, einschließlich des C64, dürften die identische Arithmetik (https://www.c64-wiki.com/wiki/Floating_point_arithmetic) haben und das gleiche liefern.
Auf dem PET ergibt das die Werte 129,81,65,56,50,46,43,41,39,38,36,35,34,33,33,32,31,31,30:
Ist zwar jetzt etwas OT, aber die Frage fand ich interessant.
Auf einer WANG 2200T ergeben sich folgende Werte:
329, 208, 165, 142, 128, 118, 110, 104, 100, 96, 92, 89, 87, 85, 83, 81 ,79, 78, 77
Um wieder etwas näher ans Thema zu kommen habe ich das Miniprogramm von Toshi ebenfalls mal nachgebaut, mit folgendem Ergebnis:
Die Genauigkeit ist im Vergleich zu vielen anderen BASIC-Versionen schon eindrucksvoll - allerdings mit dem Nachteil, dass immer so präzise gerechnet wurde. Es gibt keine Integer-Typen oder ähnliches, mit denen man einfache Dinge beschleunigen könnte. Dazu muss man aber sagen, dass die Arithmetik auch so noch recht fix ist.
Was mir bei dem Vax-BASIC gefällt ist - neben den rund 40 Zeilen auf dem Monitor - das "bürokratische" Drumherum: man kann offenbar kein BASIC-Programm schreiben, ohne ihm direkt einen Namen zu geben, und beim Start wird immer schön Name und Datum/Uhrzeit dokumentiert. Da kommt schon ein Gefühl von Großrechner und Rechenzentrum hoch ...
Kann man hier evtl. auch Variablen mit höherer Genauigkeit deklarieren? Ich finde, dass 6 Nachkommastellen für so eine Maschine doch etwas mager ist.
Ist zwar jetzt etwas OT, aber die Frage fand ich interessant.
Auf einer WANG 2200T ergeben sich folgende Werte:
329, 208, 165, 142, 128, 118, 110, 104, 100, 96, 92, 89, 87, 85, 83, 81 ,79, 78, 77
Danke. Weißt Du, ob das eine IEEE-Arithmetik ist oder etwas eigenes?
masi: Klar, das sagt die Vax. Ich habe eine Weile grbraucht, bis ich in einem DEC PDP-11 BASIC Buch gefunden habe, daß man zwei Befehle in einer Zeile nicht mit ":" sondern mit "\" trennt....
Das VAXBASIC 3.7 scheint also in dieser Hinsicht so zu funktionieren wie das CBM Basic.
Im ersten Bild noch falsch:
Bei der Gelegenheit, wenn man Zeilennummern verwendet, kann mit mit "Resequence" ein renumber durchführen.
Danke. Weißt Du, ob das eine IEEE-Arithmetik ist oder etwas eigenes?
Nein, weiß ich nicht. Ich schätze aber, dass das eher was eigenes ist.
Zumindest die internen Darstellungen könnte man mal prüfen/vergleichen - das ist bei den Maschinen gut dokumentiert. Bei Interesse findest Du alles bei Jim Battle; er hat auch eine eigene Seite für die Fließkommaarithmetik.
Spricht jetzt aber nicht für die VAX ...
Bei Archimedes kann man BASIC normal benutzen, dann sollte da auch sowas rauskommen, aber es gibt auch ein BASIC64 mit erweitertem Zahelnbereich, mit entsprechend höherer Genauigkeit. Evtl. ist das ja bei VAX auch so, daß einen BASIC Aufruf gibt, der da noch eine Stufe hochschaltet.
Netzfind zum Thema
Netzfind zum Thema
Das Vaxbasic Handbuch von 1990 hat über 700 Seiten... Da finden sich auch Hinweise, wie man die Genauigkeit erhöhen kann:
Das VAX BASIC unterstützt maximal HFLOAT (max 33 Nachkommastellen).
Neuere Versionen für Alpha / Itanium kennen noch TFLOAT und XFLOAT mit noch höherer Präzision.
Meine Frage hat mit https://oeis.org/A336777 und https://oeis.org/A336781 und deren Verwandten zu tun.
Ich wollte aber nicht Toshis Diskussion kapern und werde daher für das Thema eine eigene Diskussion machen (hoffentlich noch heute), wo wir Ergebnisse vergleichen können. Hier also nur noch VAX-Basic und VAX-Arithmetik (wozu ich leider nichts beitragen kann).
run <dateiname>.exe
danke, geht!
run <dateiname>.exe
Oder
myprog:=="$device:[pfad]myprog.exe"
und jetzt einfach myprog auf die Kommandozeile und fertig.
Dann kannst du auch einfacher Parameter übergeben.
Hast du evtl. schon bei unzip gemacht?
sys$manager:systartup_vms.com
Nochmal zum Thema Genauigkeit. Wenn ich auf HFloat umstelle, erzeugt das Programm gar keine Ausgabe mehr. Ich muss einen Schwellwert wie <1e-32 angeben.
so die Originalversion - oder hab ich einen Typo irgendwo?
Bei mir, Version 3.9, steht HFLOAT nicht unterstützt auf VAX.
Bei mir, Version 3.9, steht HFLOAT nicht unterstützt auf VAX.
bei mir gehts, siehe Thread #8
Nochmal zum Thema Genauigkeit. Wenn ich auf HFloat umstelle, erzeugt das Programm gar keine Ausgabe mehr. Ich muss einen Schwellwert wie <1e-32 angeben.
Ich vermute, daß dann nicht 0 herauskommt, sondern eine Art 'Pseudonull', mit der Du vergleichen müßtest. So was ähnliches wie ein NaN, aber zur Kennzeichnung eines Underflows.
Oder vielleicht kannst Du irgendwie einen Fehlerzustand abfragen? Im BASIC-PLUS-2 User's Guide https://manualzz.com/doc/19753657/basic-plus-2-user-s-guide steht auf Seite B-32 etwas von einem Fehlercode 242 für "Floating underflow".
Hast Du so eine Null, die keine Null ist, mal ausgegeben?
Bei mir, Version 3.9, steht HFLOAT nicht unterstützt auf VAX.
bei mir gehts, siehe Thread #8
Bei mir auch, muss man nur richtig schreiben!
list
PEZU 11-AUG-2020 11:34
7 option size = real hfloat
8 option size = integer long
10 for n=2 to 20
20 a=1
30 for i=1 to 100000
40 a=a/n
50 if a=0 then print n,i \ goto 70
60 next i
70 next n
Ready
Alles anzeigen
ZitatAlles anzeigenrun
PEZU 11-AUG-2020 11:35
2 16385
3 10338
4 8193
5 7057
6 6339
7 5837
8 5462
9 5169
10 4933
11 4737
12 4571
13 4428
14 4304
15 4194
16 4097
17 4009
18 3930
19 3857
20 3791
Ready
Das nenne ich mal überzeugende Werte!
Wieso hat das bei Dir mit 0-Vergleich funktioniert und bei Toshi nicht?
Das nenne ich mal überzeugende Werte!
Wieso hat das bei Dir mit 0-Vergleich funktioniert und bei Toshi nicht?
Habe N hochgesetzt auf 100000
Das nenne ich mal überzeugende Werte!
Wieso hat das bei Dir mit 0-Vergleich funktioniert und bei Toshi nicht?
Habe N hochgesetzt auf 100000
In der Programmfassung, die ich in https://forum.classic-computing.de/forum/index.php?thread/20697-fließkomma-arithmetik-oeis-divisionstest/&postID=243423#post243423 benutzt habe, muß man keine Grenze angeben, hat dann aber ein Problem, wenn die Arithmetik sich merkwürdig verhält und man beliebig oft dividieren kann, ohne auf Null zu kommen. Man sollte es vielleicht so machen, daß man dividiert, bis die Werte konstant werden.
Unter OpenVMS Alpha gibts das "Vax Basic" auch. Dort heißt es "Compaq Basic".
Funktioniert auch. Leider hat man wohl den Interpreter wegrationalisiert bei der Konvertierung auf Alpha.
Interessante Eigenschaft vom VMS: Man kann Dateien nicht überschreiben. Wenn man "Test.bas" ein weiteres Mal editiert und speichert, wird aus test.bas;1 => test.bas;2.
Die Revision gehört zum Dateinamen und man kann die alte Version ganz normal verwenden. Läßt man sie weg, wird automatisch die neueste Version benutzt.
Das beschriebene Dateiverhalten hat bei DEC Tradition. Das ist schon in früheren Systemen der Fall. Für eine genaue Aufzählung der Systeme bin ich nicht sattelfest, denke aber an RSX-11 und RT-11.
Warum diese feine Eigenschaft nicht mit in CP/M oder DOS abgeklaut wurden ist mir schleierhaft.
Warum diese feine Eigenschaft nicht mit in CP/M oder DOS abgeklaut wurden ist mir schleierhaft.
Die Eigenschaft ist glaube ich Bestandteil des Files-11 Dateisystems?
Wahrscheinlich hat man es nicht übernommen, weil man um 1980 herum im Privatbereich noch mit jedem Byte herumgeknausert hat?
Der Interpreter ist wirklich weg bei der Alpha-Version: https://en.wikipedia.org/wiki/VSI_BASIC_for_OpenVMS
So eine Dateirevision kostet schon mehr als ein paar Byte. Nicht nur auf der Diskette sondern auch im File-Handling.
Und irgendwelche Unterschiede zwischen PC und Workstation musste es ja geben.