Insufficient decimal places for results lower than 1
benPesso opened this issue · comments
This script should be extended to handle cases where the resulting conversion is lower than 1. Most common example would cryptocurrencies such as Bitcoin. Because the ration is so huge, and a single dollar is worth less than 0.0001 BTC, more decimal spaces are needed to properly display the resulting conversion.
In the current implementation, conv 1 USD BTC would result in 0.00 BTC, which is obviously incorrect. What the script should do instead is check whether the resulting conversion is lower than 1, and format the result using an alternate decimal places property. Say, MICRO_DECIMAL_PLACES.
which is obviously incorrect
It's hardly "obviously" incorrect. You have the workflow set to show 2 decimal places, so 2 decimal places is what you get.
What the script should do instead is check whether the resulting conversion is lower than 1, and format the result using an alternate decimal places property. Say,
MICRO_DECIMAL_PLACES.
I don't think that's the right solution. If you have DECIMAL_PLACES set to 2, then 0.1 should be shown as 0.10, not 0.1000000 (presumably you'd currently want 6 or 7 decimal places for BTC).
I'll look into dynamically adjusting the number of decimal places shown (up to, say, max. 10) so that at least one or two non-zero decimal places are show.
I've added a new option DYNAMIC_DECIMALS in v3.5. If turned on (the default), the workflow will show enough decimal places (up to 10) so that two non-zero decimal places are showing.
That should provide useful exchange rates for BTC without going crazy on other numbers.
It's hardly "obviously" incorrect.
It is incorrect, since, as you noted yourself, it should return 0.01 BTC. Not 0.00 BTC. (Maybe this should be reported as a separate issue, if you prefer.)
I don't think that's the right solution. If you have DECIMAL_PLACES set to 2, then 0.1 should be shown as 0.10, not 0.1000000 (presumably you'd currently want 6 or 7 decimal places for BTC).
Actually, you'd need 8 places, as that's what most exchanges are currently using...
I'll look into dynamically adjusting the number of decimal places shown (up to, say, max. 10) so that at least one or two non-zero decimal places are show.
...And you want to have all 8 places displaying, even if the last digits are zeros, as that's what you'd expect to see on a currency exchange.
Personally, I would create a separate logic for currencies and return the numeric value as it is returned from the exchange API (without rounding it up) and only formatting for readability. Along with that, I would add an OVVERIDE_CURRENCY_DECIMAL_SPACES option in the config to allow the user to make the script round up the result and format it based on the DECIMAL_PLACES value. Basically, this option will make the script behave as it currently does.
It is incorrect, since, as you noted yourself, it should return 0.01 BTC. Not 0.00 BTC. (Maybe this should be reported as a separate issue, if you prefer.)
I said no such thing. You don't round 0.0001 up to 0.01. That's off by a factor of 100.
Personally, I would create a separate logic for currencies and return the numeric value as it is returned from the exchange API
Very unlikely. All the conversion is done by pint. The workflow is a thin-ish wrapper around it to parse input and format output. As far as I'm concerned, currencies are just another bunch of units, and I don't see myself special-casing them (more than I already do).
Along with that, I would add an OVVERIDE_CURRENY_DECIMAL_SPACES option in the config to allow the user to make the script round up the result and format it based on the DECIMAL_PLACES value
I may add a separate CURRENCY_DECIMAL_PLACES option.
For now, I'm quite pleased with the dynamic decimal places: it works pretty well for everything, not just currencies.
I guess this will have to do for now. :)
Thanks for the quick response and resolve, though. Much appreciated!
I've added an override for the decimal places shown for currency conversions in v3.5.1