China DOS Union

Everyone knows that in batch processing, it is impossible to perform operations on overly large numbers. So how can we break through this limitation? We hope everyone will post and discuss the solutions...

I here provide one of my ideas, which I call the "column vertical form method" because it is very similar to the "column vertical form" in primary school. That is, respectively multiply each digit in the following number by the data above, and then add up all the data to get the answer. This method is based on this...

Test code:
@echo off setlocal enabledelayedexpansion echo Calculating... echo. set str1=123456789101112131415161718192021222324252627282930 set str2=123456789101112131415161718192021222324252627282930 echo %str1% echo × echo %str2% call :test %str1% "" ex call :test %str2% _ ex_ for /l %%a in (0 1 %ex%) do ( for /l %%b in (0 1 %ex_%) do ( set /a mult=!num%%a!*!num%%b_! set /a sum=%%a+%%b+1 rem Add up all data with the same number of digits: for example, add the digits in the tens place and the digits in the tens place; set /a result!sum!+=!mult! )) for /l %%a in (10000 -1 1) do ( if defined result%%a ( rem Define the variable for the previous digit set /a last=%%a-1 set var=!result%%a! rem If the number is greater than 10, carry over; if !result%%a! GEQ 10 set /a result!last!+=!var:~0,-1! set result=!var:~-1!!result! ) ) echo. echo =%result% pause>nul :test for /l %%i in (0 1 100) do ( set var=%1 if "!var:~%%i,1!"=="" set /a %3=%%i-1 & goto :eof rem Obtain the digits of thousands, millions, etc. respectively; set /a num%%i%2=!var:~%%i,1!)

Explanation: The above code currently supports the multiplication of numbers within 100 digits; for the above code, there are at least other improvement solutions that can improve the running efficiency, that is, I mentioned in another post "Using Batch Processing to Do Interesting Math Problems" before, the segmented calculation method. It is recommended to divide into segments of 5 digits. In this way, a large number of repeated and frequent calculations can be avoided, thereby improving the running efficiency. As for the latter calculation method, it is still in the testing stage.

The above is just one of my solution ideas. I hope everyone will criticize and correct it!

Remember that challenge, and these are all mentioned in batch operations

It seems that I, a newbie, have opened the wrong post again!
The original has already had discussions!
http://www.cn-dos.net/forum/viewthread.php?tid=23568&fpage=1&highlight=%E5%8F%82%E4%B8%8E

However, the above calculation method has drawbacks (temporarily does not support floating-point number calculation), but it also has advantages. When processing particularly large numbers, the running efficiency is much higher.
Under the same circumstances, the code provided in the above post takes a long time to calculate 123456789101112131415161718192021222324252627282930*123456789101112131415161718192021222324252627282930, but the above code can finish it in two or three seconds

If you change it to division, can you calculate pi? PI = 3.14...

Why does the code from the original poster say "operand not found. operand not found. Ah"?

There's no problem here for me!



As for the calculation of pi, using batch processing, it's difficult~ I think so.

Directly simulating assembly, using bitwise operations may be a good idea

It turns out there was an error in set /a num%%i%2=!var:~%%i,1!, it should be: set /a num%%i%~2=!var:~%%i,1!

I can't figure out why "set /a num%%i%~2=!var:~%%i,1! " can prevent some errors?

Because the second parameter in call :test %str1% "" ex is "", set /a num%%i%~2=!var:~%%i,1! will automatically remove the "" in %2. Otherwise, set /a num%%i%2=!var:~%%i,1! is equivalent to set /a num%%i""=!var:~%%i,1!, can this not go wrong?

In addition, the carry should start from the lowest bit, otherwise it will also go wrong, because sometimes there will be multiple consecutive carries, then your algorithm will go wrong

65536 multiplied by 65536 will truncate each digit.

I have written a division in the 26th floor here; The dividend can theoretically be arbitrarily large; the number of decimal places can theoretically be arbitrarily many; but it really doesn't work when trying 1 million digits; it will prompt that the output is too long; However, the situation where the divisor is greater than 10 to the ninth power has never been solved

http://www.cn-dos.net/forum/viewthread.php?tid=29097&fpage=5&highlight=&page=2

Hehe, indeed. Simulating assembly will calculate faster. The method is also simpler.