You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The >>, << relationship could occasionally occur if the units were specified. So, you might have 128B, but be required to display it in GiB and to round up. So the result would be < 0.01 GiB and 0.01 GiB is equal to 10737418B which is a whole lot different from 128 B. Here I think a whole lot less is appropriate, so it would make sense to use the << symbol. The reason is that the actual value is several orders of magnitude less than the represented value. But, if rounding to zero, the value is 0.00 GiB. Here 128 B is, indeed infinitely greater than the value shown, but on the scale of GiB, the difference really isn't that big, at least in terms of GiB, so a plain > seems to make sense. Probably what you want to consider is the relation of the difference between the displayed and actual value to the magnitude of the ULP. In this case, the magnitude of the ULP is exactly 10737418, and so the right decision is made.
So, an algorithm would be to calculate the value of the ULP, and find the difference between the real and the actual, and then divide that by the ULP. Maybe this value could even be a number between -1 and 1, exclusive, where 0 means the display value and the actual value are equal, Close to 1 or -1 means the difference is a >> or << as the case may be. Close to 0 means the difference is small. Whether the scale should be arithmetic or logarithmic is a hard question, though, and might be one of those configurable things.
Note that it is not clear if any of this could be easily calculated.
The text was updated successfully, but these errors were encountered:
It would actually be quite easy to calculate the difference between the actual magnitude and the shown magnitude in the getStringInfo() method using the Radix.as_rational() method. This method in turn calls NatDivision.undivision() which is not, I believe, all that algorithmically complex.
The
>>
,<<
relationship could occasionally occur if the units were specified. So, you might have 128B, but be required to display it in GiB and to round up. So the result would be< 0.01 GiB
and 0.01 GiB is equal to 10737418B which is a whole lot different from 128 B. Here I think a whole lot less is appropriate, so it would make sense to use the<<
symbol. The reason is that the actual value is several orders of magnitude less than the represented value. But, if rounding to zero, the value is0.00 GiB
. Here 128 B is, indeed infinitely greater than the value shown, but on the scale of GiB, the difference really isn't that big, at least in terms of GiB, so a plain>
seems to make sense. Probably what you want to consider is the relation of the difference between the displayed and actual value to the magnitude of the ULP. In this case, the magnitude of the ULP is exactly 10737418, and so the right decision is made.So, an algorithm would be to calculate the value of the ULP, and find the difference between the real and the actual, and then divide that by the ULP. Maybe this value could even be a number between -1 and 1, exclusive, where 0 means the display value and the actual value are equal, Close to 1 or -1 means the difference is a
>>
or<<
as the case may be. Close to 0 means the difference is small. Whether the scale should be arithmetic or logarithmic is a hard question, though, and might be one of those configurable things.Note that it is not clear if any of this could be easily calculated.
The text was updated successfully, but these errors were encountered: