Register Log In

Forums Bug Reports Different $base($calc()) results in 7.x versions.

Print Thread

Different $base($calc()) results in 7.x versions. #272065 21/09/23 03:59 PM
Joined: Feb 2011 Posts: 443 K KindOne OP Pan-dimensional mouse
OP KindOne Pan-dimensional mouse K Joined: Feb 2011 Posts: 443	Discovered this issue while testing previous bug reports on the Visual Studio 2017 beta. Code ; Source of code: ; https://forums.mirc.com/ubbthreads.php/topics/258149 //echo -ag $calc(16/6) --- $base($calc(16/6),10,10) Results from my testing: Code ; 7.02 - 7.45 ; 2.666667 --- 2.666666999999999 Code ; 7.46 ; 2.666666666667 --- 2.666666666667 Code ; 7.47 - 7.72 ; 2.666667 --- 2.666667 Code ; 7.73 - 7.75.345 ; 2.666667 --- 2.666666

Re: Different $base($calc()) results in 7.x versions. KindOne #272067 21/09/23 05:47 PM
Joined: Dec 2002 Posts: 5,365 London, UK Khaled Hoopy frood
Khaled Hoopy frood Joined: Dec 2002 Posts: 5,365 London, UK	That looks fine. Please remember to compare any results in the beta to the v7.75 release version. Update: Hmm. I think I misunderstood your post. You are specifically comparing the release version of 7.75 to that of 7.72? To clarify, this issue has been discussed before - it is due to rounding because of the limited number of decimal places in floating point calculations. It may also be present in bigfloat with large enough values. This particular issue was introduced due to a change that fixed other rounding issues in $base(). These issues are mutually exclusive. I cannot fix one without re-introducing the other. Both issues are due to rounding - in one case, due to too many decimal places, in the other, due to too few. As far as I can tell, there is no solution that resolves both.

Re: Different $base($calc()) results in 7.x versions. Khaled #272070 21/09/23 07:30 PM
Joined: Feb 2011 Posts: 443 K KindOne OP Pan-dimensional mouse
OP KindOne Pan-dimensional mouse K Joined: Feb 2011 Posts: 443	Quote You are specifically comparing the release version of 7.75 to that of 7.72? Yes. Sorry for the confusion. I forgot to include the part about the change between 7.72 and 7.75. Quote ... this issue has been discussed before .. Understood.

Re: Different $base($calc()) results in 7.x versions. Khaled #272071 21/09/23 08:29 PM
Joined: Jul 2006 Posts: 4,105 France W Wims Hoopy frood
Wims Hoopy frood W Joined: Jul 2006 Posts: 4,105 France	Would it be possible to make $base use the original input number when inbase and outbase are the same, instead of performing calculation, or is that a bad idea? #mircscripting @ irc.swiftirc.net == the best mIRC help channel

Re: Different $base($calc()) results in 7.x versions. Khaled #272081 26/09/23 10:51 PM
Joined: Jul 2006 Posts: 4,105 France W Wims Hoopy frood
Wims Hoopy frood W Joined: Jul 2006 Posts: 4,105 France	I saw the fix in the beta, not sure if that were an attempt at fixing one of the two mutually exclusive fix you mentioned but I wrote this script: Code alias testbase { var %r1 $r(1,1000000000),%r2 $r(1,1000000000) var %calc $calc(%r1 / %r2) if ($base(%calc,10,10) != %calc) echo -sg %r1 %r2 $v1 $v2 } ran on a timer -m 1 10, which unfortunately quickly echoed 267169000 622827430 0.42962 0.428962 But it seems then that it is a misconception from scripters to expect the same result with decimals in $base with same inbase/outbase. My suggestion about using the number as is with same inbase/outbase would bypass the rounding issue. #mircscripting @ irc.swiftirc.net == the best mIRC help channel

Re: Different $base($calc()) results in 7.x versions. Wims #272083 27/09/23 06:30 AM
Joined: Dec 2002 Posts: 5,365 London, UK Khaled Hoopy frood
Khaled Hoopy frood Joined: Dec 2002 Posts: 5,365 London, UK	Quote But it seems then that it is a misconception from scripters to expect the same result with decimals in $base with same inbase/outbase. That is why anyone who works with floating point needs to read this. Quote My suggestion about using the number as is with same inbase/outbase would bypass the rounding issue. No, this is, as you said, a bad idea. We would then have to start adding exceptions in every feature/identifier that doesn't quite give the results we want because of how math/floating point works. In this case, this issue is due to needing more precision/decimal places to make $base() give the correct results in calculations, however this extra precision means that the original input cannot be represented exactly as a float. I have reverted the change to $base() for the next beta.

Link Copied to Clipboard