Integer-floating point automation

There was an update to GH some time ago that began to automatically convert floating point numbers to integers when possible (1.00 to 1). And while it’s been somewhat frustrating for me as I’d rather maintain that control myself rather than have it handled by GH, I’ve been able to live with it.

But now I’m seeing some other things happening where integers aren’t recognized or behave differently depending on the source. It looks like there is another class of integer that happens within user input sources (I’m using a panel in this example) vs. the EXACT same number pulled directly from a node. Why?

Can I get some clarity on what is happening here? It makes zero sense to remove that layer of control from the user and makes even less sense to add another hidden class of data that looks the same to the user.

Connecting a panel to a panel means text stays text, those aren’t really floats.

Piping them through number will convert them first to a number, then back to the panel it gets converted again. You get automatic formatting there.

If you intend to use actual numbers, don’t feed them through a panel, but keep the conversions between data formats to a minimum.

1 Like

Ok, thank you. Interesting and very frustrating. Whatever conversion is happening automatically in the panel is ALSO happening when I enter persistent data directly in the node. Which sort of makes sense in the “replace” node since its looking for any data type and not just numbers and so defaults to strings.

I always thought that the panel shows the raw data as GH sees it, so this is the source of my frustration. Is there another way to see exactly how GH sees the data if not the Panel? When I hover the mouse over the output, is there a way to see and scroll through that data? That’s a huge miss if I am getting fed converted and formatted data that is fundamentally different than what GH is seeing on the back-end…

Other issues I’ve been having are starting to make sense now that I know the Panel is doing hidden tricks with the data behind the scenes.

Thanks again for your insight!

The panel tells each data item to format itself however it sees fit. For floating point numbers that means it will use the formatting options set in the preferences. These options touch upon rounding, special casing integers and multiples of pi, and when to switch from decimal to scientific notation.

If you want to see what a floating point number is really like, then you must use the Format component with the pattern "{0:R}". The R stands for roundtrip meaning no information is lost while formatting the value.

For more complicated data types such as points, vectors, planes or curves, it will become harder and harder to format the data in the same way that “GH sees it”.

1 Like

Thank you, David! I can see how the raw data is not always helpful and I appreciate the challenge of finding that balance for the Panel formatting. I had no idea about the preferences affecting integer display rounding, great to hear that’s an option. The Formatting strategy is exactly what I needed to inspect the data at a more fundamental level and can proceed much wiser.

Thanks for the response and making a great tool!

David, I was testing this out today and found a case you may want to think about. The formatting set in the GH preferences is not limited to formatting within panels but affects the entire definition’s results. So when I check “Special case integers” in the preferences I will get different results (rounded integers) than if I uncheck that (true floating point number results, even for 1.000) through all nodes, not just data run through the panel.

This may be a problem because preferences are not set by the file but at the program level. Meaning a definition could work for one user because their preferences match while the same file may not work for another user because they did not check the appropriate box in the preferences.

For instance, if I use a math function working in floating point, then split string by “.” I will get a different result depending on if “special case integers” are checked in the formatting settings. If any of my results can be rounded by that preference, there will be no “.” and so the split function will not work as intended. I could see this causing confusion to others (as it already has for me).