Håller på med ett litet hobbyprojekt. Har tänkt att skriva ett program som påminner lite om Mathematica eller Maple. Man ska kunna skriva in uttryck på olika sätt, lösa ekvationer, rita grafer, derivera, integrera (åtminstone numeriskt).

Dessutom har jag en ide om hur man grafiskt skulle kunna skyffla omkring olika termer (etc.) i ekvationer.


Just nu funderar jag lite på syntax och semantik. Som det ser ut nu har jag tänkt mig något i stil med:
1. Alla symboler är likvärdiga, men det finns två olika "klasser". Definierade symboler och odefinierade.
2. En definierad symbol är strikt låst till just sin definition, och överallt där symbolen står kan den ersättas med definitionen.
3. En symbol som inte är definierad kan användas som parameter, variabel eller liknande. Den kan alltså förändra sitt värde i varje uttryck.
4. Skriver man ett uttryck X så tolkas det implicit som något i stil med Ans = X

Man skulle kunna tänka sig något i stil med:

y := x+5; //definition
z := y*3; //definition

y + 1 //evaluering av uttryck
=> Ans = x+6
y[x=2]
=> Ans = 7
u = z+1
=> u = 3*y + 1


Jag vet att det här är väldigt löst specat osv. Det är därför jag frågar här; någon som har ideer eller åsikter om syntaxen/semantiken?

Har många planer, men vill ha en basic syntax på plats först.

PS.
I stort sett helt OT, men kan ju bara kort säga tekniken bakom. C++, använder spirit från boost, kommer sannolikt använda wxwidgets eller qt för gui. Personligen kör jag med gcc/mingw, men bör fungera under MSVC7, eller högre (?)
Med allra största sannolikhet open source, jag gissar att jag blir tvingad till att välja en typ av licens med tanke på biblioteken jag använder.

Ingen som tyckte det här var intressant? =)

Jo för tusan, men jag har tyvärr ingen kunskap att hjälpa dig...

/DaPe

Det behövs inte så mycket kunskap; hur vill man kunna skriva in grejer?
Hur ska saker funka?
Är det ett logiskt sätt att arbeta på som jag har beskrivit ovan?

Jag försöker komma på idéer nu angående syntax, suttit i en timme och funderat... :)

Men problemet är nog att jag har alldeles för lite erfarenhet av användning av sådana program. Jag har bara kört matlab vid några enstaka tillfällen här på universitetet.

Personligen tycker jag det verkar väldigt logiskt det system du redan föreslagit. Några småsaker jag kan komma och tänka på är t.ex. att 'Ans' som kommer upp vid vissa uträkningar ska gå att använda på kommande rader (tills det skrivs över givetvis) men detta är ju bara petitesser.

Kommer du stödja vektorer där komponenterna är indexerade, typ y[0], y[1] osv... ska isf indexet stå inom []? Det går ju faktiskt använda [] till både "variabeltilldelning" och indexering. (kanske, vad vet jag?) Känns mest logiskt att variabeltilldening står inom (), som jag iaf oftast skriver när jag räknar matte.

Hur är det med stöd för matriser, diff-ekvationer m.m.? Om man vill räkna ut en derivata kanske y'x[x=5] kan vara syntaxen för att derivera y med avseende. på x? Nä, så här i efterhand så ser det ju väldigt fult ut kom jag på. (förresten, hur skulle man isf skriva integrering? Är nog bäst att köra med funktionsanrop typ 'Deriv(y, x, x=5)')

En ytterligare tanke, från LISP: Möjlighet att räkna med bråktal? Skriver man in 1/3 så behålls 1/3 och skrivs ut i svaret, typ 2 + 1/3.

Nä nu måste jag sluta, jag ställer ju fler frågor än jag ger svar :)

/DaPe

Har mycket av samma tankegångar.
Jag har tänkt att köra "halvfunktionellt". Definierade symboler är definierade på ett visst sätt, ickedefinierade lever i sin kontext.

Ans kan alltså inte användas efteråt, då den inte är definierad.
Vektorer och matriser har jag tänkt på, men det är en senare fråga. Det känns spontant som att det är något man ganska lätt kan lägga till i efterhand.

För att göra diffekvationer naturliga så krävs nog ett kort sätt att uttrycka derivator på; t.ex. ' eller D(f, x). Då funkar också integrering hyfsat snyggt; I(f, x).


Iden är just nu att en rad endast kan innehålla två saker; lösning av ekvation eller en definition.
Tanken är att alla grejer jag har kommit på kan omvandlas till lösning av ekvation.

Om vi tänker oss "standard-lösaren":
Solve(ekvation, symbol som ska lösas ut (x));
som alltid ger svaret på formen
=> x = ...

Så kan man säga att
x = uttryck;

kan omvandlas till
Solve(x = uttryck, x);


Och dessutom att
uttryck;

motsvarar
Ans = uttryck;

Som i sin tur är
Solve(Ans = uttryck, Ans)

Angående bråktal i LISP. Tänkte på exakt samma sak, också pga LISP. Det blir en senare fråga.

Matematiskt sett är arrayer en typ av funktion och skulle därför kunna ha samma syntax som funktioner.

Förslag:
<code>
v(1) := 3;
v(2) := 5;
v(3) := 8;
</code>
definierar en funktion/array v.

