Feature request: significant figures

[ouuan]

This was requested in #117, which was closed by #127 that provides padding instead of significant figures.

Significant figures are useful. Let's say you want to see 1.34GB instead of 1GB but don't want to see 724.16MB instead of 724MB.

For instance, GitHub Releases is using significant figures:

I open this issue because #117 is closed. A new issue is good for tracking its status and making potential contributors aware of it.

#117 (comment)

I know we need a PR or there won't be this feature, so I'm not requesting the maintainer to provide this feature :)

[avoidwork]

To clarify, you're asking to drop the trailing zeros that'd come from Number.toFixed()?

My understanding of a significant figure is based on resolution, which is done with Number.toPrecision() which is called from Number.toFixed().

Zeros to the right of the last non-zero digit (trailing zeros) in a number with the decimal point are significant if they are within the measurement or reporting resolution.

from https://en.wikipedia.org/wiki/Significant_figures

So, could you explain what you're after exactly? toFixed() should meet this definition.

[ouuan]

I want Number.toPrecision(), possibly having trailing zeros removed if the option padding is false.

[avoidwork]

So you have that today, minus dropping trailing zeros because they are significant.

[avoidwork]

I'm not sure how I could attempt to run toPrecision() on the calculated result, because the user wouldn't know how big the number will be as an output.

I think you'd do this by exporting the 'object' option and running another function against the Number. The GH example is a precision of 3, and relies on the unit changing to keep the formatting user friendly.

[ouuan]

I think it's easy to have significant figures itself, but there are many other options and I'm not sure how to deal with the relationship between significant figures and other options.

[avoidwork]

I think you're misusing that phrase. You have significant figures by definition right now with 'round' option; I think you're asking for something else entirely with a specific precision on the result, which would be a tail op before the returns.

[ouuan]

I think you're misusing that phrase. You have significant figures by definition right now with 'round' option; I think you're asking for something else entirely with a specific precision on the result, which would be a tail op before the returns.

See https://en.wikipedia.org/wiki/Significant_figures#Rounding_to_significant_figures

The round option is "Rounded to decimal places", not "Rounded to significant figures".

[avoidwork]

Zeros to the right of the last non-zero digit (trailing zeros) in a number with the decimal point are significant if they are within the measurement or reporting resolution.

This is on the same page. What I'm trying to point out is you need to both specify the round variable, and then your ask/want is to run precision on the result. There's an edge case when you have numbers that would use an exponent larger than 8.

[avoidwork]

Trailing zeros in an integer may or may not be significant, depending on the measurement or reporting resolution.
45,600 has 3, 4 or 5 significant figures depending on how the last zeros are used. For example, if the length of a road is reported as 45600 m without information about the reporting or measurement resolution, then it is not clear if the road length is precisely measured as 45600 m or if it is a rough estimate. If it is the rough estimation, then only the first three non-zero digits are significant since the trailing zeros are neither reliable nor necessary; 45600 m can be expressed as 45.6 km or as 4.56 × 104 m in scientific notation, and both expressions do not require the trailing zeros.

This is also something I want to point out; there is literally no way for the function to know what's significant, so this is a configuration variable. I fail to see how your use case can't be handled right now by using a different output or simply composing filesize with another function that does whatever you want.

[ouuan]

 I fail to see how your use case can't be handled right now by using a different output or simply composing filesize with another function that does whatever you want.

Then you can simply use a piece of code to tell me how.

[ouuan]

OK, I just realized that it's not hard. Just run function on the number part of the output. However, this library itself is not hard to implement if there are't so many options. It will be better if it's available out-of-box in this library. In fact, I think rounding to three significant figures should be the default behavior.

If the significant figures feature is hard to be added within this library, I can use the workaround to process the output on the user side.

[avoidwork]

I think it can be done in the lib, the point to execute the precision is on the result[0] before the returns: https://github.com/avoidwork/filesize.js/blob/master/src/filesize.js#L121

[avoidwork]

I implemented it such that if the exponent is > 8 & precision > 0 the precision will be adjusted such that it'll add the difference such that the output is an integer of full size... the purpose of this lib overrides the strictness of this option.

[ouuan]

Thanks for implementing this. I'm now using the precision option alone and it works fine.

[flleeppyy]

The implementatiomn doesn't seem to be working at all.

[avoidwork]

rtfm