Number.cmd
Number.cmd is a new data type for Batch, that can represent large and floating-point numbers and enables calculation with those.
https://github.com/timlg07/Number.cmd
I just implemented a new feature that allows for input operands to contain floating point numbers in the usual, human readable version (like 2.74). With this feature it is now completely possible to never use or even see the internal notation and use all capabilities of Number.cmd with normal integers and floating point numbers.
Example:
stores
2.4 in the variable %x%.GitHub
GitHub - timlg07/Number.cmd: A new data type for Batch, that can re...
A new data type for Batch, that can represent large & floating-point numbers and enables calculation with those. - timlg07/Number.cmd
27 Replies
With this new feature we now also reached a total amount of 100 tests :D
Nice to hear that Number.cmd is getting an update after 4 years
I believe I found a bug with the division
Ah I see you're already aware of it at https://github.com/timlg07/Number.cmd/issues/42
GitHub
Division should work for numbers of any lengths. · Issue #42 · timl...
Currently the division algorithm still relies on set /a in some parts, therefore limiting the number range in which it can operate.
Say
A = a*10^(e1) and B = b*10^(e2)
I'm assuming 0 < a < 10 and 0 < b < 10
If this is the case, wouldn't it be possible to avoid precision issues by dividing first a / b, afterwards substracting the exponents 10^(e1-e2) and finally adding/subtracting again the resulting exponent when converting a / b into mantissa-exponential form?
I see that by looking at the code the issue lie in the way the decimals are represented, and that π = +314159265E-8But isn't that how it's done currently?
I need to get rid of that set /a there by manually implementing division
And all of these set /a need to go away as well 😬
But maybe I'm wrong rn, I haven't looked at this code for years 😅
Maybe I'm saying nonsense but
btw I only did this because the repo received a new star and I felt bad for abandoning it 🙈 xD
If you temporarily increase the size of either the numerator or the denominator such that the division c=a/b has 10^-9 < c < 10^9 and then dividing the power of 10 again to return it to normal?
This way you can still use set /a
but then I would loose precision, right?
I mean losing precision is better than getting 2^31 - 1
true
I think this would be a good temporary solution
If you temporarily increase the precision for the middle steps and then return it to normal you wouldn't lose precision
At the cost of performance but at least it'd work
It's for sure a hacky solution but it's the best way I can think of
+ this would allow for the division of numbers that would be < 10^-10
Right
I know probably it's not going to be used much by people but fixing the division issue could be a fun problem to solve
After I finish my exams I could try giving it a go
that should already work though. It's only a matter of precision, the size of the number is irrelevant
maybe I'm understanding you wrong, but if I cut off numbers, the result will be slightly different, so I kinda still loose precision
yeah, I don't think there's a high demand for this xD
The idea wouldn't be to cut/truncate numbers but rather to multiply the smaller ones
when are your exams?
Sure, if you truncate you'll lose precision
starting 7, and also 10, 13, 16 January
but the problem is that the numbers are too long, so I need to truncate them in order to use set/a
ahhh I see what you mean
oh that's already this week 👀 good luck!!!
I'm gonna fail linear algebra spectacularly
but anyways returning to this
awesome! 😂 😂 ðŸ˜
if we separate out the digits we're gonna truncate and do it separately
and add them together at the end
and apply the algorithm I mentioned this would make it possible without losing precision no?
this would only work for the division exceeding 2^31-1 due to properties of fractions
but the same thing, multiplying the numerator until it is an integer, divide, truncate zeroes, add together
@<Tim>
ohh true, I think I always thought that wasn't allowed for division, but yes, makes sense
at this point I can implement it completely manual for one digit at a time though xD
hm but your approach might be faster
we would have to truncate the decimals in groups of 10 at max to avoid overflows in that same algorithm
10 digits at a time instead of just one