Roman numeral support in Number type

# Owen Swerkstrom (7 years ago)

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:

  • 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?
# kdex (7 years ago)

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.
  • 0 does 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.

# Bob Myers (7 years ago)

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

# Vic99999 (7 years ago)

An HTML attachment was scrubbed... URL: esdiscuss/attachments/20170707/1b12891b/attachment-0001

# kdex (7 years ago)

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.

# Tab Atkins Jr. (7 years ago)

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.)