Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Vocalpoint]

Morning,

Just completed my upgrade to v17 and noticed that calculated replay gain values that should have a zero on the end are now being truncated by a digit.



Would it be possible to get this to show (as in previous versions) as -8.50 ? I am so used to seeing all my replay gain data to two decimal places...

VP

[MrC]

I was going to suggest a temporary workaround:

  FormatNumber([Gain R,0], 2)

But this is producing incorrect results also.  Sometimes it outputs 2 decimal places, and other times just 1.

So perhaps the issue your seeing is a bug with formatting the number of decimal places in general.

[Vocalpoint]

I was going to suggest a temporary workaround:

  FormatNumber([Gain R,0], 2)

But this is producing incorrect results also.  Sometimes it outputs 2 decimal places, and other times just 1.

So perhaps the issue your seeing is a bug with formatting the number of decimal places in general.

Something is definitely "off" here. Cannot understand why this - of all things -  would get changed. Hoping that dev can take a look for us.

VP

[Matt]

Internally Replay Gain is stored with high precision.

At display time, we use two decimals.

Trailing zeros are not shown, since they're superfluous.

In other words, 8.5 and 8.50 are the same number.

[Vocalpoint]

In other words, 8.5 and 8.50 are the same number.

Understood...however...

Trailing zeros are not shown, since they're superfluous.

Suddenly superfluous in v17 but not in any version prior? Why not just leave it as it was? It is not doing any harm whatsoever.

[MrC]

I'll suggest then that FormatNumber() is broken.  When you ask for 2 decimal places, you should get 2 decimal places.  Otherwise, it is not possible to column align trailing text such as:

  FormatNumber([some field], 2) blah blah blah

[rick.ca]

Trailing zeros are not shown, since they're superfluous.

Not in the context of a file list. They're necessary for readability. All numeric data should be shown with the appropriate number of significant digits, padded with zeros and right aligned—preferably with decimals in alignment.

If the number is not one in a list, a trailing zero is not required for readability, but may be necessary to convey the number of significant digits. '8.5' could mean anything between 8.46 and 8.54. '8.50' means 8.50.

[Vocalpoint]

Not in the context of a file list. They're necessary for readability. All numeric data should be shown with the appropriate number of significant digits, padded with zeros and right aligned—preferably with decimals in alignment.

If the number is not one in a list, a trailing zero is not required for readability, but may be necessary to convey the number of significant digits. '8.5' could mean anything between 8.46 and 8.54. '8.50' means 8.50.

+100. Please consider returning the trailing zero for readability purposes. Thank you.

Cheers,

VP

[Matt]

Not in the context of a file list. They're necessary for readability. All numeric data should be shown with the appropriate number of significant digits, padded with zeros and right aligned—preferably with decimals in alignment.

If the number is not one in a list, a trailing zero is not required for readability, but may be necessary to convey the number of significant digits. '8.5' could mean anything between 8.46 and 8.54. '8.50' means 8.50.

I don't have a strong feeling on this.  Turning on trailing zeroes, which we suppress by default when formatting decimals, will likely lead to other bug reports where we show things like "13.000" in places where users don't expect it.

As for digits of significance, neither "8.5" or "8.50" are representing the number of significant digits.  Replay Gain is stored with several more digits than displayed.  However, it's hardly worth showing "8.4997632" just because that's what we have stored.

[Vocalpoint]

I don't have a strong feeling on this.  

Well - I do.

Turning on trailing zeroes, which we suppress by default when formatting decimals, will likely lead to other bug reports where we show things like "13.000" in places where users don't expect it.

This "suppress by default" is something new and is not the way it was in 16.0.181.

I cannot understand what harm or "bug reports" could possible come from displaying 8.5 as 8.50 just so it looks "in line" with all the other values to two decimal places.

I am not asking for 14 decimal places nor do I want it to suddenly cause "bug reports". Please consider reinstating the standard "two" decimal places as it has been for as long as I have used MC.

Cheers,

VP

[Matt]

Currently the database has a data type decimal.

Formatting these values for display uses up to 2 decimal places, but trims trailing zeroes.  That way integers aren't shown like 24.00.

It's easy to switch to keeping trailing zeroes, but this will change other fields as well.

Is it good for a list of frame rates to look like:
24.00
25.00
etc.

Or is there something special about Replay Gain, so the database needs a new data type for just it?

[Vocalpoint]

Is it good for a list of frame rates to look like:
24.00
25.00
etc.

Or is there something special about Replay Gain, so the database needs a new data type for just it?

Someone please correct me but I believe it's industry standard to show frame rates to at least two decimal points (aka 23.976 FPS for NTSC etc) so shaving superfluous zeros off of those makes no sense to me.

Regarding Replay gain...I believe it's generally standard to display that to two decimals as well.

Bottom line - this was displayed just fine for years and suddenly now you decide to shave a zero? Why? Is there some huge gain being made by doing that? If so - I am cool with it...but doing it for no reason just makes these values jarring to look at onscreen.

VP

[rick.ca]

As for digits of significance, neither "8.5" or "8.50" are representing the number of significant digits.  Replay Gain is stored with several more digits than displayed.  However, it's hardly worth showing "8.4997632" just because that's what we have stored.

I was only refuting your contention the trailing '0' is superfluous. I do understand the meaning of "significant digits" and was not trying to suggest you should be displaying all of them. When reporting a number, one decides how many significant digits to include. I don't believe it's improper to refer to those as a "number of significant digits."

What you've gone on to describe is a limitation in your display system. I don't know why an integer wouldn't be displayed as an integer and a decimal as a decimal. I'm just pointing out that if you display a decimal with two digits of significance (hopefully rounded correctly), trailing zeroes should not be dropped. And in a column, the numbers should be right-aligned.

[vagskal]

And in a column, the numbers should be right-aligned.

+1

[Vocalpoint]

What you've gone on to describe is a limitation in your display system. I don't know why an integer wouldn't be displayed as an integer and a decimal as a decimal. I'm just pointing out that if you display a decimal with two digits of significance (hopefully rounded correctly), trailing zeroes should not be dropped. And in a column, the numbers should be right-aligned.

+2