Hacker News Reader

Comment by mkl | Hacker News Reader

Even without technically changing font, there are more than you might expect: XxˣₓẊẋẌẍⅩⅹ⠭ꭖꭗꭘꭙ🄧⒳ⓍⓧＸｘ𝐗𝐱𝑋𝑥𝑿𝒙𝓍𝓧𝔁𝔛𝔵𝕏𝕩𝖃𝖝𝖷𝗑𝗫𝘅𝘟𝘹𝙓𝙭𝚇𝚡🅇🅧🆇

https://unicode-table.com/en/blocks/mathematical-alphanumeri...

View on HN

I think that violates the “only X, but in different fonts” dictum. Those are technically different glyphs and therefore very distinct names. A font would be the same character tagged in different ways, those are absolutely different characters. Aside from the visual similarity, a computer would never be confused into think they’re even remotely similar (kind of how to us 1000000001 and 10000000001 look almost indistinguishably similar, but are almost impossible for a computer to confuse).

That seems obviously true, except it is actually incorrect, at least as far as Python (3) goes.

The following are all interpreted as X in variable names: XⅩＸ𝐗𝑋𝑿𝓧𝔛𝕏𝖃𝖷𝗫𝘟𝙓𝚇

And these are all interpreted as x: xˣₓⅹｘ𝐱𝑥𝒙𝓍𝔁𝔵𝕩𝖝𝗑𝘅𝘹𝙭𝚡

I.e. 𝖃𝖝, 𝕏𝕩 and Xx all represent the same variable!

Edit: As a mathematician, this is actually kind of annoying. Sometimes I would love to have different variables named x and 𝐱, or whatever. Oh well, at least I can have θ, λ, φ, π, etc. Autohotkey macros make them easy to type.

Sure, that's true in Python. Python has some reasonable assumptions built into it in this ares. The X programming language, on the other hand, was built by someone whose prior work in language creation was so egregious as to warrant a court order against further such activity. (Only to be overturned, one would presume, on 1st amendment grounds)

“Language P has a mechanism by which it conflates several different glyphs into a canonical form for the sake of variable names” is not an “actually not true” kind of exception.

A mathematician such as yourself (and myself too) should recognise that asserting different things to be functionally equal is an entirely distinct phenomenon from what is being discussed here, which is differentiating a unique glyph based on a formatting that (font).

This bit is the incorrect bit: "a computer would never be confused into think they’re even remotely similar". Python is treating different glyphs as if they're the same but formatted differently.

I never understood why Unicode has bold versions of characters, that's the function of the font, not the character set.

Most of them are because they have different meanings in maths, so this makes it easier to represent maths using Unicodemath [1] or MathML.

[1] https://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.1...., https://docs.microsoft.com/en-gb/archive/blogs/murrays/unico...

Edit: [2] Similar for Latex https://www.ctan.org/pkg/unicode-math?lang=en

I'm pretty sure the first two links refer to something very different than the third:

The first two are about a way to encode maths using unicode, as in conventions and special characters allowing e.g. to write fractions, aligned equations, etc. So, this would essentially furnish an alternative to the "math" subset of latex (think mathjax or katex) or mathml.

The third is a package for latex, and allows to use unicode symbols (greek letters, math symbols, etc.) in your math environments + something related to the use of unicode in the output (requiring compatible fonts); it seems the second part is the main one but I'm not sure what that means exactly.

The Latex package says "Maths input can also be simplified with Unicode since literal glyphs may be entered instead of control sequences in your document source." So it at least includes a similar idea.

Superficially similar, yes, but my point was just that it may seem from your bunching up the links together that all refer to the same thing, while they don't.

Fair enough, I've edited it. I just tried using the Latex package with a formula typed using Unicode symbols, and it does work, but doesn't follow all the UnicodeMath rules.

I have always assumed this related to achieving a differentiated character set for Math and science formulas.

> why Unicode has

Because the distinction did already exist in the originating repertoire.

https://news.ycombinator.com/item?id=23029871

Symbolically same but semantically different characters are most of the time represented differently in the byte level so that searching in large text can still be implemented as simple byte comparison, if Unicode can be called simple.

"simply byte comparison" is not a term associated with Unicode. Unicode is usually in strings, and reverse engineering a string is -- very hard, and surprisingly I haven't found a paper proving whether it is NP complete.

That's the opposite of the rule for CJK characters, right? For those, symbolically-same characters get the same codepoint regardless of semantics (language) or shape (glyph).

Reply on news.ycombinator.com