Lizard - Skriptsprache für symbolische Berechnungen, beliebig große und genaue Zahlen, Parallel-Computing und mehr

[Nino]

Zwei Wünsche von mir:

Das Beispielprogramm Example6_Console.pb ist sehr nützlich!
Es wäre eine komplette Anwendung, wenn es noch Callbacks für Warnungen und Fehler enthielte.
(Ich würde es vielleicht auch umbenennen in Lizard Console.pb oder so, weil es mehr ist als nur irgendein Beispielprogramm.)

In der Dokumentation sieht es so aus, dass wohl noch die Funktion Floor() kommen wird (= Runden Richtung minus Unendlich). Schön wären dann auch noch Ceil() (= Runden Richtung plus Unendlich) und Trunc() (= Runden Richtung Null).

[Nino]

Ich denke ich habe einen Fehler gefunden:

Code: Alles auswählen

Lizard kernel has been initialized.
Kernel version: 0.3.8-0003

In(1)   :=  (-9)^(1/2)
Out(1)   =  3*I

In(2)   :=  27^(1/3)
Out(2)   =  3

In(3)   :=  (-27)^(1/3)
Out(3)   =  3*(-1)^(1/3)

Die ersten beiden Ergebnisse sind OK, aber das richtige Ergebnis der dritten Berechnung ist -3.

[Helle]

@STARGÅTE:
@Lord: Das angezeigte Ergebnis ist richtig! Die von dir erwarteten mickrigen 4 Milliarden sind 2^32, zu berechnen ist aber 2^65536.

[STARGÅTE]

@Lord:
> "Ist in der Console eine Art maximale rekursive Tiefe o.ä vorhanden?"
In der Console? In PureBasic selbst gibt es eine maximale Rekursionstiefe für den Stack.
Den hatte ich schon mal für die DLL erhöht (/STACK:8388608), scheint aber nicht zu helfen für die Anwendung die die DLL dann nutzt .
Daher hat Lizard selbst noch mal ein Rekursionsstopp ab einer Tiefe von 512.

> "Nächster Schritt: 2^2^2^2^2"
Power wird von rechts gelesen, also 2^(2^(2^(2^2))).

@Nino:
Das Consolen-Beispiel werde ich erweitern, guter Punkt. Auch die Syntax-Fehlermeldungen sind aktuell noch sehr unaussagekräftig. Da muss ich dran arbeiten.

> "In der Dokumentation sieht es so aus, dass wohl noch die Funktion Floor() kommen wird (= Runden Richtung minus Unendlich). Schön wären dann auch noch Ceil() (= Runden Richtung plus Unendlich) und Trunc() (= Runden Richtung Null)."
Tatsächlich ist Floor() schon drin (nur nicht fertig). Die Funktion Trunc() wäre in Lizard ToInteger(), kann ich aber gerne doppelt belegen. Auch Ceil setzte ich auf meine Liste.

Nun zu der Frage ob "(-27)^(1/3)" zu "-3" werden sollte. In der Welt der reellen Zahlen mag das stimmen.
Geht man aber von allgemein komplexen Zahlen aus, gibt es drei Lösungen (zwei komplexe und -3) und -3 ist dabei leider nicht die "principal value" oder wie man das nennt, sondern die komplexe Zahl:
https://www.wolframalpha.com/input/?i=(-27)^(1%2F3)

Code: Alles auswählen

In(1)   :=  (-27)^(1/3) //Calculate
Out(1)   =  1.5+2.59808*I

[Nino]

Hallo Stargate, danke für Deine Antworten.

Nun zu der Frage ob "(-27)^(1/3)" zu "-3" werden sollte. In der Welt der reellen Zahlen mag das stimmen.
Geht man aber von allgemein komplexen Zahlen aus, gibt es drei Lösungen (zwei komplexe und -3) und -3 ist dabei leider nicht die "principal value" oder wie man das nennt, sondern die komplexe Zahl:

Code: Alles auswählen

In(1)   :=  (-27)^(1/3) //Calculate
Out(1)   =  1.5+2.59808*I

OK. Davon hast Du ganz sicher mehr Ahnung als ich.

