mIRC Home    About    Download    Register    News    Help

Print Thread
Edge cases with $bytes #269577 07/11/21 06:19 AM
Joined: Jan 2004
Posts: 1,640
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 1,640
From taking a look at $bytes, there's a little bit of a bug, and there's a little more that's unclear because the /help doesn't explain the design in much depth.

As I understand it, $bytes(num).suf increases the suffix level while trying to prevent there from being more than 3 numbers to the left of the decimal, while also rounding any fraction to have no more than 2 digit, which don't count against the limit of 3 numbers unless the '3' switch is used, causing it to sometimes chop the fraction even shorter to limit the combined digits to 3.

1a. Is it considered breaking backwards compatibility to have the default display switching to Petabytes rather than having the quantity of terabytes go into the thousands or millions? i.e. numbers at the doubles-max are displaying in the thousands of terabytes.

//echo -a $bytes( $calc(2^53-1) ).suf

1b. I realize this next number is above the 2^53 doubles limit, but the error goes beyond chopping the number down so that it has no more than 53 bits of significance. This next number is below 2^53, and seems to display fine, other than being rounded to the wrong whole number. However, at larger scales the result is wildly inaccurate. If you alter this number by appending anywhere from 0-12 zeroes, the output remains the same at 1,122TB. It's only until the 13th zero is added when the quantity of terabytes jumps into the quadrillions. $bytes has no trouble with most numbers in this range, especially those near a 2^N location.

//var %a 1234567890123456 | echo -a bytes: $bytes(%a,3).suf

2a. With the intent being to limit the '3' display to no more than 3 digits, the design appears to jump to a higher suffix in order to prevent that. There are a few cases where it missed for a small range of numbers. The 1st 2 numbers are where it switches from 999 to 1,000 and the 3rd number is where it switches to 0.98

//echo -a $bytes( $calc(999*1024+1018) ,3).suf vs $bytes( $calc(999*1024+1019) ,3).suf vs $bytes( $calc(999*1024+1024) ,3).suf

result: 999KB vs 1,000KB vs 0.98MB

//echo -a $bytes( $calc(999*1024^2+1024*1018+901) ,3).suf vs $bytes( $calc(999*1024^2+1024*1018+902) ,3).suf vs $bytes( $calc(999*1024^2+1023*1024+1024) ,3).suf

result: 999MB vs 1,000MB vs 0.98GB

2b. Related to this rounding issue, could you clarify the design intent for how the display is shortened? The borderline between where numbers are rounded up/down doesn't look like it's an intentional behavior, where numbers to the left/right are rounded in different ways. This next number displays as '500' even though it's within 6 bytes of 501kb. Instead of rounding, it looks more like an 'almost int'.

//echo -a $bytes($calc(500*1024+1018),3).suf -> 500KB

Last edited by maroon; 07/11/21 07:56 AM.
Re: Edge cases with $bytes [Re: maroon] #269607 15/11/21 01:01 PM
Joined: Dec 2002
Posts: 5,020
Khaled Offline
Hoopy frood
Hoopy frood
Joined: Dec 2002
Posts: 5,020
1a. Possibly :-)

1b. If you are using numbers that could result in calculations exceeding the number range, anything can and will happen.

2a. This is all about rounding/rounding errors.

2b. Again, this is about rounding/rounding errors.

This could also be due to whether kilobytes are 1000 or 1024 bytes, depending on context. It's quite likely that in code developed over 25+ years, both 1000 and 1024 are being used in different places, based on what users requested/what I thought made sense at the time.

It could also be due to the number of significant figures being used, eg. 1.990001 to two significant figures would round to 2.0.

And so on, and so on.

It would have been helpful if you had included:

/alias or $identifier is displaying: X
I believe it should be displaying: Y

But, really, the purpose of $bytes() was to return a reasonably useful result for displaying an approximate value in different formats, which it does. I will make some changes to the rounding significant figures in the next beta though.