![]() |
China DOS Union-- Unite DOS · Advance DOS · Grow DOS --Union site: www.cn-dos.net Forum site: www.cn-dos.net/forum |
| Guest | Log in | Register | Members | Search | China DOS Union |
|
中国DOS联盟论坛 The time now is 2026-10-24 08:55 |
47,815 topics / 349,928 posts / today 0 new / 48,287 members |
| DOS批处理 & 脚本技术(批处理室) » [Joint Participation] [Challenge Ideas] [Batch Processing Floating-Point Operations] |
| Printable Version 47,107 / 136 |
| Floor31 不得不爱 | Posted 2006-10-06 00:38 |
| 超级版主 Posts 2,044 Credits 5,310 From 四川南充 | |
|
The code on the 15th floor has been updated to integer/floating-point segmented calculation
Everyone is welcome to test... |
|
| Floor32 不得不爱 | Posted 2006-10-06 01:11 |
| 超级版主 Posts 2,044 Credits 5,310 From 四川南充 | |
|
The code on the 10th floor is wrong!
Please enter operand one:132165.134646454 Please enter operand two:132654.6546546 -2 132165.134646454+132654.6546546=-2? |
|
| Floor33 pengfei | Posted 2006-10-06 03:38 |
| 银牌会员 Posts 485 Credits 1,218 From 湖南.娄底 | |
|
It was already stated on the 10th floor: the decimal part can calculate up to 8 digits. But your decimal part has 9 digits, so it overflowed...
Found several defects in the code on the 15th floor; calculation error, adding 1 too many. The zero problem has not been fully considered: (111+111=223), (0.23+1.08=2.31)... Moderator still needs to improve the code. Specifically, both the code on the 10th floor and the code on the 4th floor solved it by adding 1 to the frontmost digit (this is also why the decimal parts in the code on the 10th and 4th floors can only calculate 8 digits). [ Last edited by pengfei on 2006-10-6 at 04:05 ] |
|
| Floor34 pengfei | Posted 2006-10-06 03:41 |
| 银牌会员 Posts 485 Credits 1,218 From 湖南.娄底 | |
|
Also, after improvement the code on the 4th floor is already general-purpose, and is even more advantageous than the code on the 10th floor.
Specifically, its calculation range is larger; decimal plus integer can calculate up to 17 digits. The code is more concise and has better fault tolerance! Just written, so there may still be some problems not yet considered. Looking forward to everyone doing comprehensive testing... |
|
| Floor35 不得不爱 | Posted 2006-10-06 07:43 |
| 超级版主 Posts 2,044 Credits 5,310 From 四川南充 | |
|
I just checked it; it turns out I typed set/a n1+=1 as set n1+=1, so an error occurred.
The 15th floor has already been updated! The decimal part can have up to 9 digits, the integer part can calculate up to 9 digits, and it supports input such as A 136.987 236, as well as entering A and then entering according to the prompts! Everyone is welcome to test... [ Last edited by qwe1234567 on 2006-10-7 at 03:45 ] |
|
| Floor36 不得不爱 | Posted 2006-10-06 07:50 |
| 超级版主 Posts 2,044 Credits 5,310 From 四川南充 | |
|
There is an error in the code above on the 4th floor. If there is 0 before the integer, it errors; the later decimal digits are not aligned!
a 008.64 36.6 无效数字。数字常数只能是十进制(17),十六位进制(0x11)或 八进制(021)。 .70 请按任意键继续 . . . a 8.64 36.6 44.70 [ Last edited by qwe1234567 on 2006-10-6 at 07:54 ] |
|
| Floor37 pengfei | Posted 2006-10-06 09:52 |
| 银牌会员 Posts 485 Credits 1,218 From 湖南.娄底 | |
|
Moderator, this kind of a 008.64 should belong to the category of erroneous input, right? I had not considered this. Let’s still test the various situations that may occur in floating-point calculations! I did not find the error tested on the 36th floor...
The moderator said that if there is 0 in front it errors; I’m afraid not, right? The digit-by-digit loop zero-removal method can remove all zeros at the highest digit. As for later decimal digits not being aligned, that is a formatted output problem and also was not considered; the code is only for testing whether the calculation result is right or wrong. If one insists on formatted output, adding corresponding code can also be considered. Everyone is welcome to test the calculation defects of the code on the 4th and 10th floors... [ Last edited by pengfei on 2006-10-6 at 10:16 ] |
|
| Floor38 不得不爱 | Posted 2006-10-06 19:29 |
| 超级版主 Posts 2,044 Credits 5,310 From 四川南充 | |
|
I mean I wrote the code above on the 4th floor (the file whose input is %1 and %2) into the A.BAT file, then entered in CMD:
a 008.64 36.6 无效数字。数字常数只能是十进制(17),十六位进制(0x11)或 八进制(021)。 .70 请按任意键继续 . . . a 8.64 36.6 44.70 |
|
| Floor39 pengfei | Posted 2006-10-06 19:42 |
| 银牌会员 Posts 485 Credits 1,218 From 湖南.娄底 | |
|
Hehe~ That section of my code is only limited to calculating inside the batch file and cannot accept input from variables %1, %2. The moderator should know as soon as he looks at it.
Congratulations, your code has already added the digit-by-digit loop zero-removal method and the code for adding 1 before the decimal part for calculation, solving this series of problems. It also adds code for use under CMD ^_^ Currently the code on the 4th floor, 10th floor, and moderator qwe1234567’s code all test normally... |
|
| Floor40 不得不爱 | Posted 2006-10-06 23:34 |
| 超级版主 Posts 2,044 Credits 5,310 From 四川南充 | |
|
Then where do the %1 and %2 in the 4th floor’s code accept variables from? (The code below is the one above on your 4th floor, please look!)
Where do the %1 and %2 in it accept variables from? |
|
| Floor41 pengfei | Posted 2006-10-06 23:35 |
| 银牌会员 Posts 485 Credits 1,218 From 湖南.娄底 | |
|
This section of script is the original one; many problems were not solved. Isn’t there another section below on the 4th floor?
|
|
| Floor42 不得不爱 | Posted 2006-10-07 03:08 |
| 超级版主 Posts 2,044 Credits 5,310 From 四川南充 | |
|
There is no problem with the section below on the 4th floor!
|
|
| Floor43 不得不爱 | Posted 2006-10-08 00:13 |
| 超级版主 Posts 2,044 Credits 5,310 From 四川南充 | |
|
New-idea calculation method:
Before calculation, leading zeros in the decimal part are automatically removed, trailing zeros are automatically removed, and leading zeros in the integer part are automatically removed. The largest result is: 2147483647.2147483647 (the largest result for the decimal part is .2147483647, and the largest result for the integer part is .2147483647) If the decimal parts of the addends both have N or more leading 0s, the decimal part digit count can be more than N+9 digits! Everyone is welcome to test! 321.00000000065496546+13.000000000046541346=334.000000000701506806 321.1105496546+13.1041541346=334.2147037892 [ Last edited by qwe1234567 on 2006-10-8 at 05:20 ] |
|
| Floor44 pengfei | Posted 2006-10-08 04:47 |
| 银牌会员 Posts 485 Credits 1,218 From 湖南.娄底 | |
|
After looking at the moderator’s code, there are two improvements:
1. When reading the integer and decimal parts of the two operands, you put them together to extract them. Nice idea ^_^ 2. If the first digit of the decimal part is zero, remove the zero for calculation. (Here leading zeros in the decimal part do not affect calculation; this is the same as integer calculation.) Although this section of code has not found an error in decimal calculation for the time being, it cannot calculate integers (the reason lies in removing the leading zero of the decimal part; if there is only one zero, then there is no operand. Even the several later lines of code will error). This problem can be solved. Previously I felt that adding 1 before all decimals was simple and convenient, but it could only calculate 8 digits. Hehe~ I still feel that a larger calculation range is more important; the code is being updated... |
|
| Floor45 不得不爱 | Posted 2006-10-08 05:22 |
| 超级版主 Posts 2,044 Credits 5,310 From 四川南充 | |
|
The problem of removing the leading zero in the decimal part, where if there is only one zero there is no operand, and even the several later lines of code will error, has already been solved. Updated on the 43rd floor.
Everyone is welcome to test! |
|
| Prev 1 2 3 4 5 6 … 10 Next |
|
[ Contact the Union admin team -
中国DOS联盟 -
Standard version ] Sponsored by ifanr Inc | © 2001–2023 |