Number.cmd

[obsidian needle]

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:

Number x = .75 * 3.2 f:.

stores 2.4 in the variable %x%.

With this new feature we now also reached a total amount of 100 tests :D

[sleek coyote]

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

[sleek coyote]

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 π = [phone]E-8

[obsidian needle]

But 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 😅

[sleek coyote]

Maybe I'm saying nonsense but

[obsidian needle]

btw I only did this because the repo received a new star and I felt bad for abandoning it 🙈 xD

[sleek coyote]

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

[obsidian needle]

but then I would loose precision, right?

[sleek coyote]

I mean losing precision is better than getting 2^31 - 1

[obsidian needle]

true

I think this would be a good temporary solution

[sleek coyote]

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

[sleek coyote]

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

[obsidian needle]

that should already work though. It's only a matter of precision, the size of the number is irrelevant

[obsidian needle]

maybe I'm understanding you wrong, but if I cut off numbers, the result will be slightly different, so I kinda still loose precision

[obsidian needle]

yeah, I don't think there's a high demand for this xD

[sleek coyote]

The idea wouldn't be to cut/truncate numbers but rather to multiply the smaller ones

[obsidian needle]

when are your exams?

[sleek coyote]

Sure, if you truncate you'll lose precision

[sleek coyote]

starting 7, and also 10, 13, 16 January

[obsidian needle]

but the problem is that the numbers are too long, so I need to truncate them in order to use set/a

[sleek coyote]

ahhh I see what you mean

[obsidian needle]

oh that's already this week 👀 good luck!!!

[sleek coyote]

I'm gonna fail linear algebra spectacularly

but anyways returning to this

[obsidian needle]

awesome! 😂 😂 😭

[sleek coyote]

if we separate out the digits we're gonna truncate and do it separately

and add them together at the end

[sleek coyote]

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

@obsidian needle

[obsidian needle]

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

[sleek coyote]

we would have to truncate the decimals in groups of 10 at max to avoid overflows in that same algorithm