Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
When using the cell "Edit" option to enter a number, the behaviour should be consistent with toNumber() #2163
Comments
|
I'm all for eliminating the guessing game for users. The con here is that we lose some simplicity in handling Numbers, but its inconsistent handling so... Generally, +1 on the expected behavior to favor consistent handling. |
|
Somebody doing this issue or can I take it? |
|
go for it @PrzemyslawCieslik and you can even now do a WIP (work in progress) Draft PR in Github, so I'd suggest starting that way, so we can help along and review at same time. Here's how: https://github.blog/2019-02-14-introducing-draft-pull-requests/ |
Describe the bug
If you enter a string into a cell such as "3" and then use "toNumber()" to convert it to a number, toNumber() first tries to parse as a Long, and then tries parsing as a Double. So "3" will be stored as a Long, while "3.0" will be stored as a Double
However, if you edit a cell by using the single cell "edit" option and enter a number, and change the 'type' to Number, OR only attempts to parse the string typed into the cell edit dialogue as a Double - meaning that "3" is stored as a Double, not a Long. This means that entering "3" and "3.0" have exactly the same result in this case.
Expected behavior
The two options should be consistent in terms of how they parse strings to numbers and store the data.
The 'toNumber()' behaviour is preferred, and the 'edit' cell dialogue should be consistent with 'toNumber()' when entering numbers into cells
OpenRefine (please complete the following information):
Additional context
https://groups.google.com/d/msg/openrefine/8uq_mZMISCs/E4IKWNHeBQAJ