Scientific Notation for Widgets?

[rpep]

If you create a widget as so:

A = FloatText(value=6e12)

Then the value is converted out of scientific notation as so:

It would be a great feature to be able to give a string specifier to the widget to stop this from happening. I'm trying to use widgets for scientific data and it looks really odd when dealing with large parameters.

[rpep]

Should note that this is possible in the FloatSlider, though the model and view of this is more complex because the value is parsed using d3-format to get the representation.

[minrk]

The Widget has no way of knowing that it was given as scientific notation. As far as Python is concerned, 6e12 and 6000000000000. are perfectly indistinguishable. We could add a format-string option to the widget, though.

[SylvainCorlay]

@minrk for the sliders, we have a readout_format attribute which allows you to specify a formatting string using Python's format specification mini-language. (Hence you can pass something like .2f).

On the javascript side, this is implemented in the d3-format npm package which comes from d3's big split.

The reason why I have not done this for inputs is that I am not sure what the behavior should be when you type. Should it reformat your input on validation? ...

[dajuro]

I just ran into this problem in a project I'm currently working on. I find it strange that there is a different behavior for the slider (readout_format) and the other widgets.

@SylvainCorlay reformatting the input after the user stops typing is what I'm implementing right now using a lot of "observe" code. But that seems silly to me. Is it possible to subclass let's say FloatText and add a NumberFormat trait?

[jasongrout]

Is it possible to subclass let's say FloatText and add a NumberFormat trait?

Of course! You can use the widget-cookiecutter to get a head start on building a package for it.

But I think even better would be putting in a PR to the FloatText widget to add a value_format (or a better name) attribute. The FloatText already understands input in scientific notation.

Here is where the widget text gets set for IntText and FloatText: https://github.com/jupyter-widgets/ipywidgets/blob/a9c4069570aa92368f590296569e411d9c49e123/packages/controls/src/widget_int.ts#L528

So we could just redirect that to a formatting function, and then implement a formatting function for IntTextView and FloatTextView. You'll notice the check in the code above checks to see if the values are equal to decide whether to update the text, but now we'll actually have to check to see if the formatted strings are equal.

This change will make the continuous_update=True a bit hard to type, but I think that's probably a rare case, and I'm not sure how useful the continuous_update True case is for IntText/FloatText.

[codingS3b]

Sorry for putting up such an old issue again but I found that the SelectionSlider widget seems not to have the readout_format argument, only the readout flag. Is there a reason for that? I use this widget also for scientific notation purposes and it would help a lot.

[boffi]

Sorry for putting up such an old issue again... The current (2022) behavior is insane because when a user sees 30000000000 in an input box, they have to COUNT the fine zeros to know what it is (in this example, the conventional Young modulus of concrete, 30 GPa (ymmv)). The issue is empirically solved asking the user to give input at a specific scale, e.g., if they input a Young modulus I ask that the input must be in GPa, and later I multiply the value by 10⁹ to work with Pa, but this is open to misunderstandings, and some quantities have a wild range of variability… Further, if the default value were shown in scientific notation, the user would be encouraged to use the same, while now they could think that they have to input all those zeros as well. What I'd really like is a work-alike of Matplotlib's EngFormatter , but just a readout_format, for the reason I have exposed, would represent a BIG advance!