China DOS Union

CMD is limited in function. When doing division, it directly discards the fractional part of integer-division results, but there is also remainder calculation,
set/a a=97%7
6
that is remainder calculation

Actually I also have an idea for doing division with batch files, but it's rather intimidating, so I don't dare write it.

1. The resulting code would be extremely complex.
2. Execution efficiency would be very low. A rough estimate: if the divisor has several digits and the dividend has twenty digits, execution time could very likely reach dozens of seconds or even more.

I wonder if any expert would like to take on the challenge of division, with the requirement that, like the previous addition, subtraction, and multiplication, it can handle floating-point numbers and the number of digits is unrestricted. Let's wait and see!!!

Don't think it's impossible. Nothing is impossible. In my eyes that word doesn't exist.

Using batch files to implement unrestricted division is completely feasible~~~!

Originally posted by qwe1234567 at 2006-10-14 08:54:
CMD is limited in function. When doing division, it directly discards the fractional part of integer-division results, but there is also remainder calculation,
set/a a=97%7
6
that is remainder calculation

　　Although there is modulo arithmetic, and the result can be expressed in the format quotient……remainder, that only applies to integers. If division is done digit by digit following the model of floating-point addition, then how should the algorithm for decimal division be written? Even if the algorithm can be written, it would probably be quite complex and rather inefficient, wouldn't it?

Just calculate it like using an abacus

Updated code is in the 86th-floor post, welcome to keep testing

[ Last edited by he200377 on 2006-10-17 at 01:00 ]

There are still quite a lot of errors. 3.2/0.32 and 0.32/0.032 can't be calculated!

Originally posted by qwe1234567 at 2006-10-16 01:05:
There are still quite a lot of errors. 3.2/0.32 and 0.32/0.032 can't be calculated!

I thought of a fundamental way to solve it, hehe. Before calculating, make the numbers of decimal places the same, hehe, then the problem becomes much easier to solve

[ Last edited by he200377 on 2006-10-16 at 02:11 ]

That's good then!

Originally posted by he200377 at 2006-10-16 02:10:

I thought of a fundamental way to solve it, hehe. Before calculating, make the numbers of decimal places the same, hehe, then the problem becomes much easier to solve

[ Last edited by he200377 on 2006-10-16 at 02:11 ]

Brother he200377, the code in your 81st-floor post must have taken quite a bit of thought, hehe~ not bad.

But it has major limitations when calculating floating-point numbers. Let me mention a few immature suggestions here; I'm not even sure whether my analysis is correct:

1. It generates the temporary file ver_.txt. As long as the variables are used a bit better, there is absolutely no need to generate a temporary file.

2. I looked at that subroutine for removing zeros. You used twenty lines, but actually it can be solved in just a few lines.

3. The biggest flaw is the 9.99/9 case you mentioned. Looking at your code, this point wasn't thought through completely. The error mainly lies in carrying when removing the decimal point from the divisor and dividend. In the final decimal carry handling, no matter what value %x_wei% has, you always carry in the form 0.xxx. The integer part was originally a positive integer, but when the decimal point is carried, the integer digits become fractional digits.
What you mentioned here about aligning the decimal places first and then calculating is also a good idea, but originally it could only calculate numbers within 9 digits, and this would make the calculation range even smaller. That's not a good solution.
I suggest that at the end you read out the decimal-point position of the result, and then carry according to %x_wei%. If the number of digits is not enough, then pad with zeros.

4. About what moderator qwe1234567 said: 3.2/0.32 and 0.32/0.032 cannot be calculated! When the integer part of the divisor is zero, the error is quite serious; it goes into an infinite loop when processing the decimal point at the end.

5. 0.123/123=0.002609756097 Here an error occurs while reading the dividend; the characters are reversed.

This algorithm is still not mature, and it has limitations. Most importantly, it cannot break through the digit-limit restriction.

But when handling integers, it can improve precision.

Brother, you still need to keep working hard. If you want to break through the digit limit, this algorithm cannot do it.

[ Last edited by pengfei on 2006-10-16 at 08:20 ]

Updated in the 91st-floor post

[ Last edited by he200377 on 2006-10-18 at 05:54 ]

Hehe, actually for calculations, I think if you let cmd do the things it can do, it can still greatly improve efficiency, hehe

Reply to brother pengfei:

1. It generates the temporary file ver_.txt. As long as the variables are used a bit better, there is absolutely no need to generate a temporary file.
I had thought about this too. The reason I didn't do it that way was because I considered generality. Didn't you notice that every call can be transplanted completely? Hehe

2. I looked at that subroutine for removing zeros. You used twenty lines, but actually it can be solved in just a few lines.
Hehe~ this is what I was thinking: put out the few-line ones to show, haha~ so we can all learn together

[ Last edited by he200377 on 2006-10-17 at 01:06 ]

Still needs improvement, please look at the results:
Calculation result:
1321.1321/.132=86348.503267973
91.3/0.91=480.526315789
0.965/9.6=0.05927083333
0.0986/9.86=0.006987829614

Originally posted by he200377 at 2006-10-17 01:05:
Reply to brother pengfei:

1. It generates the temporary file ver_.txt. As long as the variables are used a bit better, there is absolutely no need to generate a temporary file.
I had thought about this too. The reason I didn't do it that way was because I considered generality ...

As for generating temporary files and removing zeros, you can refer to the earlier scripts; that kind of code is already there.