mIRC Home    About    Download    Register    News    Help

Print Thread
#258652 07/08/16 02:22 PM
Joined: Jan 2016
Posts: 19
Pikka bird
OP Offline
Pikka bird
Joined: Jan 2016
Posts: 19
Using mIRC version 7.46

When using

Code:
//echo -a $bytes(4182218.0099,db)



It returns:

Quote:
4,182,218.0098999999


Instead of:

Quote:
4,182,218.0099


This would be wrong since all $bytes(N,d) should do is retain the decimal point values instead of adding to/changing it.

(Number value for example purposes)

Thank you.

Last edited by Stewie1k94; 07/08/16 02:23 PM.
Stewie1k94 #259035 29/09/16 09:54 AM
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Thanks for your bug report. This is due to mIRC v7.46 adding support for more decimal digit precision in calculations. There was a discussion on this here (as well as others in the past).

In this case, the internal floating point representation of "4182218.0099" is "4,182,218.0098999999" for 12 decimal digit precision. The full internal representation is actually much longer (type it into here). This is typical of floating point values.

During calculations, it is not possible to know in advance how much precision a scripter wants, which is why $round() is provided.

However, in specific cases, like $bytes(), mIRC could assume that you want as much precision as the textual representation of the number you provide. So for "4182218.0099" this would be four decimal digits "0099". But this would have to be built-in to each and every identifier that uses numbers, on a case by case basis.

The fact that these results are not apparent in older versions of mIRC, that use 6 decimal digits, is just luck because rounding avoids them.

The only solution would be to change the limit back to 6 decimal digits, which I think would be for the best. However, this would mean that more precision would not be possible - even adding a $calc(,N) would not help, because the N value would need to be propagated to all routines that use that number from that point onwards, which would be very difficult.

This will be changed back to 6 digits in the next version.

Khaled #259037 29/09/16 12:34 PM
Joined: Apr 2004
Posts: 871
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
Originally Posted By: Khaled
The only solution would be to change the limit back to 6 decimal digits, which I think would be for the best.

STRONGLY disagree. And I really hope you're not basing this conclusion on someone trying to abuse $bytes.

Quote:
This will be changed back to 6 digits in the next version.

Please don't.


Saturn, QuakeNet staff
Sat #259038 29/09/16 12:37 PM
Joined: Jan 2016
Posts: 19
Pikka bird
OP Offline
Pikka bird
Joined: Jan 2016
Posts: 19
Originally Posted By: Sat
Originally Posted By: Khaled
The only solution would be to change the limit back to 6 decimal digits, which I think would be for the best.

STRONGLY disagree. And I really hope you're not basing this conclusion on someone trying to abuse $bytes.

Quote:
This will be changed back to 6 digits in the next version.

Please don't.


This is not the way I would hope for it to go.. I would prefer if there was another workaround..

But, are you suggesting I am abusing $bytes(), and if so, how?

Stewie1k94 #259039 29/09/16 12:45 PM
Joined: Apr 2004
Posts: 871
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
4182218.0099 is not a valid number of bytes. There are millions of ways to do formatting of number strings, but if you're passing a non-integer value to $bytes, the nature of $bytes imposes that it will parse the value as a number, and that may have side effects - with a decimal limit of 6 just as well. From your post it is clear that you want to have your input be treated as a literal string, so use another method for formatting instead.

Edit: case in point, try this on an older mIRC version:

Code:
$bytes(1000000000000000.09,db)

The result: 1,000,000,000,000,000.1

Last edited by Sat; 29/09/16 12:50 PM.

Saturn, QuakeNet staff
Stewie1k94 #259040 29/09/16 12:48 PM
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
You are using $bytes() correctly. The issue is with how floats are stored internally in IEEE format and that mIRC extended the number of digits in v7.46.

Sat #259041 29/09/16 12:59 PM
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Quote:
STRONGLY disagree. And I really hope you're not basing this conclusion on someone trying to abuse $bytes.

This applies to all identifiers not just $bytes().

Note that every time that this change has been made (and it has been made quite a few times over the years), issues like this one re-appear.

If you remember, I extended the precision to 16 digits in the 7.46 beta and the issue re-appeared, so I decreased it to 12 digits. While the issue is less likely to appear with 12 digits than 16 digits, it is still there and difficult to resolve. I would have left it at 16 digits if that was not the case.

Khaled #259042 29/09/16 01:07 PM
Joined: Apr 2004
Posts: 871
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
Originally Posted By: Khaled
[..] issues like this one re-appear.

