mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Jan 2004
Posts: 2,002
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,002
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

Joined: Jan 2004
Posts: 2,002
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,002
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 }

Joined: Jan 2004
Posts: 2,002
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,002
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 }

Joined: Dec 2002
Posts: 5,246
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,246
Thanks this issue has been fixed for the next version.

Joined: Jan 2004
Posts: 2,002
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,002
$modinv fixed, but not $powmod, frozen when changing 308 to 309

Joined: Dec 2002
Posts: 5,246
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,246
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.


Link Copied to Clipboard