Allerdings finde ich es irgendwie unbefriedigend, dass ausgerechnet die "glatte" einfachste Lösung nicht genannt wird.
Wie wäre es denn, wenn Lizard als Ergebnis alle 3 Lösungen zurückgeben würde: {Lösung1, Lösung2, Lösung3}? Lizard kann ja sowieso perfekt mit solchen Listen umgehen. Oder würde sowas nicht ins Konzept passen?

[Nino]

Ich habe in der Datei "Documentation.html" (Kernel Version 0.3.8-0003) einige sprachliche Fehler gefunden.
Ich sehe sowas, ob ich will oder nicht und ich weiß nicht, ob das ein Fluch oder ein Segen ist ... oder beides.

Tippfehler (Suche nach ganzem Wort -> Ersetzen)

Code: Alles auswählen

allways -> always
assingment -> assignment
contant -> constant
handeled -> handled
Indetermine -> Indeterminate
is typical unsed -> is typically used
leeds to -> leads to
negativ -> negative
numerial -> numerical
positiv -> positive
Powerfull -> Powerful
Seperators -> Separators
unexact -> inexact
wenn -> when

lateral sequence -> literal sequence (?)

Andere Fehler:
Das Wort "keeped" gibt es im Englischen nicht. To keep ist ein unregelmäßiges Verb: "keep, kept, kept".

Usually expressions with exclusively exact values, will keeped exact results.

Durch "will" wird das Futur ausgedrückt. Richtig ist: "will keep".

Log keeped unevaluated if no exact solution was found.

Hier muss es "keeps" heißen. Oder besser "remains".

Everything which can not evaluated into a simple object type will keeped ...

Richtig: "Everything which can not be evaluated into a simple object type will be kept ..."

[CSHW89]

Oh man, da erweckst du aber sehr alte nostalgische Gefühle:
http://www.purearea.net/pb/showcase/show.php?id=501

Bezüglich des Divisionsalgorithmus, den Dank nehme ich aber nur zum Teil an. Der Algorithmus kommt nämlich ursprünglich aus der Java-Standardbibliothek .

Hast du eigentlich auch vor, analytische Funktionen bereitzustellen, also Differenzieren, Limes, Integrieren? Differenzieren ist ja kein großer Akt, aber schon beim Limes bin ich damals nicht weitergekommen. Wenn du aber schreibst "Sehr mächtige Mustervergleichs-Engine" kann ich mir durchaus vorstellen, dass das damit machbar wäre. Der Algorithmus hinter der Mustervergleichs-Engine würde mich im Übrigen wirklich sehr interessieren. Sowas wie "2*a+5*b+a = 3*a+5*b" sieht ja recht einfach aus, fand ich damals aber schon relativ anspruchsvoll (also jeden möglichen Fall der Vereinfachung abzudecken, mein ich natürlich). Zumindest mit meinem damaligen Kenntnisstand

Bisher sieht das aber schon echt gut aus

[Lord]

@Lord:
> "Ist in der Console eine Art maximale rekursive Tiefe o.ä vorhanden?"
In der Console? In PureBasic selbst gibt es eine maximale Rekursionstiefe für den Stack.
Den hatte ich schon mal für die DLL erhöht (/STACK:8388608), scheint aber nicht zu helfen für die Anwendung die die DLL dann nutzt .
Daher hat Lizard selbst noch mal ein Rekursionsstopp ab einer Tiefe von 512.
...
[/code]

Gut zu wissen. Das sollte auch reichen.

...
> "Nächster Schritt: 2^2^2^2^2"
Power wird von rechts gelesen, also 2^(2^(2^(2^2))).
...
[/code]

Da hätte ich auch selber drauf kommen können.

Danke für die Antwort.

[Nino]

Meine erste selbstgeschriebene Lizard-Funktion: Umwandlung eines beliebigen Bruches in eine gemischte Zahl.

Code: Alles auswählen

Lizard kernel has been initialized.
Kernel version: 0.3.8-0003

In(1)   :=  Mixed(r?) := {a=ToInteger(r), r-a}

In(2)   :=  Mixed(10/3)
Out(2)   =  {3, 1/3}

In(3)   :=  Mixed(2/3)
Out(3)   =  {0, 2/3}

In(4)   :=  Mixed(-10/3)
Out(4)   =  {-3, -1/3}

