|
|
Joined: Feb 2011
Posts: 461
Pan-dimensional mouse
|
OP
Pan-dimensional mouse
Joined: Feb 2011
Posts: 461 |
Discovered this issue while testing previous bug reports on the Visual Studio 2017 beta.
; 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:
; 7.02 - 7.45
; 2.666667 --- 2.666666999999999
; 7.46
; 2.666666666667 --- 2.666666666667
; 7.47 - 7.72
; 2.666667 --- 2.666667
; 7.73 - 7.75.345
; 2.666667 --- 2.666666
|
|
|
|
|
Joined: Dec 2002
Posts: 5,482
Hoopy frood
|
|
Hoopy frood
Joined: Dec 2002
Posts: 5,482 |
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.
|
|
|
|
|
Joined: Feb 2011
Posts: 461
Pan-dimensional mouse
|
|
OP
Pan-dimensional mouse
Joined: Feb 2011
Posts: 461 |
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. ... this issue has been discussed before .. Understood.
|
|
|
|
|
Joined: Jul 2006
Posts: 4,180
Hoopy frood
|
|
Hoopy frood
Joined: Jul 2006
Posts: 4,180 |
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
|
|
|
|
|
Joined: Jul 2006
Posts: 4,180
Hoopy frood
|
|
Hoopy frood
Joined: Jul 2006
Posts: 4,180 |
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: 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
|
|
|
|
|
Joined: Dec 2002
Posts: 5,482
Hoopy frood
|
|
Hoopy frood
Joined: Dec 2002
Posts: 5,482 |
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. 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.
|
|
|
|
|
Joined: Jul 2006
Posts: 4,180
Hoopy frood
|
|
Hoopy frood
Joined: Jul 2006
Posts: 4,180 |
on mIRC 7.76 $base(51.4,10,10) returns 51.39999A
#mircscripting @ irc.swiftirc.net == the best mIRC help channel
|
|
|
|
|
Joined: Dec 2002
Posts: 5,482
Hoopy frood
|
|
Hoopy frood
Joined: Dec 2002
Posts: 5,482 |
This is the same issue as reported above. Please see my previous explanation.
|
|
|
|
|
Joined: Jul 2006
Posts: 4,180
Hoopy frood
|
|
Hoopy frood
Joined: Jul 2006
Posts: 4,180 |
Which previous explanation exactly? this issue is due to needing more precision/decimal places to make $base() give the correct results in calculations, If you're talking about this one, these are not the same issue, this new one shows 'A', it's not a precision issue, it's just incorrectly returning a character that's not part of the string base "0123546789", effectively constituing the base10 used in $base, am I wrong?
#mircscripting @ irc.swiftirc.net == the best mIRC help channel
|
|
|
|
|
Joined: Dec 2002
Posts: 5,482
Hoopy frood
|
|
Hoopy frood
Joined: Dec 2002
Posts: 5,482 |
it's just incorrectly returning a character that's not part of the string base "0123546789" Ah, now your bug report makes sense :-) An explanation always helps. It looks like this is due to the recent change to $base(). I think I've found a solution but it will need testing. This change will be in the next beta.
|
|
|
|
|
