mIRC Home    About    Download    Register    News    Help

Print Thread
#270754 17/09/22 09:19 AM
Joined: Dec 2002
Posts: 341
D
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
D
Joined: Dec 2002
Posts: 341
I assume Wolfram Alpha is correct, but that's an assumption I'm making.

F is 15, also known as 2^4 -1.
FF is 255, also known as 2^8 -1.
These can be checked using calc in Windows and going from dec to hex.
So, sixteen F, or FFFFFFFFFFFFFFFF, should be 2^64 -1.

https://www.wolframalpha.com/input?i=convert+2%5E64+-1+to+base+36
They give 3w5e11264sgsf

mIRC 7.69
//echo $base(FFFFFFFFFFFFFFFF,16,36)
3W5E11264SG0G

mIRC 6.03
//echo $base(FFFFFFFFFFFFFFFF,16,36)
3W5E11264SGSF

So, did newer versions of mIRC start miscalculating using $base or is Wolfram Alpha incorrect? Or possibly both incorrect?

Did a search and came across https://books.google.com/books?id=qDszEAAAQBAJ&pg=PT237&lpg=PT237&dq="3W5E11264SGSF"
Maybe they made a mistake there, but, maybe someone else here can verify what base 16 FFFFFFFFFFFFFFFF should be in base 36. I suspect newer versions of mIRC have a math bug in $base.

Edited...

More things I found out playing around.

//inc %n 1 | tokenize 32 $calc(20000000000000 + %n) | echo -s $base($1-,16,36)

In 7.69
Done seven times
2GOSA7PA2GW
2GOSA7PA2GY
2GOSA7PA2H0
2GOSA7PA2H0
2GOSA7PA2H0
2GOSA7PA2H2
2GOSA7PA2H4

In 6.03
2GOSA7PA2GX
2GOSA7PA2GY
2GOSA7PA2GZ
2GOSA7PA2H0
2GOSA7PA2H1
2GOSA7PA2H2
2GOSA7PA2H3

In 7.69
//echo -s $base(2GOSA7PA2H0,36,16)
//echo -s $base(2GOSA7PA2H1,36,16)
Same result of 20000000000004

In 6.03
//echo -s $base(2GOSA7PA2H0,36,16)
20000000000004
//echo -s $base(2GOSA7PA2H1,36,16)
20000000000005

Wolfram Alpha
https://www.wolframalpha.com/input?i=convert+2GOSA7PA2H1_36+to+base+16
20000000000005_16

So, Wolfram Alpha takes 2GOSA7PA2H1 in base 36 and converts it to 20000000000005 in base 16.

Last edited by Doomstars; 17/09/22 10:35 AM.
Joined: Mar 2008
Posts: 91
B
Babel fish
Offline
Babel fish
B
Joined: Mar 2008
Posts: 91
3W5E11264SGSF should be the correct value.
C# code on SharpLab.IO

Joined: Dec 2002
Posts: 5,169
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,169
Thanks for your bug report. This is related to rounding/precision/etc. The result you are seeing in the latest version of mIRC is the expected, albeit wrong, result.

mIRC is a 32bit application. For it's $calc()/$base()/scripting calculations it can handle a maximum of a double value. IEEE 64-bit double precision provides exactly 53 bits of mantissa. The remaining bits are for the sign and exponent. So a 64bit value cannot fit in a double value.

However, the fact that a twenty year old version of mIRC, v6.03, returned the correct result, is intruiging. If I use the exact same code from v6.03 in v7.69, I still see the same incorrect result in v7.69. Which is what mIRC should be returning: the correct incorrect result ;-)

mIRC v6.1 returns the same result as v7.69. So I assume that it was the switch from an older Visual C++ compiler, used for v6.03, to the newer Visual C++ .Net used for v6.1 that resulted in this change. My guess is that Microsoft fixed an issue in their floating point library to make it comply with IEEE double precision.

Update: And there you go: https://stackoverflow.com/questions/7120710/why-did-microsoft-abandon-long-double-data-type

Joined: Dec 2002
Posts: 341
D
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
D
Joined: Dec 2002
Posts: 341
It'd be slower, but what about creating a new $base called $basepc for base precision in which it'd do it in a long-hand method while keeping the current $base that is used in 6.1 and higher (for speed purposes)?

Joined: Dec 2002
Posts: 5,169
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,169
Quote
It'd be slower, but what about creating a new $base called $basepc for base precision in which it'd do it in a long-hand method while keeping the current $base that is used in 6.1 and higher (for speed purposes)?
This topic has indeed been discussed many times before, ie. adding support for arbitrary precision arithmetic, such as BigNum. There is no practical way to add support for this since the result would not be usable anywhere else in mIRC, as no other feature would be able to parse that value, use it in a calculation, etc. Every scripting command/identifier would eventually need to have its own $XXXpc() extended version to handle BigNum values, and because the scripting language is so closely tied to whole of mIRC, including the GUI, every scripting feature would need to perform conversions from BigNum to non-BigNum values in order for the values to be consistently usable everywhere else, with the resulting decrease in performance due to BigNum handling.


Link Copied to Clipboard