Roman numeral support in Number type
Oh, wow. Sorry, but I don't see this happening any time soon.
Here's just a few problems:
- Roman numerals are hardly ever used.
0does not have a standard representation.- Fraction representation is possible, but relatively complicated.
- The set of characters used for Roman numerals is non-standard. It varied over time and even geographically.
- Often times, there are multiple representations for one and the same number
- Fore more problems, see below.
Contrary to popular belief, Roman numerals do not just consist of a bunch of (non-standard) letters that represent numeric values. In fact, there were different kinds of dots (uncia, sextans, …) that represented values in a duodecimal fraction system as well.
Romans even started drawing lines around their numbers to indicate that the value of the represented numeral is multiplied or raised by some constant; look up "Vinculum". This was used to represent larger numbers.
Another thing that was used for larger numbers was the "Apostrophus", which was an encasing system to indicate that the encased part is multiplied by a constant. How would you handle that, and how would you treat the optional contractions? ("C|Ɔ" → "ↀ", "|ƆƆ" → "ↁ", etc.)
Suffice it to say that this doesn't fit into parseInt/toString(n) at all, as
Roman numerals are a nonpositional numeral system. Therefore, it doesn't
make sense to supply a radix.
This kind of functionality is best kept in libraries.
Can we also support Maya numbers en.wikipedia.org/wiki/Maya_numerals?
[image: Inline image 1] They apparently do have a zero, the shell glyph which looks like [image: Inline image 2].
Newlines matter; each new line is multiplied by 20. Inexplicably, these glyphs do not yet seem to be in Unicode.
Bob
An HTML attachment was scrubbed... URL: esdiscuss/attachments/20170707/1b12891b/attachment-0001
There's numerous problems with this approach.
While
new Intl.NumberFormat("it-u-nu-roman").format(100035);
procudes "ↈXXXV",
new Intl.NumberFormat("it-u-nu-roman").format(100035000);
produces "100.035.000". Turns out the largest representable number is 399999, but this might be implementation-specific.
Next,
new Intl.NumberFormat("it-u-nu-roman").format(0);
produces N, which is non-standard an might be undesired. There's no option
to turn this off. There's also no option to turn off apostrophus contraction.
Fractions don't work at all. And of course, vincula as well as parsing numbers
are also unsupported. There's also no way to control the numerals you want to
allow in general. In fact, the options you pass to Intl.NumberFormat are
pretty unflexible and don't allow for such detailed, locale-specific options.
I think this task should really be outsourced to a dedicated library.
On Thu, Jul 6, 2017 at 11:29 PM, kdex <kdex at kdex.de> wrote:
Turns out the largest representable number is 399999, but this might be implementation-specific.
Avoiding the more unusual characters is why CSS's roman-numeral list-numbering scheme drafts.csswg.org/css-counter-styles/#lower-roman is only
defined up to 3999 - that lets us stick with ASCII.
(I agree in general that this should be handled by i18n or by a userland library; there's nowhere near enough call to do this to justify it being in JS core, imo.)
This started as a joke, but after implementing it, I'd actually like to propose this as an addition and see what comes of it.
I've added support for stringifying and parsing numbers to and from Roman numeral representation, using the usual Number functions: var num = 5; console.log(num.toString("r")); // logs "V" console.log(parseInt("IX")); // logs 9 penduin/romanumber
I have two main questions:
This started as a joke, but after implementing it, I'd actually like to propose this as an addition and see what comes of it. I've added support for stringifying and parsing numbers to and from Roman numeral representation, using the usual Number functions: var num = 5; console.log(num.toString("r")); // logs "V" console.log(parseInt("IX")); // logs 9 https://github.com/penduin/romanumber I have two main questions: - Is this worth proposing? It seems silly, but does deal with real numerical representations. - Is using "r" as a radix sane? Would separate .toRomanString / .parseRoman be better?