Gem numbers_and_words not working for decimal values about numbers_and_words

[sorich87]

Do we need to do something for other languages? E.g. in french, we use a comma (spelled 'virgule') instead of a dot.

[eLod]

well for example in hungarian i believe you have to explicitly include the capacity for the fraction part, e.g. 21.7 is something like 'twenty-one point and seven tenth', but i have to research the hungarian grammar rules further

[kslazarev]

It's a temporary solution. Of course need to refactoring. Float#to_words is not language dependent function, so first of all, language words should be in appropriate places and I think there are many language-specific subtasks. Maybe @sorich87, @eLod you could get this task and try to create a good solution for appropriate language French, Hungarian as in English and Russian the approach is quite simple.

[eLod]

i created a topic branch for this issue so we can speak more easily about it (compare). this is only a proof-of-concept so i can verify my ideas. @dblock any thoughts about the english translations?

[sorich87]

I think in english digits after the 'point' are spelled one by one, or you use 'and' instead of 'point' and you pluralize the 'micro' part.
E.g. 21.77 = 'twenty-one point seven seven' or 'twenty-one AND seventy-seven hundredthS'.

[eLod]

well i'm not terrible familiar with precise english grammar, also i'm not sure if this is a common idiom. in hungarian we only have the 'proper' form which includes the fraction 'magnitude' (e.g. 'hundredths') - also the missing pluralization of this magnitude is simply an overlook on my part (we don't pluralize them in hungarian). the second from (the '... point seven seven') i believe we have in spoken language but i don't think it's a proper way (as per the hungarian grammar rules). so i think based on how common this second form is (e.g. how about french, spanish or italian?) it can be implemented in a separate strategy (which can be included in given languages) or in base.

also i've tried not to touch the API, so the way i'm handling the integer and fractional parts may need some refactor. also i moved the float (and integer) extension to numeric. what i recently recognized is that we will have problems with large floats, e.g. ((42 ** 42) + 0.1).to_s would return scientific notation for which our conversion will fail (not sure how we could convert this to decimal form, maybe with sprintf?).

[sorich87]

If you make the fraction magnitude part optional, it will cover french and spanish (and I guess other latin languages as well).

IMO, this library shouldn't cover scientific notation. Whoever need to handle it could do the rounding themselves and chose which rounding method is more appropriate to their use case.

[eLod]

1, you mean in french, spanish and other latin languages they don't include the 'magnitude' by default? or all of them have this 'terse' format (remember, 'zero point seven seven' not just does not include the 'magnitude', it also has the fractional part spelled otherwise, e.g. 'seven seven' instead of 'seventy-seven')? do any of them have the 'proper' format?

2, i did not mean to say that this gem should support scientific notation. my problem is that (42 ** 42) + 0.1 is a float, so right now neither do we raise any errors (although we have a validation hook), nor do we return the correct answer (we cast everything - but the "." - to_i, so "1.50130937545297e+68" will be converted as "1.501309375452970068"). i only wanted to be sure to handle this situation (either by raising an error or returning the correct answer).