China DOS Union

Suddenly saw a question about rounding in the post!
Thought to myself, CMD doesn't support rounding operations.
But then when I turned to look at other posts, I had an idea and came up with the following algorithm..
Now I'm writing my algorithm below. Hope to progress together with the experts.
Also hope experts can streamline their code.
——————————————————————————————————
Idea:
Take the remainder of division. If the remainder minus half of the dividend is greater than 0, it means this number is rounded up. Otherwise, it's rounded down.
Added a judgment on the remainder, because the remainder can only be 2n or 2N+1. If it's 2n+1, then dividing this number by 2 meets the conditions for rounding. If not, continue with the following judgment
——————————————————————————————————
@echo off & SetLocal EnableDelayedExpansion
set /a divisor=25
set /a dividend=10
set /a remainder=%divisor% %% %dividend%
set /a reference_value=%dividend%/2
set /a reference_value1=%dividend%-%reference_value%*2
set /a carry=%remainder%-(%reference_value%+%reference_value1%)

echo %reference_value%,%reference_value1%,%carry%

if %carry% LSS 0 (
echo The result of %divisor% ÷ %dividend% is rounding down!
set /a result=%divisor%/%dividend%
) else (
echo The result of %divisor% ÷ %dividend% is rounding up!
set /a result=%divisor%/%dividend%+1
)
echo The answer is:%result%
pause
--------------------------------------------------------------------------------------------
Here I just threw out a brick.. but attracted a piece of jade out..

Everyone take a look at bjsh's code, it's getting more and more perfect each time.

Now it can basically handle division operations of any number of digits and ensure precision.

Everyone give bjsh more points :）

[ Last edited by flyinspace on 2007-4-1 at 08:33 PM ]

Thanks for lxmxn's pointing out.

Now the problem has been solved..

Another thing: the problem of progress bar display during file copying has been solved!

When copying files, you can see the progress of copying.

Only temporary files are generated.

There is a 1-3 second display difference when the hard drive is too fast and the file being copied is too large.

Now considering modifying this display issue.

[ Last edited by flyinspace on 2007-4-1 at 02:04 PM ]

@echo off & SetLocal EnableDelayedExpansion
set /p divisor=
set /p dividend=
set /a remainder=%divisor% %% %dividend%
set /a reference_value=%dividend%/2

if %remainder% LSS %reference_value% (
echo The result of %divisor% ÷ %dividend% is rounding down!
set /a result=%divisor%/%dividend%
) else (
echo The result of %divisor% ÷ %dividend% is rounding up!
set /a result=%divisor%/%dividend%+1
)
echo The answer is:%result%
pause

Directly judge whether the remainder is less than 1/2 of the dividend? Why subtract and then compare with 0?

Hehe, of course it can... But the code you copied now has problems. There will be cases of incorrect judgment under special circumstances...

Reply to floor 4. It makes sense. I made one more judgment.
I'm going to write a batch script and a C program to test divisors from 1 to 100,000 and dividends from 1 to 100,000.
To see if the code will have incorrect judgment.

This is what I wrote;

Precise to the decimal point you specified; rounded; everyone help test it

The code can be further streamlined; if you have time, post the streamlined one;

Everyone can also help streamline the code

1. @echo off &SetLocal EnableDelayedExpansion
   
2. set /p x=Please enter the dividend:
   
3. set /p y=Please enter the divisor:
   
4. set /p n=Please enter the number of decimal places to retain:
   
5. set /a count=0
   
6. set /a bjsh=10
   
7. :loop
   
8. if %count% geq %n% goto start
   
9. set /a bjsh*=10
   
10. set /a count+=1
    
11. goto loop
    
12. :start
    
13. set /a rest=%x%*%bjsh%/%y%-%x%*%bjsh%/10/%y%*10
    
14. if "%n%"=="0" (set /a last=%x%/%y%) else (
    
15. set /a last=%x%*%bjsh%/10/%y%-%x%*%bjsh%/100/%y%*10
    
16. )
    
17. if %rest% geq 5 set /a last+=1
    
18. if "%n%"=="0" echo The result is %last% & pause & goto exit
    
19. set /a result=%x%/%y%
    
20. set result=%result%.
    
21. set /a end=%n%-1
    
22. set /a bjsh=10
    
23. for /l %%i in (1,1,%end%) do (
    
24. set /a add=%x%*!bjsh!/%y%-%x%*!bjsh!/10/%y%*10
    
25. set result=!result!!add!
    
26. set /a bjsh*=10
    
27. )
    
28. set result=%result%%last%
    
29. echo The result is %result% & pause
    
30. :exit
    

BJSH posted on: 2007-04-01 13:22

[ Last edited by bjsh on 2007-4-1 at 01:32 PM ]

Hehē, the algorithm is just to provide a way of thinking.

. But bjsh really played this well : )

As for the test... I think forget it : )
The precision is not high. It's better not to test.

And since it's already ready to be written to a practical level...
Errors should be judged.
Otherwise, this is meaningless.

Yes
Only accurate to eight decimal places;

If it's higher, random numbers will appear;

When it's above a hundred, there will be strange combinations of - and numbers;

Here it should be related to the system

The algorithm of the code I wrote is different from that of flyinspace.

Brother flyinspace's algorithm is

Take the remainder of the division. If the remainder minus half of the dividend can be greater than 0, it proves that this number is rounded up by 5

Mine is: Use to magnify the actual result by 10^n to get the digit after the desired precision digit; then make a judgment
{/color]

Well. Then the first point. Need to judge the number of input digits! Try not to have random numbers.
Second, block the following random numbers.
Third, error handling mechanism.
I think this shouldn't be difficult, right?

Well;
That is quite simple.

Judge that %n% is greater than or equal to 8 and prompt that the precision cannot be higher than 8 digits; it won't be used later and can be shielded.

As for the error mechanism;
It is only judged in the front.
Just check whether x, y, and n are numbers.

I won't add this thing; leave it for those who want to use it to add. Anyway, it's just a few lines of code.

Hehe, let's try
100000 / 7

Hmm. You should also consider the practicality of the DOS progress bar issue, etc.

[ Last edited by flyinspace on 2007-4-1 at 02:05 PM ]

Dividing 100000 by 7 can only be accurate to 5 decimal places; and because the 6th decimal place is inaccurate, the 5th decimal place is also inaccurate; Is there a way to improve the accuracy?

Calculated with 18/7;

Can be accurate to the 8th digit but the 8th digit is also inaccurate;

Accurate to 7 digits is accurate;

The difference between 100000/7 and 18/7 lies in the number of digits;

So amplifying by 10^n does affect the precision;

Vaguely feel that improving the algorithm will increase precision; although the system itself has precision limitations;

But it should be able to be maximized

Um.. take a look at your own algorithm. You'll understand it :)

Only intercept the precision you estimate by yourself from the result.

And not just to judge the input. The input is only to help users not go astray to a certain extent.

The core is still the problem of your own script code.

What do you think?? Brother bjsh