Eleganter geht's nicht!
(außer Stargate kann das noch besser schreiben ...)

[STARGÅTE]

@Nino:

Um es nun sauber zu machen solltest du "a" schützen (ähnlich wie in Pure Basic mit Protected).
In Lizard geht das mit Scope:

Code: Alles auswählen

Mixed(r?) := Scope(a, {a=ToInteger(r), r-a})

Deine Korrekturen zur Dokumentation habe ich dankend zur Kenntnis genommen und werde es zeitnah korrigieren.

> "Wie wäre es denn, wenn Lizard als Ergebnis alle 3 Lösungen zurückgeben würde: {Lösung1, Lösung2, Lösung3}?"
Der Term (-27)^(1/3) soll ja an sich keine Lösungsmenge zurückgeben, sondern so (order umgeschrieben) weiter durchgereicht werden, bis er z.B. auf ein ^3 trifft und dann wieder eine -27 umgewandelt werden kann. Die Sache mit allen Lösungen ist aber ein weiteres Fernziel, nämlich Solve(): Dann würde Solve(x==(-27)^(1/3), x) eine Liste mit allen Lösungen geben.
___________________

@CSHW89:

Ja genau da ist es ... ComplexMath ... doch schon 12 Jahre her

> "Hast du eigentlich auch vor, analytische Funktionen bereitzustellen, also Differenzieren, Limes, Integrieren?"
Auf lange Sicht ja. Ein "Package" zum Differenzieren gibts schon, das muss dann auch garnicht "hard-coded" werden, sondern lassen sich direkt in Lizard definieren, wie zum Beispiel:

Code: Alles auswählen

Derive(f? + g?, x?Symbol)    := Derive(f, x) + Derive(g, x)
Derive(f? * g?, x?Symbol)    := Derive(f, x) * g + Derive(g, x) * f
Derive(f? ^ n?Integer, x?Symbol)   := n * f^((-1)+n) * Derive(f, x)

Dank der guten Mustererkennung werden in Lizard so auch Terme wie f+g+h differenziert, weil Lizard alleine weiß, dass es daraus (f)+(g+h) machen darf.
Das Lizard (bis zu einem gewissen Grad) Terme zusammen fassen kann, liegt weniger an dieser Mustererkennung sondern an den besonderen Attributen wie "Flat": verschachtelte Funktionen dürfen abgeflacht werden f(x,f(y,z))=f(x,y,z); und "Orderless": Argumente dürfen sortiert werden f(a,c,a) = f(a,a,c);
Dadurch werden Terme "automatisch" so modifiziert, dass die eigentliche Funktion Plus es dann einfacher Folge-Terme ggf. zusammenzufassen.

> "Wenn du aber schreibst "Sehr mächtige Mustervergleichs-Engine" kann ich mir durchaus vorstellen, dass das damit machbar wäre. Der Algorithmus hinter der Mustervergleichs-Engine würde mich im Übrigen wirklich sehr interessieren."
Das "Sehr" ist vllt etwas übertrieben, aber ich finde sie schon recht mächtig. Was meine ich damit? Nun, wenn für einen Ausdruck geguckt werden soll, ob es eine passende Definition gibt, so arbeitet die Engine ein bisschen wie die für Reguläre Ausdrücke. Das Muster f(x?, x?, y??) passt dann zB auf alle Funktionen f, bei denen das erste und zweite Argument exakt identisch sein muss, und danach beliebige viele (??) andere Argumente sein können. Nun kommt hinzu, dass die oben beschriebenen Attribute Flat und Orderless ebenfalls ausgenutzt werden können. Hier prüft die Engine also auch, ob die Definition vielleicht passt, wenn ich die Funktion verschachtel oder die Parameter umordne.
Wenn f z.B. Orderless ist, dann würde auch f(1,2,3,2) zum Muster passten, nämlich f(2,2,1,3).
Wenn f z.B. Flat ist, dann würde auch f(1,2,1,2,3,4) zum Muster passen, nämlich f(f(1,2), f(1,2), 3, 4).
Diese Mustervergleichs-Engine zu schreiben war schon sehr Zeit- und Nerven-raubend, dafür hat man jetzt viel mehr Flexibilität.