The Atom types in wpf-math and CSharpMath #2
Comments
The CSharpMath MathAtom/IMathListThis is what I could find in the CSharpMath repo but I believe it's incomplete. I am unclear on why there are fewer cases than for wpf-math. Are some Atoms getting created directly through the MathAtom constructor rather than via a subclass constructor? @Happypig375 type Atom =
| List of Atom list // This is a MathList
| Accent of Atom
| Color of Atom * colorString: string
// What are the delimiters?
| Fraction of numerator:Atom * denominator:Atom * leftDelimiter:string * rightDelimiter:string * hasRule:bool
/// This is an Atom surrounded by bounds. Bounds are atoms with MathAtomType.Boundary
| Inner of inner:Atom * lBound:Atom * rBound:Atom
| LargeOperator of Atom * limits:bool
/// Atom followed by a number of primes
| Primes of numberOfPrimes:int * Atom
| Radical of degree:Atom * radicand:Atom
| Space of length:float<mu>
| Styled of Atom * Style
/// E.g. a matrix. Each list describes a row. Rows may have different lengths apparently.
| Table of (Atom list) list * interColumnSpacing:float<mu> * interRowAdditionalSpacing:float<mu> * columnAlignments: ColumnAlignment list
| Underline of Atom
| Overline of Atom
| RaiseBox of raise:float<mu> * inner:AtomThere are also dedicated hashing functions contained in the subclasses whose purpose I am not sure of. A superscript and subscript option is inside each MathAtom in CSharpMath. |
wpf-math enumstype TexDelimiterOverUnder = Over | Under
[<RequireQualifiedAccess>]
type TexAtomType =
| None
| Ordinary
| BigOperator
| BinaryOperator
| Relation
| Opening
| Closing
| Punctuation
| Inner
| Accent
// These are combined in wpf-math but seem like they should be separated.
type XAlignment = Left | Right | Center
type YAlignment = Top | Bottom
type TexDelimeter =
| Brace
| SquareBracket
| Bracket
| LeftArrow
| RightArrow
| LeftRightArrow
| DoubleLeftArrow
| DoubleRightArrow
| DoubleLeftRightArrow
| SingleLine
| DoubleLine
type TexStyle = Display | Text | Script | ScriptScript |
CSharpMath MathAtomTypetype MathAtomType =
| MinValue
| Ordinary
| Number
| Variable
/// A large operator such as sin/cos, integral, etc.
| LargeOperator
| BinaryOperator
| UnaryOperator
| Relation
/// Open brackets
| Open
/// Close brackets
| Close
| Fraction
| Radical
| Punctuation
/// A placeholder for future input
| Placeholder
/// An inner atom, i.e. embedded math list
| Inner
| Underline
| Overline
| Accent
| Group // what is a Group?
| RaiseBox
| Prime
| Boundary
| Space
///Style changes during rendering
| Style
| Color
///A table. Not part of TeX.
| Table |
|
Once we have a clearer idea about CSharpMath structure we can start to compare. |
|
Will revisit tomorrow. |
Is 'BigOperator' a typo? This is a circular reference.
Yes. See:
The Superscript and Subscript properties defined in MathAtom.
It's really the index of the radical. |
Opinionated comparison tableEquivalent
Take from wpf-math?
Take from CSharpMath?
Discuss
Remove?
|
|
CSharpMath has Overline atom too. |
Statement revoked. After looking into its source in wpf-math, it does seem to be better.
Equivalent to a MathAtom with MathAtomType.Ordinary, MathAtomType.Number and MathAtomType.Variable.
I don't really like the idea of coupling fonts with characters.
Do we really need an abstraction of text atoms here?
Equivalent to a MathAtom with MathAtomType.Ordinary, MathAtomType.Number and MathAtomType.Variable. CSharpMath does not separate text from symbols.
It is really a group with the accent and accentee inside.
It could be equivalent to the Boundary atom of CSharpMath. |
I agree. Let's discuss fonts and styles here: #3
It's open for discussion whether the wpf-math cases are right here. I don't have an opinion at the moment. But we should have cases so that everything is covered by the right case. Then the information is contained transparently in the tree structure instead of hidden in nullable fields of Atom which are only valid in certain cases. CSharpMath has the following properties in every Atom: This is why there are fewer subclasses in CSharpMath. But I prefer a complete subclass approach which would remove these properties. |
|
Right. I didn't notice the amount of redundant properties before. Guess I don't visit the code of MathAtom often enough. I'll try incorporating the wpf-math approach here. |
|
At the same time, I would want to get rid of the MathAtomType enum and replace it with type pattern switching on the MathAtom discriminated union. I want to apply the DRY principle here. I'll try writing an analyzer for switching on discriminated unions myself. |
Right we want the right C# model of DUs. Option A: an enum for all the cases (so finer than MathAtomType): enum MathAtomCase {Row, Overlined, Underlined, Radical,... };
public class MathAtom { public MathAtomCase Case; };
public class Row:MathAtom
{
public List<Atom> Atoms;
Case = MathAtomCase.Row
}
...
public Box Layout(MathAtom a) {
switch (a.Case)
case MathAtomCase.Row
Row r = (Row) a
return ... // something using r
case ...But I gather that C# doesn't give any warnings on incomplete enum switches. If it does then this would be the best approach. But if it doesn't then the enums don't give us much. Option B: forget the enums: public class MathAtom { };
public class Row:MathAtom
{ public List<Atom> Atoms; }
...
public Box Layout(MathAtom a) {
if a is Row r
return ... // something using r
elif a is ...
...(I may have got the some C# syntax wrong.) Were you considering either of these approaches? |
|
Enhanced Option B: abstract class MathAtom {
private MathAtom() { }
...
//Inner class
class Row : MathAtom {
...
}
class Color : MathAtom {
...
}
}Plus a [DiscriminatedUnionAttribute] and a custom Roslyn analyzer to enforce the completeness of the switch. |
|
I tried an F# DU Atom and a C# one similar to yours and they look identical to consuming C# code. |
Both libraries use C# and it was decided to stick with C#. The following is F# code because even if we don't compile it, it's good pseudocode.
The wpf-math Atom
In CSharp there is an Atom class and subclasses inherit from it.
These classes also contain code to generate a Box, which describes how to lay out and render it. I think this part can be moved into a separate layer and Atom classes just used to give a structural representation.
The text was updated successfully, but these errors were encountered: