Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Surprising rounding in NumericalInput #4045

Closed
damianrusak opened this issue Apr 7, 2020 · 2 comments
Closed

Surprising rounding in NumericalInput #4045

damianrusak opened this issue Apr 7, 2020 · 2 comments

Comments

@damianrusak
Copy link

damianrusak commented Apr 7, 2020

On blueprintjs/core@3.24.0 and with minorStepSize property set to 1e-20 I'm seeing an unintuitive behaviour with NumericInput:

upon blurring the input some numbers are being rounded, while some are not:

2, 20, 200 would not get “sanitized” to a different value
2000 -> 1999.9999999999998
20000 would not get sanizited
200000 -> 200000.00000000003
2000000, 20000000 would not get sanizited
but 200000000 would have same decimal part as 2000 after clamping etc…

is it perhaps something with the rounding / max step precision logic in https://github.com/palantir/blueprint/blob/develop/packages/core/src/components/forms/numericInput.tsx#L218 and https://github.com/palantir/blueprint/blob/develop/packages/core/src/components/forms/numericInputUtils.ts#L91 ?

My props:

<NumericInput
    fill={true}
    value={value}
    clampValueOnBlur={true}
    onValueChange={this.updateNumber}
    minorStepSize={1e-20}
/>

the rounded numbers above have been collected from this.updateNumber from valueAsNumber param (no difference between it and valueAsString).

Property documentation pasted below does not mention that minorStepSize is being used at all to derive precision of the input or/and rounding logic applied:

 /**
     * The increment between successive values when <kbd>alt</kbd> is held.
     * Pass explicit `null` value to disable this interaction.
     * @default 0.1
     */
    minorStepSize?: number | null;
@TheRayTracer
Copy link

TheRayTracer commented Jun 27, 2023

I have experienced the same undesired behavior with the NumericalInput component when attempting to make input forms for scientific computing.

Blueprint core version:
@blueprintjs/core: 4.20.1

For example, when props are:

<NumericInput
                        id={"eccentricity"}
                        fill={true}
                        clampValueOnBlur={true}
                        stepSize={0.01}
                        minorStepSize={0.0001}
                        min={0}
                        max={1}
                        defaultValue={0.0001}
                        rightElement={<div className="mr-2">[0 - 1]</div>}

Values are rounded up or down, and seems impossible to have a value such as 0.0001 without the value being rounded down to 0 on blur.

I have traced this behavior to the following:
https://github.com/palantir/blueprint/blob/develop/packages/core/src/components/forms/numericInput.tsx#L248

It seems that the NumericalInput component is preforming rounding on the input in addition to just clamping the number. There is most likely a logical and sound reason for this, however, this behavior is not documented with the clampValueOnBlur flag.

It further seems that the component attempts to offer some control around this rounding feature via the minorStepSize prop: https://github.com/palantir/blueprint/blob/develop/packages/core/src/components/forms/numericInput.tsx#L265
However, setting this is a small number such as 0.00001 has no effect.

Possible solutions:

  1. Document the clamping AND rounding behavior (and how to control it).
  2. Remove the rounding feature and just clamp the inputted number.
  3. Add an additional and separate roundValueOnBlur type flag to perform the rounding if requied.

@adidahiya
Copy link
Contributor

fixed by #6382

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

No branches or pull requests

3 participants