feat: format metadata floats with significant digits

[emigun]

Description

Add possibility to round floats with significant digits If enabled, values in both the metadata-view and tree-view are rounded.

Motivation

Currently, all decimals for a float is shown which doesn't look good and is likely not helpful to anybody.

Changes:

If enabled, it is possibly to configure number of significant digits and two cutoff values for rounding float values. If minCutoff < floatValue < maxCutoff, decimal format (i.e 0.123) would be used. If the floatValue is outside of this range, scientific notation is used (i.e. 1.23e+6)

Default values if not provided is: significantDigits: 3 minCutoff: 0.001 maxCutoff: 10000

Tests included

• [x] Included for each change/fix?
• [x] Passing? (Merge will not be approved unless this is checked)

Documentation

• [ ] swagger documentation updated [required]
• [ ] official documentation updated [nice-to-have]

official documentation info

If you have updated the official documentation, please provide PR # and URL of the pages where the updates are included

Backend version

• [ ] Does it require a specific version of the backend
• which version of the backend is required:

Summary by Sourcery

Enable configurable significant-digit formatting for float metadata values in both metadata and tree views, switching between decimal and scientific notation based on cutoff thresholds.

New Features:

• Add MetadataValueService to format float values with configurable significant digits and cutoff bounds
• Introduce metadataFloatFormat and metadataFloatFormatEnabled options in AppConfigService for controlling float formatting

Enhancements:

• Integrate the float formatting service into MetadataViewComponent and TreeViewComponent

Build:

• Provide default float formatting settings (significantDigits, minCutoff, maxCutoff) in AppConfigService initialization

Tests:

• Update component specs and add tests to verify rounding and formatting behavior when float formatting is enabled

[cchndl]

Hi,

first of all, the result looks a lot better than without this change!

• How do you deal with number in the range [minCutoff, maxCutoff]? They are still displayed with all their digits, even though they may not be as accurate.
• support for small numbers like 1e-5 would also be nice, what do you think?

I sadly missed the discussion in the last zoom meeting, but would it make sense to allow to track this on quantities as a next step and fall back to this general behaviour when the quantity lacks the accuracy? (see: https://github.com/SciCatProject/scicat-backend-next/issues/1971) Then one would not have to provide an instance-wide cutoff.

Best cchndl

[emigun]

Hi,

first of all, the result looks a lot better than without this change!

• How do you deal with number in the range [minCutoff, maxCutoff]? They are still displayed with all their digits, even though they may not be as accurate.
• support for small numbers like 1e-5 would also be nice, what do you think?

I sadly missed the discussion in the last zoom meeting, but would it make sense to allow to track this on quantities as a next step and fall back to this general behaviour when the quantity lacks the accuracy? (see: SciCatProject/scicat-backend-next#1971) Then one would not have to provide an instance-wide cutoff.

Best cchndl

Hi,

Thanks for taking a look!

• Both numbers outside and inside the range are rounded with significant digits. Outside the range will be scientific notation like 1.23e-4 and inside it would be decimal numbers like 0.000123 (with three significant digits). Take a look at metadata-value.service.spec.ts for more examples.
• I'm not exactly sure what you mean. If the number is smaller (absolute value) than the minCutoff it will be presented with scientific notation.

How did you configure it? If you only set metadataFloatFormatEnabled to true it will use default values for significant digits, minCutoff and maxCutoff.

I agree with your proposal on a "precision" field next to value and unit.

[cchndl]

• Both numbers outside and inside the range are rounded with significant digits. Outside the range will be scientific notation like 1.23e-4 and inside it would be decimal numbers like 0.000123 (with three significant digits). Take a look at metadata-value.service.spec.ts for more examples.
• I'm not exactly sure what you mean. If the number is smaller (absolute value) than the minCutoff it will be presented with scientific notation.

Yeah sorry. When I wanted to try it out with a backend that was not local I ran into the thing again where the backend overrides the frontend config. Hasn't bitten me in a while and I forgot. So I thought there was a problem and I wanted to check with you. Sorry for the confusion on my part. Looks good!

[Junjiequan]

It seems that FormatNumberPipe is already doing numbers transformation, can't we just extend configuration logic within the formatNumberPipe instead of creating a new metadata-value service?

Some benfits i see doing so is that:

1. Avoid having a new service
2. Keep consistency - FormatNumber pipe is already used for formatting
3. Easy to use pipes with just {{ value | formatNumber }}

[emigun]

It seems that FormatNumberPipe is already doing numbers transformation, can't we just extend configuration logic within the formatNumberPipe instead of creating a new metadata-value service?

Some benfits i see doing so is that:

1. Avoid having a new service
2. Keep consistency - FormatNumber pipe is already used for formatting
3. Easy to use pipes with just {{ value | formatNumber }}

Interesting! It sounds like a good idea, I wasn't aware of the FormatNumberPipe.

Looks like FormatNumberPipe is being used in TreeBaseComponent and MetadataInputComponent. I don't know what the latter is, but for TreeBaseComponent it seems to be used when there is a unit? Does that work? Either way, seems reasonable to format also without unit.

Do we want to keep the old behaviour exactly as is when it is not configured?

[Junjiequan]

Do we want to keep the old behaviour exactly as is when it is not configured?

At ess, we don't use the tree-view, so it does not affect us. But I think we should keep the old behaviour as fallback when configuration is not given

[nitrosx]

We will go ahead and merge it, as the changes requested by @Junjiequan have been addressed and he is currently on holiday.