Compromise: Better Fraction Support

[michaelmesser]

• [x] Handle Spaces
• [x] Vulgar Fractions (Single Code Point)
• [ ] Subscript, Superscripts, and Unicode Fractions Slash
• [ ] Handle words

[michaelmesser]

Should I replace the fancy unicode characters with the normals before parsing or should I handle them during parsing?

[spencermountain]

good question. i'd support your choice. they're already tagged as Value in the pos-tagger now right?
it would make sense to me that they be passed-around as unicode, and only become an integer after value.parse() runs
¯_(ツ)_/¯

[michaelmesser]

They are not tagged as Value

[michaelmesser]

Put them in data/number.js right?

[spencermountain]

yeah, then in ./src/lexicon.js
thanks.

[michaelmesser]

How can I ensure that when parsing "1½" that "1" and "½" are parsed separately (in the to_number method)?

[spencermountain]

yeah, if tagger.js identifies them both as Value, they'll be lumped together into one string by lumper.js.
so that to_number method will need to split them back apart, which i think you're already doing, if i'm correct.

... i guess if a fraction appears before a number, it's ½ * num, but if it appears after, it's num + ½?

i think the decimal logic in to_number is similar - eg "two point eight nine". Dunno.
it may be sensible to split-out fraction_parse, decimal_parse, etc in to_number, to make your life more pleasant. Up to you. :bow:

[michaelmesser]

"-1½" is parsing. For some reason "- 1" fails. Not recognized as a value

[michaelmesser]

"- 1" working

[michaelmesser]

"- 1 ½ 1/2" is -2. Should it be different?

[michaelmesser]

For superscripts should 3³ be 33 or 27 or nothing? Wolfram Alpha says 27. I think it should fail.

[spencermountain]

hey @2426021684 is this ready to pull in?

[michaelmesser]

Sorry I forgot about this. I still have to figure out how to get fractions recognized as values.