Context Navigation

Timeline

7:13 PM Ticket #3764 (ConsoleWrite binary mode) updated by divinity76@…: @Jpm if you really believe that "stdout data corruption is an acceptable alternative to a binary write mode", then you're a moron.

2:54 PM Ticket #3515 (Assigning directly a value to an element of an array in array) updated by kovlad: I published my function for nested arrays (not read-only). https://www.autoitscript.com/forum/topic/205675-nested-arrays

4:45 PM Ticket #3817 (Double to Int64 type conversion - wrong results) updated by J-Paul Mesnage: Owner, Status changed
Fix sent to Jon

1:23 PM Ticket #3817 (Double to Int64 type conversion - wrong results) updated by J-Paul Mesnage: Checking the code I realize that big positive float lead to negative return due to precision loss so I decide to return in this case the max positive int64 Not sure is IEEE conversion compatible but I cannot accept a positive float number be converted as a negative number even if it is the max negative number …

9:12 PM Ticket #3820 (ProgressOn() - move feature) closed by mLipok: Works For Me: My mistake.
1:46 PM Ticket #3818 (InputBox() - TOPMOST option) updated by J-Paul Mesnage: Owner, Status changed
Will be set by default Fix sent to Jon
1:05 PM Ticket #3820 (ProgressOn() - move feature) updated by J-Paul Mesnage: I don't understand as the $DLG_MOVEABLE is doing the job
1:02 PM Ticket #3819 (_FileCountLines help file precision to add) closed by J-Paul Mesnage: Fixed: Fixed by revision [12523] in version: 3.3.15.4

7:49 AM Ticket #3817 (Double to Int64 type conversion - wrong results) updated by AspirinJunkie: The problem has already been reported here once: https://www.autoitscript.com/trac/autoit/ticket/3703 Anyway - the reasoning that this is not a bug is not correct. As explained here, rounding errors are not the cause, since these should only occur from 2⁵³ - not already from 2⁴⁹. Furthermore C/C++ gets along with this type conversion - only in AutoIt wrong results are produced. So the problem must be related to the internal handling in AutoIt.

3:24 PM Ticket #3820 (ProgressOn() - move feature) updated by mLipok: Summary changed
2:41 PM Ticket #3703 (2 ^ 49 and further return wrong results) updated by jchd18: Sorry but the "max precision of 15/16 digits" has nothing to do here. The max number of exact digits output by printf() and friends, as the example below clearly shows, is determined by the upper integral value stored exactly in a FP double. Direct cast from double to long long gives the correct result up to 2⁵³ (9007199254740992). You can check that the conversion from FP to string in plain C also is correct up to 2⁵³. So there is no valid reason why AutoIt would yield a wrong result below the limiting value, which is actually hardware-dependant (FP used in PCs has a 53-bit mantissa). Here's a very simple C program illustrating the facts: […] and here's the result: […]
2:00 PM Ticket #3820 (ProgressOn() - move feature) updated by TicketCleanup: Version changed
Automatic ticket cleanup.
1:36 PM Ticket #3818 (InputBox() - TOPMOST option) updated by mLipok: Description changed
1:28 PM Ticket #3820 (ProgressOn() - move feature) created by mLipok: Please add feature which give enduser the ability to move the progress …

6:06 PM Ticket #3819 (_FileCountLines help file precision to add) created by Nine: _FileCountLines should say in help file that it allows File handle AND …

10:00 PM Ticket #3818 (InputBox() - TOPMOST option) updated by TicketCleanup: Version changed
Automatic ticket cleanup.
9:39 PM Ticket #3818 (InputBox() - TOPMOST option) created by mLipok: Please add a feature to set InputBox() window as top most like …
10:02 AM Ticket #3817 (Double to Int64 type conversion - wrong results) created by AspirinJunkie: Following script: […] produces: $fN :562949953421312 (Double) …

Note: See TracTimeline for information about the timeline view.