17 ms·
While this format is more generic, an abbreviated encoding can sometimes accomplish the same thing. For example, just moving the "type" to be the object key an
by roller 10y ago
While this format is more generic, an abbreviated encoding can sometimes accomplish the same thing. For example, just moving the "type" to be the object key and removing the implied secondary name gets you this far:
{ "mrow": [
{ "mi": "x" },
{ "mo": "=" },
{ "mfrac": [
{ "mrow": [
{ "mo": "-" },
{ "mi": "b" },
{ "mo": "±" },
{ "sqrt": {
{ "mrow": [
{"mi": "b"},
{"msup": { "mi": 2 }},
{"mo": "-"},
{"mi", "4ac"}
]}
}}
},
{ "mrow": [
{"mi": "2a"}
]}
]}
}
It's not as general, but works if you know your syntax is similarly bounded. I don't know how certain static languages would handle serial/deserializing, but makes construction via javascript literals much more pleasant.
- jdmichal 10y agoSure, that works as long as each type only has one property. Decoding it might be problematic; I don't know any serializers that would handle that kind of mapping natively.
- wtbob 10y agoFWIW, this would be a literal s-expression translation: (mrow (mi x) (mo =) (mfrac (mrow (mo -) (mi b) (mo ±) (sqrt (mrow (mi b) (msup (mi 2)) (mo -) (mi 4ac)))) (mrow (mi 2a)))) And this would be a saner one, where mrow is implied: ((mi x) (mo =) (mfrac ((mo -) (mi b) (mo ±) (sqrt (mi b) (msup (mi 2)) (mo -) (mi 4ac))) (mi 2a))) I think either of those is clearly and inarguably superior.