För att spinna vidare på detta skulle man kunna deklarera funktioner genom syntaxen
<code>
f(x) := x^3 + 2x^2 - 7x + 5;
</code>

Du körde själv med en syntax som påminner om funktioner:
<code>
y := x+5;
y[x=2]
</code>

Man skulle kunna tänka sig att "min" funktionssyntax kunde relateras till "din" syntax genom att man tillåter uttryck att användas som funktioner och att man kan ange i vilken ordning variablerna i uttryck skall tilldelas i detta fall:
<code>
f(x,y) := x^2 + 2xy + 3
</code>
betyder
<code>
f := (x^2 + 2xy + 3){x,y}
</code>
där {x,y} visar i vilken ordning variablerna binds:
<code>
f(3) --> ((x^2 + 2xy + 3){x,y})(3) --> ((x^2 + 2xy + 3){y})[x=3] --> (3^2 + 2*3*y + 3){y} --> (6y + 12){y}
f(3,5) --> [som ovan] --> ((6y + 12){y})(5) --> (6y + 12)[y=5] --> 6*5 + 12 --> 42
</code>

Alltså skulle...
expr1[var=expr2] betyda att expr2 substitueras för var i expr1,
expr{var} innebära lambdaabstraktion
expr{var1,...,varN} innebära "currering".

Angående arrayer; Det stämmer visserligen, men jag känner ändå att jag skulle vilja använda en vektor på ett annat sätt. Skriver man det på "funktionsform" så är det lätt att tappa storleken; jag vill att "u + v = w" ska vara hårt typat; u, v och w ska ha samma dimensioner. Sen känns det knepigt att konsturera vektorer i kod, kanske går snyggt med någon lambdaliknande variant.
Kanske. Det får vara en senare idé.

<b>>För att spinna vidare på detta skulle man kunna deklarera funktioner genom syntaxen
<code>
f(x) := x^3 + 2x^2 - 7x + 5;
</code>

Du körde själv med en syntax som påminner om funktioner:
<code>
y := x+5;
y[x=2]
</code>
</b>

Mmm... Det är primärt detta jag funderar på. Det finns tre anledningar till att jag hellre ser det som symboler som är definierade som uttryck hellre än funktioner av vissa variabler.
1. Det blir i någon mening enklare att skriva. Applikationen ska tills vidare bara vara ett ganska lättsamt sätt att arbeta med matematiska uttryck.
2. Det känns enklare att slippa hela curry- och lambdabitarna i type checkern. "En symbol definieras som ett uttryck. Är någon symbol i uttrycket definierad så kan man inte specificera den. Alla övriga kan man specificera."
Jag tänker på något i stil med:
<code>f(x,y) := a*x + y;</code>
Då måste man hålla reda på att a inte får specificeras, att x och y är lokala för funktionen. Och vid anropet f(3) har man ytterligare krav (a och x får inte specificeras, y är lokal, funktionen är dessutom anonym).
3. Jag vill inte skriva om hela Haskell fast med borttagning av ickenumeriska typer och med tillägget "derivata".

Apropå det, när jag skrev meddelandet så kom en grej. Låt säga att man skriver ett uttryck:
x + y;

Vad ska hända om man specificerar a i den kontexten?
Fel, eller ignoreras? Med tanke på det känns det bättre att köra med definierade funktioner.

Om inte annat känns det bäst att börja lågt, man skulle kunna göra precis så, att man kör en transformation på ast:n när man får ena formen.

Jag är tacksam för förslagen.

Intressanta idéer. Hur har ni tänkt det med typning? "Ett" objekt i stil med matlab eller ska det finnas flera, double, int, vector matris etc?

Tycker det vore bra om funktionssyntaxen skulle bli enkel. Så att man enkelt kan skiva in funktioner och utvärdera dessa. Känns som om det är en liten brist i matlab idag ( enligt mig).

Som nu har jag bara tänkt en enda; flyttal. (Precision och ev. komplexa tal en senare fråga.)
Angående vektorer och matriser så kan man antingen göra som Per föreslår (att låta vektorer av specialfall av funktioner) eller låta dem vara typade.

Typade var min första idé med tanke på att man vill garantera likadana dimensioner.


Per:
Nu kom jag på ett bättre sätt att beskriva varför jag ville göra på det sättet jag först beskrev.

Om man bara kör med att symboler är definierade som uttryck så kan man säga att man har en separat del med definierade uttryck.
Sen instansierar man hela den delen med värden på olika obundna symboler, eller mer generellt, gör operationer på de olika definitionerna där instansiering är en operation.


Erik, angående funktionssyntaxen:
Det är ett par alternativ på gång. In order of appearence:
- f[x, y] := x^y;
- f := x^y;
- f(x, y) := x^y;

Den första (som jag inte uttryckligen nämnt här) och sista är ekvivalenta förutom parentestypen.

Evaluering blir något i stil med:
f[x=5]

eller

f(5)

Om f då är definierat som
f := x+3;
blir svaret
=> 8

Men om f är definierat som
f := x + y;
blir svaret
=> 5 + y

När man kommer så långt som till plottning kan det till exempel bli :
Plot(f, 1, 5) ;
eller
Plot(f, x, 1, 5);
eller
Plot(f, x = [1,5]);