Why my values appears as Boolean/String & not float?

Hi there,

The following python code was made to read a jpw file that will read its values and export them as a list of floats.

import rhinoscriptsyntax as rs
import System.Decimal as decimal

def worldParam(file):
paramList =

with open(file, 'r', 0) as worldParamFile:
    for line in worldParamFile:
    return paramList

a = worldParam(worldFile)
The problem that I have is that variable ‘a’ should export floats but instead I get:

  1. A list of Boolean if I connect it directly to a component
  2. A list of string if I connect it to a panel

Can you tell me how can I rectify this problem ?

Thank you in advance
terreno-norte-17_1.zip (249 Bytes)
GIS - World File Parameters - Python 20180813.002_003.gh (8.6 KB)

Because Decimal supports much higher precision than float/double, it is not a native floating type to either C# nor GH. In order to accurately represent it, its ToString would be called.


Isn’t ToString will convert my results to string ??

I need them to be floats, with no change or rounding.

You should stick to float() to convert your strings. Don’t rely on the Panel component to show sane values for these numbers, as you’ll get all sorts of automatic representation shortenings that lie about what they represent.

As already alluded to in your other thread, Panel isn’t a good component, especially not to pipe your data through. You can use it to show data, but you shouldn’t put it between components.

Just simply use float() and check the actual data. You’ll see that you get the data you need.

See how the output of the Expression component gives you exactly (well, exactly enough, IMO, there still is some rounding going on) what you have in the data, that was also print()ed to the python output console.

IOW, you created a problem that does not exist.

edit: IronPython float is represented as System.Double. You’ll find that even using System.Decimal to initially parse, when converted to the System.Double (i.e. python float) you’ll get the rounding errors, since even the System.Double has fewer significant digits. See https://docs.microsoft.com/en-us/dotnet/api/system.decimal.todouble?view=netframework-4.7.1#remarks

There is not much you can do about, except for writing all necessary components you need to work with System.Decimal


Thank alot @jesterking

That insight was what I needed to know, specially when we are talking about precision.