Confusing behavior for integer Annotator initial values

[jbednar]

Using the latest HoloViews master (hopefully soon to be released), the first example in Annotators.ipynb uses an Element with integer coordinates: points = hv.Points([(0, 0), (1, 1), (2, 2)]). The behavior for that example is quite confusing: the points can be dragged to an arbitrary location in the x,y plane, but the locations remain integers:

If the type is truly meant to stay integral, I would expect that the location of the point should "snap" to the integer coordinates after dragging, to make the display consistent with the Python data structure. In any case, this is a very confusing example, and the behavior should either be acknowledged or updated not to use integer coordinates for the initial locations.

BTW, if updating that example, it would be nice not to show NaN, and it would also be nice if hover would show the label values so that people could verify that the right label is associated with the right point.

[philippjfr]

If the type is truly meant to stay integral, I would expect that the location of the point should "snap" to the integer coordinates after dragging

It's problematic because it's only displayed as an integer because the table uses type inference to instantiate an IntFormatter on initialization. Internally the data is actually stored as float it just gets rendered as an int. I think changing the example is the only reasonable approach apart from introducing a ton of special handling on the JS end that actually looks at the table formatters to perform casting.

it would be nice not to show NaN

What empty cells get displayed as also depends on the formatter, if the formatter is numeric (which is required to enter numeric values) then it will always render empty cells as NaNs, so I really have no control here.

it would also be nice if hover would show the label values so that people could verify that the right label is associated with the right point.

That definitely seems like a good idea.

[jbednar]

Ok, changing the example to avoid this confusion seems like a reasonable approach.

What empty cells get displayed as also depends on the formatter, if the formatter is numeric (which is required to enter numeric values) then it will always render empty cells as NaNs, so I really have no control here.

Hmm; can a default value be supplied for that column?

Separately, seems like empty values should display as empty space, which is what Pandas, Excel, and just about every other table that I know of does...

[jbednar]

Hmm; empty values do display as empty space for values after the table is created, just not for points that existed from the start:

This behavior seems confusing and inconsistent, but maybe there is a good explanation.

[philippjfr]

Hmm; can a default value be supplied for that column?

Yes, I should definitely expose that as an option.

Hmm; empty values do display as empty space for values after the table is created, just not for points that existed from the start:

Probably to do with the casting that the edit tool performs. If the column contains numeric values then it's deserialized as a typed array and empty values become nans. The drawing tool then converts the typed array to a regular JS array so it can be edited at which point you can have actual null values. Quite annoying and I don't see an obvious solution.

[jbednar]

In the above table, turns out the user-added values have the Python value "None" (which displays as empty space), while the default values have the value "NaN". That's definitely odd. I would assume that empty items should be None in all cases, but it does sound a bit tricky to achieve that.

[philippjfr]

Definitely need to look into that. I did add some code to try to ensure that if the column contains numeric values any Nones should become NaNs on Python deserialization. It looks like that's actually a string column though in which case I'd expect even the 6 in there to be a string and all empty values to be Nones.