mIRC Homepage
Posted By: maroon $modinv GPF in .doubles mode - 20/01/23 06:46 PM
Scripts should be fine as long as they don't make a typo <cough>

1. When input reaches the range near 2^1024 where doubles mode just returns 0, $modinv triggers a GPF

2. OK. If replace $modinv with $gcd, it switches to returning 0 instead of 1, I assume because the overmax value evalues as zero.

3. OK. If replace $modinv with $powmod(2,65537,%gpfcrash) it switches to zeroes around 2^55 which is fine, since accuracy in doubles mode can't be expected above modulus=sqrt(2^53)

4. Not sure which is the better choice for results in this range, returning 0 or blank or maybe -1. If replace with $cbrt(%gpfcrash) or $log2(%gpfcrash) they return blank in that range instead of zeroes. But if replace with $lcm(911,%gpfcrash), it returns zeroes in that range, but there's also a gap of $null outputs between the numbers having 53 bits of precision and where it begins to return zero
Posted By: maroon Re: $modinv GPF in .doubles mode - 21/01/23 02:25 PM
Oops, I refer to my example command which I neglected to post.

Warning this will make the client freeze forever

//var %i 11 | while (%i isnum 1-1030) { var %m.bf $calc(2^%i -3) , %gpfcrash %m.bf | echo -ag > modinv(911,2^ %i -3) = $modinv(911,%gpfcrash) | inc %i }
Posted By: maroon Re: $modinv GPF in .doubles mode - 21/01/23 08:37 PM
Found the same kind of GPF in $powmod, where 308 is fine, but freezes if changing it to 309 in doubles mode. Again, not critical for a real script since it's far outside the doubles accuracy range, except for defending against DoS.

//var %i 11 | while (%i isnum 1-308) { echo -a %i $left($powmod(2,$str(8,%i),$str(9,%i)),10) | inc %i }
Posted By: Khaled Re: $modinv GPF in .doubles mode - 23/01/23 07:12 AM
Thanks this issue has been fixed for the next version.
Posted By: maroon Re: $modinv GPF in .doubles mode - 23/01/23 08:12 PM
$modinv fixed, but not $powmod, frozen when changing 308 to 309
Posted By: Khaled Re: $modinv GPF in .doubles mode - 24/01/23 02:17 PM
Right. It looks like the Visual C++ compiler is wrongly optimizing away a variable check in the release version. So far, I have not been able to get it to work correctly when optimization is enabled. I will either have to disable optimization for this function or tweak the code to see if I can find a solution. I will also need to re-evaluate the fix in $modinv, since it uses the exact same check there. This change should be in the next beta.
© mIRC Discussion Forums