I would like to see the ability to record numbers in scientific notation. I have seen this come up when certain instruments only output sample results in scientific notation, and right now the user cannot enter it in how they see it on the instrument.
The preference will be to implement this in line with an ISO or other standard, which I’m having a hard time turning up. In the meantime, can you clarify which, if any, of these formats would be acceptable this case:
Superscript: 3.14 x 102
E notation: 3.14e2
Carat: 3.14 X 10^2
For this use case, superscript would be ideal.
This is a little bit of a tricky thing to implement on the engineering side for a few reasons:
- Scientific notation is represented as text, and right now Tulip Inputs are Text or Number, not a Number, but entered as text. Right now, the Number input will only allow numerical input, and that would have to change to support scientific notation input. This is problem usually addressed by taking a text input, then converting it to a number in the background. Right now this is a tricky thing to do with traditional triggers.
- Superscript input isn’t something we support in text inputs right now. This down to limitations of the html text input type not supporting exponential notation. Again, something that could be resolved by making our own input type that supports this, but its not a small ask. In that regard, E Notation or Carat notation are significantly easier to implement.
Here is the good news…
Over the last 3 months we have been testing a new feature called Custom Widgets where users can extend the edges of the platform to fit their needs. Our team is developing tons of widgets as part of the library that can just be downloaded and used, and coming in r230 (releases at the end of the week) the ability to make your own custom widgets will be coming to all enterprise customers.
I spent about 10 minutes and made this, It supports carat and e notation-
I will write up a feature request to support this functionality natively , but I struggle some to understand the right way to natively support this without adding another input type.
If you want to use this widget, I can share it with our library team and get it added to a future release.