Isn't BigFloat excessive for this crate?

[pavloslav]

In fact, only a sequence of digits with optional minus and decimal period is needed. With BigFloat, some absolutely unneeded things like .acosh() or .is_subnormal() are compiled with this project for no reason.

I see two possible solutions:

• accept a string of digits instead of BigFloat as input;
• introduce an own type.

With our own type, we can support some other kinds of numbers, e.g., common fractions.

[Ballasi]

Honestly, even today after switching to BigFloat I am having this discussion to myself.

The reason why I ended up with BigFloat is that, of course it'll build stuff that will be useless for the project, but they are relatively minimal compared to other dependencies I have seen, as BigFloat doesn't have any dependency itself.

I have been thinking a lot about introducing my own type of bigint/bigfloat but that is hassle that other project have tackled for this particular reason, which is why there are crates for that.

However, even the current implementation of bigfloat is suboptimal, as seen in #11, BigFloat has a given precision, which at first I believed to be configurable, but apparently it's not. This means even with storing 1, it'll, at core, take 38 bits of precision, which is kind of overkill, but storing 1000...001 wouldn't work as the precision isn't precise enough too.

I've been thinking of taking strings, however, this can cause hassle in the long-run later as, once you find a way in to introduce data that isn't number (and there are a lot of ways), you can cause the program to crash/panic, which is better to avoid.

But honestly, even a normal number type is too much, in theory, all we need is a float we can multiply, divide and mod to 10^n -- implementing our own number type, and re-implementing multiplication, division and modulo would mean implementing them for any given set of natural number, which is overkill for this specific use-case too.

My best guess would be to store number as a tuple (Vec<u8>, u8), where the first corresponds to the number and the latter corresponds to the power of 10 it is multiplied by, basically:

([1, 2, 3, 4, 5], -2)
=> 12345 * 10^(-2)
 = 123.45

Multiplication, division and modulo are easy to implement with that, and takes virtually no effort, but this requires to make a specific type to implement Mul, Div and Rem to make it transparent to the Languages that implements it, but it leads to the issue I have talked about before.

Maybe it's cool to make separate functions (num.multiply_by_10(2) to say multiply by 10^2) but this seems a bit confusing to the person implementing the Language.

Maybe we should implement Mul, Div and Rem to expect to have a power of 10 as input, and panic if we do not, but I kind of want to avoid implementing panics, or we should just ignore it, since it can only be multiplied/divided/modulo of the same type, we should just look at the latter value and discard the table?

That's basically the internal discussion I have been having with myself, I don't know what are you thoughts on this? If you do have an interesting idea I am willing to hear it!

[pavloslav]

Once again: why exactly do we need multiplication, division and modulo, beside transforming a number into a sequence of digits, i.e. into a string?
Checking that the string is in the correct format (r"-?\d+.?\d?" for regex) is much easier (I'm not proposing to add regex in the dependencies, just stating; checking this manually is not much harder.

Besides, floats are bad for decimals, like
num2words::Num2Words::new(0.1 + 0.2).to_words().unwrap()
produces
point three zero zero zero zero zero zero zero zero zero zero zero zero zero zero zero four
and nothing can be done with that with floats. There is decimal crate too; but simple strings are just fine. On wrong data, validation will return an Err, no panic or anything.
Maybe I'm missing some use cases?

[Ballasi]

The example you are giving won't really fix anything by using strings, if you do "0.1" + "0.2", that doesn't work or (0.1 + 0.2).to_string() the result practically is the same.

Also, another issue I have with using regexp/manual check is that it requires a lot of processing power and substantially slows down the program. You could say it isn't much, and it's true, but if you compare that to the process of building BigFloat.acosh(), which is a one-time thing during build time, it's worse. On top of that, I am pretty much sure the rustc compiler is smart enough to not include these in the executable. In other words, it's excessive.

Overall, strings is mostly a hassle to work with -- it can be easier to implement sure, but it's also comparatively way slower and less safe as more prone to injection.

That's why I have been thinking of the idea of a string (a series of chars), but tailored to exactly a series of numbers, but it feels like it isn't right still.

[pavloslav]

What I'm trying to say is, it's anyway up to the user to provide num2words with the desired decimal precision; and decimal precision isn't even a property of the floating point number. 0.1+0.2 is user's operation that seems to produce 0.3, but it doesn't. Forcing the user to give us strings will make him think about what exactly he's passing in.

Validating the string is O(n), and the algorithm is anyway O(n), so I don't think there can be any real performance issue on this.

Oh, and btw 42.3 should be "forty-two and three tenth", not "forty-two point three"; one more option to think about.

[pavloslav]

More info: https://stackoverflow.com/questions/3730019/why-not-use-double-or-float-to-represent-currency

Btw, I was wrong about BigFloat nature. Excessive is an incorrect word. But still, I think it's unsuited for this crate purposes.