These are not issues with mIRC. These are wrong expectations of people using mIRC. The actual "issues" have been there all along (see above), just perhaps less obviously, as they are inherent to usage of floating point numbers. Again, I strongly disagree with the notion of constraining the abilities of the entire language just to avoid going against some people's wrong expectations for (only) some cases, especially when there are trivial ways for them to deal with such cases (there is $round after all).


Saturn, QuakeNet staff
Khaled #259043 29/09/16 01:14 PM
Joined: Jul 2006
Posts: 4,144
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,144
In others identifiers (maybe with some exceptions just like $bytes here), people are ok with their input being seen as a number and not a string, it's a fact that scripts use $bytes(,b) to format strings of numbers.
You said that @OP used $bytes correctly, that's contradictory to how $bytes treats the input.
I agree with Sat, reverting the change isn't going to fix anything, either it is wrong expectation from people as Sat is saying, or $bytes is just not working correctly..
I think giving $bytes an option to treat the input as a string when $bytes(,b) is used would solve the issue, giving people a way to get what they really want, alternatively, a new $format identifier or something could be added.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Khaled #259044 29/09/16 01:15 PM
Joined: Apr 2004
Posts: 871
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
Of course it may be possible to compromise, though. How difficult would it be to set the precision globally at run time with a command? So that, if say I want to do some intensive math, I can do "/setprecision high" before starting and "/setprecision default" afterward etc?


Saturn, QuakeNet staff
Sat #259045 29/09/16 01:23 PM
Joined: Jan 2016
Posts: 19
Pikka bird
OP Offline
Pikka bird
Joined: Jan 2016
Posts: 19
Originally Posted By: Sat
Originally Posted By: Khaled
[..] issues like this one re-appear.

These are not issues with mIRC. These are wrong expectations of people using mIRC. The actual "issues" have been there all along (see above), just perhaps less obviously, as they are inherent to usage of floating point numbers. Again, I strongly disagree with the notion of constraining the abilities of the entire language just to avoid going against some people's wrong expectations for (only) some cases, especially when there are trivial ways for them to deal with such cases (there is $round after all).


My expectation of using $bytes(N,db) was for how it has always displayed for me (before 7.46), I apologize if I am incorrect, of course.

I don't want to see a feature removed because of this, either. This was not my intention. In fact, I wasn't even actually expecting a reply to be honest (given how long it's been since I posted)

I did find a way around my original issue, any way via $gettok(,1,46) / $gettok(,2,46) not much of a big deal when I can just work around it.

This report was only because the output had changed and I just wanted clarification, really.

I wasn't really expecting any of this to turn into an argument, again, I apologize.

Stewie1k94 #259046 29/09/16 01:26 PM
Joined: Apr 2004
Posts: 871
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
Originally Posted By: Stewie1k94
I wasn't really expecting any of this to turn into an argument, again, I apologize.

No worries, and I am sorry for getting you caught in the crossfire of a discussion that would have come up one way or another anyway..


Saturn, QuakeNet staff
Stewie1k94 #259066 01/10/16 10:18 AM
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Quote:
My expectation of using $bytes(N,db) was for how it has always displayed for me (before 7.46), I apologize if I am incorrect, of course.

You were quite right to report this as a bug.

In the previous discussion on this topic, I offered to extend the number of digits to 14 but said we would need to keep an eye out for any side-effects because the change had caused issues in the past.

Unfortunately, soon after, someone reported an issue with $calc() here. So I decreased the digits to 12 in the hope this would mitigate any side-effects. Clearly they are still present, so for the sake of backwards compatibility and consistency, this change needs to be reverted.

Sat #259067 01/10/16 10:27 AM
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Quote:
How difficult would it be to set the precision globally at run time with a command?

This should be possible but as a global variable it would affect all running scripts. For exmple, if you use /setprecision and then display a dialog using $input(), any other scripts that run in the interim, either on timers or as remote events, would be affected until /setprecision is reset to default.

Khaled #259070 01/10/16 01:09 PM
Joined: Apr 2004
Posts: 871
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
Well, sure. Badly written scripts can ruin things for other scripts, eg I'm still not sure why /unsetall is a thing. But I don't think that's something to worry about here.

I should actually extend my last example though, because one might make a full script (a la nnscript, first example that comes to mind) that is "ready" for high precision and may just do "/setprecision high" at startup and leave it there, in which case other addons would have to do something like:

Code:
var %oldprecision = $precision
setprecision high

...math intensive code block...

setprecision %oldprecision

As such, a stack system would be more convenient for scripts (/setprecision high | ... | /setprecision -r).


Saturn, QuakeNet staff

Link Copied to Clipboard