CatsAreCool

I'm working on a language MathLingua (www.mathlingua.org) whose goal is to precisely describe mathematics using a format that is easy to read and understand to help address ambiguity in mathematical texts written using natural language.

It is still a work in progress, but does it help address some of the problems you see in learning mathematics? Any feedback is greatly appreciated. Thanks.

It is similar. However, where omdoc seems to focus on storing math concepts in a precise way, it’s focus doesn’t appear to be on easily hand writing concepts in that format.

MathLingua, on the other hand, focuses on being precise and easy to read and write in its raw form.

That is correct, and the structure allows for computers to better understand the meaning of the math concepts being described, which opens the door to different analyses that can be done.

Looks interesting. Thanks for the link.

Great feedback. This is one of the areas that I designed MathLingua to help with.

Every definition has a ‘written:’ section describing how to express the math idea on paper and a ‘called:’ section describing how it is described when speaking.

Right now the ‘written:’ is used to render how a result looks, and in a similar way the ‘called:’ section can be used to convert a result into a transcript that a screen reader would read.

I haven’t yet been able to implement this feature though, but stay tuned for updates.

I’m glad you like it. One of the goals is to make discovering math easy and fun, in particular exploring theorems and definitions.

I haven’t added a reverse lookup yet where you provide a symbol and can find all things that the symbol can represent, but it is on the roadmap.

Yes, you can. MathLingua makes no assumptions about what symbols are used to represent different math operations (other than KaTeX is used to render expressions and so you need to symbols KaTeX recognizes).

As such you can use whatever visual representation you want for operations and definitions.

For a particular math definition, you can also specify multiple different notations for the concept (in this case, MathLingua uses the first one when rendering results).

An example of this is the derivative of a function in the “A Detailed Example” section of the docs.

I think having a tool but not being able to know how it works can be both amazing and frustrating at the same time (depending on the perspective of someone using the tool vs someone wanting to make the tool better).

Both perspectives are equally valid.

As a concrete example, suppose an alien cube suddenly appeared on Earth that, with a push of a button, would emit a pill.

It was discovered that the pill could cure half (but only half) of all known forms of cancer.

However, no matter how hard anyone tried, it was impossible to understand how the cube or the pill it created worked.

For those with cancer that took the pill and were cured, the cube was an amazing magical device.

For the people that took the pill and it didn't help them, the cube was worthless, since doctors couldn't tell them anything about why it didn't work, or what they could do to make it work.

For researchers it was frustrating because the cube showed some cancers are curable, but gave no reason why.

For the cancers it did cure, they didn't know why, and for those it didn't cure they also didn't know why.

Further it gave no insight into why only half were curable.

Was it because the cube was imperfect, or was that really the best that could be achieved?

For all intents and purposes, cancer research and treatment didn't really change. If you had cancer, you tried the magic pill. If it worked great. If it didn't, then doctor's were back to traditional techniques.

Thus from a knowledge perspective of one day curing all cancer, the cube didn't help, because the knowledge of how it worked couldn't be expanded to cure all cancer.

For someone cured by the cube, it was an amazing device, and nothing could change their mind.

For a cancer researcher, the cube was useless, and the only thing that could change their mind was if its mechanisms could be understood.

It is similar for math. As a tool, it is good enough to just know that the theorem is valid.

However, if you want to expand on that tool, develop more tools, or create different ways of looking at the problem, you need to understand why the theorem is true.

I thought of this, but couldn't find a nice way to fit this into the syntax.

That is,

  Theorem: "some text"

is the same as

  Theorem:
  . "some text"

Thus it would be hard to distinguish a named theorem with one statement

  Theorem:
  . "some name"
  . "statement 1"

from an un-named statement with two statements:

  Theorem:
  . "statement1"
  . "statement2"

So for now I'm leaving the name in the metadata section, but I'm open to putting the title higher if I can come up with a nice way to do so.

I have read through this before, but thanks for sharing the link.

Thanks for letting me know about the typo.

The dot space is used to mark arguments since some arguments span multiple lines but are connected. For example, in

  Theorem:
  . for: x
    where: y
    then: z
  . 'some statement'

the 'for:where:then' group together is one argument, while the 'some statement' item is the second argument. The dot is needed to distinguish from

  Theorem:
    for: x
    where: y
    then: z
    'some statement'

where it is hard to tell where one argument stops and another starts.

Cool. Thanks for letting me know.