endrain / omninumeric Goto Github PK

By design, Cyrillic converter supports reading numbers with decorator irregularities - including missing "thousand" marks. (Whether this design is right is another question - #4.) The problem here is that certain irregularly written numbers can break current translation algorithm.

Concider this number:
раi҂ра҃i

Let's agree that all our numbers are properly written left-to right, only some decorators are missing. Now, current algorithm will not interpret this as 111,111,000 as it should. It will interpret this as 222,000. It will take the "thousand" mark from the first numeral group and index value (1) for the second numeral group. Both will yield a multiplier of 1,000. Hence, 111*1,000 + 111*1,000 = 222,000.

#5 means that Omninumeric isn't going to validate input, instead just returning zeroes or empty strings on irregular input. But it's not impossible that someone using this library will need to write some checks. To support this, regular expressions must be published by respective modules.

Refactor to conform to EAFP principle.

Some tests fail on Python 3.0-3.6:

self.assertEqual(10001010001, cu_to_arab("҂҂҂і҂҂а҂іа҃"))
AssertionError: 10001010001 != 10001000010001

self.assertEqual(18, cu_to_arab("и҃і"))
AssertionError: 18 != 8010

self.assertEqual(1015, cu_to_arab("҂ає҃і"))
AssertionError: 1015 != 1005010

Code should be refactored to support broader range of platforms.

By current design, Omninumeric tries to read from alphabetic numeral systems as permissively as possible. Numbers in ANS are not required to follow the system's rules for decorators by the book. For example, Cyrillic converter would render this:
араi
as 1,111, even though the "thousand" mark before the leftmost a is missing.

Is this the right design choice or not?

Arguments for this design:

• ANSs generally have many variations within themselves. Cyrillic has two styles of writing with "thousand" marks and a third style implementing something entirely different. Byzantine Greek sees use of both number-long overstroke and "keraia" symbol for marking a number. It seems only natural to read as permissive as possible from such variable systems.
• Relaxed reading allows for relaxed regular expression. Stricter reading will require stricter regex, which at some point might become a pain in the back.

Arguments against this design:

• A system is a system, however variable it can be. There are rules for writing numbers in those systems, not guidelines. It would be only natural to demand that numbers read obey those rules.
• A "thousand" mark is not a decorator but a significant, meaningful component of a numeral - and a number. It would be irrational not to expect these marks be in order.
• Wrong inputs and corresponding results should be the user's problem, not the programmer's.
• Stricter rules for reading mean more concise conversion algorithm, and through that, better readability and sustainability.