Group Abstract Group Abstract

Message Boards Message Boards

New graphic notation to express math relationships

POSTED BY: Joseph Anglada
6 Replies

Hi @Joseph Anglada, did you have any further progress with this?

POSTED BY: Marina Shchitova

Joseph have you had any progress on this? Seems like very interesting idea and you should probably look into Graph functionality.

POSTED BY: Vitaliy Kaurov
Posted 10 years ago

Hi Joseph,

I guess I'm a bit confused. In your first diagram, how can you infer that the upper 2 and 3 means 2^3 and not 2*3, 2+3, etc?

Also how does your idea scale with arbitrary functions? For example can you make a diagram for y = sin(2x)?

p.s. Have you seen the function TreeForm?

TreeForm[y == m x + b]

enter image description here

POSTED BY: Greg Hurst

Have you seen this example

neat example

and did you know that physicist Richard P. Feynman (a big diagramatic person, by the way) in his youth used to use his own symbolics because he felt the official (common-sense) notation awkward and confusing ... later on the wish to be understood and to be able to communicate with others let him switch back to the usual notation (invented on its own by some mindful people, too) ...

POSTED BY: Udo Krause

This probably could be implemented in Wolfram Language. Do you have any code for this - I have not seen any Mathematica files in your linked GitHub repository.

Another question. How do you suggest dealing with self-overlapping branches for large enough expressions? First thing that comes to mind is scaling down the branch size on deeper tree levels.

POSTED BY: Vitaliy Kaurov

Hi Vitaliy;

I have not yet implemented this on any programming language, since my main purpose was to design a notation. However, that would be a good project to implement it in code, and I hope to start a project like that in the future. I know some python and ruby, but I have never used Wolfram Programming Language for projects. I appreciate that suggestion, since I know it is a good language for this purpose.

Also, I would like to find flaws and ambiguity first, before implementing it, because I fear I could loose valuable time implementing something that may not work.

Another question. How do you suggest dealing with self-overlapping branches for large enough expressions? First thing that comes to mind is scaling down the branch size on deeper tree levels.

Good question. I suggest pipes (long lines and L's) to avoid overlapping (you can actually play with the length of the branches), but also variables to replace whole sections of the expression and express them somewhere else (or omit them, if they are not being discussed).

My biggest concerns are redundant variables in the same tree. I know traditional notation would allow them, but I'm not sure they work very well with this notation.

Thanks.

POSTED BY: Joseph Anglada
Reply to this discussion
Community posts can be styled and formatted using the Markdown syntax.
Reply Preview
Attachments
Remove
or Discard