Wishlist: special character support

[Klortho]

Here's an idea I had back in the day, but I'm not sure how useful it would be, really. We could add support for these units:

Symbol	Ord	Name	Meaning
µ	B5	Micro Sign	prefix for micro
¢	A2	Cent Sign	0.01 us-dollar
¹	B9	Superscript One	Raise the preceding term to the 1st power (the identity operator)
²	B2	Superscript Two	squared
³	B3	Superscript Three	cubed
×	D7	Multiplication Sign	multiplication operator
÷	F7	Division Sign	division operator
¼	BC	Vulgar Fraction One Quarter	number 0.25
½	BD	Vulgar Fraction One Half	number 0.5
¾	BE	Vulgar Fraction Three Quarters	number 0.75
		Others?

[jberger]

Other than the mu symbol, and perhaps the angstrom sign, I'm not sure the others make much difference. That said, adding unicode might be a worthy goal. Users might want to add units with unicode, perhaps we eventually support currency exchange rates, that would need some unicode. Worthy goal.

[benkasminbullock]

Since most physicists use LaTeX I would have thought being able to use LaTeX-style commands or output as LaTeX would be more useful than getting tangled up in Perl's Unicode stuff.

[Klortho]

Something like this unilatex.vim might come in handy.

[Klortho]

That said, I'd want to shy away from trying to implement too many mathematical operators. I'll admit a lot of the symbols above are kind of whimsical -- who would need the ¾ character to be properly implemented, after all?

I felt that implementing operators like "square" and "cubed" was a good idea, because they appear so often in the names of units, and maybe the superscript 2 and 3 could be implemented for that reason. But to try to implement real latex math expressions would be out of scope -- where would it end?

[jberger]

BTW check out: https://github.com/jberger/Text-AsciiTeX also https://metacpan.org/module/Text::AsciiTeX

I personally don't think that playing with cutesy characters are in the best interest. I do think that making sure that the module can handle user-defined units with unicode work correctly is.

[benkasminbullock]

Klortho says:

who would need the ¾ character to be properly implemented, after all?

Characters like ¾ are only in Unicode because Unicode had to encompass all of the crufty junk from old encodings like the Japanese and Chinese encodings from the 1980s, when people added this kind of character because all characters had to be in bitmapped graphics, or because some 1970s computer used these symbols in its bitmapped character set. They're not there because they were actually thought desirable as part of a modern standard. They are just in Unicode because Unicode had to be able to "round trip" from old standards and back again. It's better not to use any of these things except legitimate symbols like µ.

jberger says:

I do think that making sure that the module can handle user-defined units with unicode work correctly is.

The less the module does in terms of Unicode, the more likely it is that everything will "just work". If the module doesn't care about whether input strings are Unicode or not (is_utf8 or not), then Perl will probably take care of everything correctly. If the module starts insisting that input strings have to be one way or another, that is when things will break. As it is, if we don't do anything, the module probably will handle µ etc. correctly.