suche Ideen: Darstellungroutine für math. Formeln schreiben

Walli

Hi,

für das aktuelle Projekt auf der Arbeit muss ich eine Darstellungsroutine für etwas kompliziertere mathematische Formeln schreiben (hoch, tief, Bruch, Summe etc.), da Bitmaps schlecht aussehen und Platz fressen. Dafür wollte ich Ideen sammeln. Als Format zur Beschreibung der Formeln will ich ein \LaTeX-ähnliches Format benutzen, allerdings bei weitem nicht so umfangreich. Habt ihr noch irgendwelche Ideen für mich, bevor ich anfange?

Gruß,

Mastah

Korbinian

hm, und latex selbst darfst nicht verwenden?
würd mir sonst halt genau überlegen, was das darstellungsdings können muss, und v.a. musst dir ne syntax überlegen, die leicht zu parsen ist

Walli

Also Latex selber verwenden soll ich definitiv nicht. Ich schwanke momentan zwischen 3 Möglichkeiten:

MathML, wobei das irgendwie schrecklich zu lesen ist
Latex-artiges Format, d.h. auf ein Minimum beschränkt. Stelle mir aber vor, dass es nicht ganz so einfach zu parsen ist wie MathML.
eigenes Format, das zur Not noch erweiterbar ist

Können muss das ganze:

Brüche
Integrale, Summen, Klammern etc.
Text hoch-/tiefstellen
versch. Sonderzeichen (ist aber erstmal Nebensache, da kein großes Problem)

Also folgende Formel sollte beispielsweise darstellbar sein...
$cos(z)=\sum_{k=0}^{\infty}(-1)^k\frac{z^{2k}}{(2k)!}$

Das wäre allerdings schon das Maximum an Anforderungen. Irgendwie schreit das ganze nach einem eigenen Format... Hat jemand ne Idee dazu?

Gruß,

Mastah

Korbinian

hm, in dem rahmen könnte man das schon selbst auf die reihe kriegen denk ich
mal ein paar sachen die du hinkriegen musst:
schriftausgabe: ich glaube soetwas wie einen pdf-output zu machen, ist etwas zu hoch gegriffen. ich würde vorschlagen, dass du irgendwie true-type schriften auf einer bitmap arrangierts, und dann als jpeg/png (da gibts ja libs) exportierst. vielleicht ist es geschickt, wenn du so ausdrücke in verschiedenen größen an bestimmte stellen in eine bitmap schreiben kannst. also etwa schreibInBmp(0, 0, "cos(x)", 3). dann musst du z.b. fuer hoch/tiefstellen sowie brüche nur noch berechnen, wo du den ausdruck plazieren musst.

syntax: würde ich so einfach wie möglich halten. sprich sonderzeichen extra (z.b. [sigma] oder [sum]) fuer hoch "^{ausdruck}" und tief "_{ausdruck}" und fuer bruch fract{zaehler}{nenner}. dann hast kein großen umstand, und das kannst recht schön parsen.

am schwierigesten dürfte die plazierung im bitmap sowie die erstellug der buchstaben sein

Walli

Also mit der Ausgabe wird eher ein sekundäres Problem sein, da ich ziemlich sicher nur in einen HDC rendern muss (das ganze soll unter Windows laufen). Allerdings werde ich den Parser deutlich abkapseln und die Ausgabe abstrahieren, also nicht sofort die Win-GDI-Funktionen benutzen, damit ich das Ding zur Not auch mal portieren kann. ich denke mit der syntax werde ich mir etwas einfaches überlegen. habe es mir aber ähnlich vorgestellt wie du.

naja, vorher spiele ich etwas mit den möglichkeiten der GDI rum. Nehme also noch revolutionäre Vorschläge zur Syntax entgegen ;).

rüdiger

ich würde etwas einfaches zu parsen nehmen, ungefähr so

frac{a,b}

entspricht $$\frac{a}{b}$$

exp{a,b}

entspricht $$a^b$$
etc.

wenn du alle Funktionen in einem ähnlichen Format machst, kannst du nämlich den Parser viel kleiner/einfacher machen.

Walli

Stimmt, ist auch ne gute Idee . Ich werde morgen mal ein kleines Format entwickeln.

Hi

zum thema portieren: wiso nicht gleich eine true type engine verwenden, die auf fast allen systemen läuft? wie z.B. FreeType2 wird beispielsweise beim Gnomdesktop eingesetzt. die Engine seber ist frei und gibts sowohl für windows als auf für unix/ linux.

gruss Termite

Walli

Hmmm, nur mein Arbeitgeber hält nicht so viel von solchen Sachen. Das Ding soll ja primär erstmal nur unter Windows laufen.

Winn

kingruedi schrieb:

ich würde etwas einfaches zu parsen nehmen, ungefähr so
frac{a,b}
entspricht $$\frac{a}{b}$$
exp{a,b}
entspricht $$a^b$$
etc.

wenn du alle Funktionen in einem ähnlichen Format machst, kannst du nämlich den Parser viel kleiner/einfacher machen.

Wenn Deine Syntax auch nur für den deutschen Raum gedacht ist, würde ich mich auch daran orientieren, welche Zeichen ohne drücken weiterer Tasten erreicht werden können. kingruedi benutzte runde Klammern, find ich gut, denn die eckigen können ja nur über ALT+8 erreicht werden... die SHIFT Taste empfinde ich hingegen nicht als störend, sie muß ja beim Tippen eh genutzt werden und liegt auch im üblichen Reich der 10 Finger

Gruß Winn

rüdiger

@Winn
jo, hab nur { } genommen, weil diese ja nicht in der Form in mathematischen Ausdrücken vorkommen, im Gegensatz zu ()

man kann natürlich auch so etwas nehmen

frac#a,b#

dann muss man noch nicht einmal SHIFT drücken :-þ

Oder nimm ein ganz einfache Syntax die sich eher an html orientiert.

<high>3</high>

etc.

MfG Max

rüdiger

nein! Viel zu redundant! Ist nicht nur umständlich beim schreiben, sondern verbraucht auch zu viel Speicher und ist nicht so leicht zu parsen.

Es hängt natürlich in diesem Fall sehr stark von der Zielgruppe ab,
ich wollte diesen Vorschlag nur bringen falls es für normale Anwender entwickelt wird, die sich nicht lange einarbeiten wollen/können.

MfG Max

rüdiger

aber ob die mit SGML-Style Syntax klar kommen?

ich finde es gerade, wenn ich aus der Mathematik Ecke komme doch logischer so etwas zu schreiben

frac<a,b>

anstelle

<frac><dividend>aa/dividend><divisor>b</divisor></frac>

(wobei man gerade hier den Vorteil der ersten Syntax sieht)

Jo, stimmt ist zu unübersichtlich, du hast recht.
Es ist für Komplexe Ausdrücke dann doch nicht geeignet.
Ich dachte zuerst daran das es einfach sein muss und hatte die Funktionalität ein bisschen vergessen.

MfG Max

Walli

Deswegen hatte ich mich ja gegen eine MathML-artige Syntax entschieden. Es ist einfach im Code schwer zu lesen. Ich denke mal, dass ich damit nach den Klausuren anfangen werde. Habe also noch etwas Zeit um mir was vernünftiges zu überlegen.