Earlier quoted context omitted.
It is much more readable than the version using full-length words for variables.
i totally agree, but living in the world of mostly ascii-limited code this looks exotic, weird and refreshing. and cool
UnicodeMath – A Nearly Plain-Text Encoding of Mathematics (2016) [pdf]
11–20 of 59 posts
Re: UnicodeMath – A Nearly Plain-Text Encoding of Mathematics (2016) [pdf]
#12Earlier quoted context omitted.
It is much more readable than the version using full-length words for variables.
i totally agree, but living in the world of mostly ascii-limited code this looks exotic, weird and refreshing. and cool
So, for example, xˆy could be written as x superscript y. SUM[ihttp://www.ccs.neu.edu/home/samth/fortress-spec.pdf
Re: UnicodeMath – A Nearly Plain-Text Encoding of Mathematics (2016) [pdf]
#13Earlier quoted context omitted.
i totally agree, but living in the world of mostly ascii-limited code this looks exotic, weird and refreshing. and cool
> living in the world of mostly ascii-limited code this looks exotic this is is not the world where everybody lives. I live mostly in the world of math books, where all variables are single letters (which is the main difference here, and not the use of unicode). I tend to find code written by non-mathematicians ridiculous and unreadable. Instead of E = m * c^2 they seem to prefer bullshit like thing->Energy = thing->…
The problem then occurs when you work in a multidisciplinary group and 'everybody' wants to use 'p' or 'c' or whatever mean the the super obvious thing it means in their field and you have to remember what each letter means in 6 different fields and the 'p' in function f means something completely different from the 'p' in function g.
Re: UnicodeMath – A Nearly Plain-Text Encoding of Mathematics (2016) [pdf]
#14Earlier quoted context omitted.
i totally agree, but living in the world of mostly ascii-limited code this looks exotic, weird and refreshing. and cool
> living in the world of mostly ascii-limited code this looks exotic this is is not the world where everybody lives. I live mostly in the world of math books, where all variables are single letters (which is the main difference here, and not the use of unicode). I tend to find code written by non-mathematicians ridiculous and unreadable. Instead of E = m * c^2 they seem to prefer bullshit like thing->Energy = thing->…
thing->Energy = thing->Mass() * pow(speedOfLightInVacuum, 2)
And you can obviously clean it up further by using variables and just write auto mass = thing->Mass();
auto c = speedOfLightInVacuum;
thing->Energy = mass * pow(c, 2);
// or thing->Energy = mass * c * c;
// or thing->Energy = mass * c**2; (for languages that support it)
The issue is that in "E = m c^2", it's obvious from context what everything refers to. In programming languages, that's not necessarily the case. You can have "thing", but also "other_thing" and "array_of_things". And all those things can have many different properties. And those things can be either objects, or pointers to objects.You're not wrong: it's a definite flaw of many programming styles (and programmers!) that they're "too wordy". But it's also true that mathematics can get by with a bit of ambiguity that humans can handle that computers can't.
Re: UnicodeMath – A Nearly Plain-Text Encoding of Mathematics (2016) [pdf]
#15Re: UnicodeMath – A Nearly Plain-Text Encoding of Mathematics (2016) [pdf]
#16This is actually the method used by MS Word as far as I know, or a reduced dialect of it. It's a mix of convenient and inconvenient, can't make my mind up about it. All I know is that LaTEX is much, much easier to manage than this jumbled mess...
> All I know is that LaTEX is much, much easier to manage than this jumbled mess... LaTeX is beautiful and powerful, but mixed with unicode (in the right doses) it becomes astonishingly more powerful. For example, you can keep the block constructors {} _ and ^, but use unicode symbols such as α, ∂, ∫, instead of \alpha, \partial, \int
Re: UnicodeMath – A Nearly Plain-Text Encoding of Mathematics (2016) [pdf]
#17Earlier quoted context omitted.
> All I know is that LaTEX is much, much easier to manage than this jumbled mess... LaTeX is beautiful and powerful, but mixed with unicode (in the right doses) it becomes astonishingly more powerful. For example, you can keep the block constructors {} _ and ^, but use unicode symbols such as α, ∂, ∫, instead of \alpha, \partial, \int
But you can't type α, ∂, or ∫ in a standard keyboard.
Re: UnicodeMath – A Nearly Plain-Text Encoding of Mathematics (2016) [pdf]
#18Earlier quoted context omitted.
But you can't type α, ∂, or ∫ in a standard keyboard.
You can on a Mac. Holding the option key allows typing a whole host of symbols. https://beebom.com/how-type-hidden-mac-keyboard-symbols/
Re: UnicodeMath – A Nearly Plain-Text Encoding of Mathematics (2016) [pdf]
#19Earlier quoted context omitted.
But you can't type α, ∂, or ∫ in a standard keyboard.
You can on a Mac. Holding the option key allows typing a whole host of symbols. https://beebom.com/how-type-hidden-mac-keyboard-symbols/
Re: UnicodeMath – A Nearly Plain-Text Encoding of Mathematics (2016) [pdf]
#20This is actually the method used by MS Word as far as I know, or a reduced dialect of it. It's a mix of convenient and inconvenient, can't make my mind up about it. All I know is that LaTEX is much, much easier to manage than this jumbled mess...
It's the same one as implemented in MS Word (and PowerPoint, OneNote), this standard was written by an engineer who is on the Math in Office team and maintains a blog [1]. It's the best WYSIWYG equation editor I've used so far. LaTeX has its place, but it's hard to convince non-coders to use it and I'm glad it has the editor. I stumbled into this specification trying to format a constrained optimization problem and f…
For me, I'm able to use both LaTeX and this, but the main points that make this more convenient to me is that it relies less on characters that are present in awkward locations in many keyboard layouts (such as {}) and the equivalent formula is often much shorter due to somewhat more advanced tokenizing (of course, specific to math input, as the format doesn't have the same constraints as a general-purpose programming and markup language), e.g. x^12 works for x to the power of 12 instead of resulting in x^1 2.