Loaded assets look like numbers but are a different type

max · July 13, 2021, 6:06am

I’ve noticed that some of the downloaded outputs look like numbers but are some other type, which means I need to run them through a Number parameter component first. Is there a reason for this?

Grasshopper’s native Average component throws an error but the native Multiply component doesn’t, so I didn’t notice at first that I was getting the wrong results:

mostapha · July 13, 2021, 1:19pm

Technically it should show up as numbers. I checked the handler that loads the results and it converts them to numbers:

github.com

pollination/handlers-python/blob/8ceadd03edf057c067b7d3548106258916039e7f/pollination_handlers/outputs/helper.py#L40-L47

    
      
          result_file = os.path.join(result_folder, '{}.{}'.format(grid_id, extension))
          with open(result_file) as inf:
              for _ in range(st_ln):
                  next(inf)
              if is_percent:
                  results.append([min(float(next(inf)), 100) for _ in range(sensor_count)])
              else:
                  results.append([float(next(inf)) for _ in range(sensor_count)])

@mingbo, is this the behavior of the Grasshopper component to change the type to text if it doesn’t know the type? Or does it use the type of the output alias?

@chris, can you confirm that I’m checking the correct function for parsing the results?

mingbo · July 13, 2021, 4:32pm

I can confirm here I can recrate this issue.
It is because I used a generic GH_ObjectWrapper for all output data for constructing the GH_DataTree, instead of trying to guess what each of the real types are.

I will try to find a better solution here.

chriswmackey · July 20, 2021, 5:49pm

I know I’m incredibly late here but I thought it was still worth confirming that @mostapha has found the correct handler function there. The issue is in regards to the GH_ObjectWrapper that is being used. In case it’s helpful, @mingbo , this is how we construct the DataTree in IronPython:

github.com

ladybug-tools/ladybug-rhino/blob/master/ladybug_rhino/grasshopper.py#L238-L262

    
      
          def list_to_data_tree(input, root_count=0, s_type=object):
              """Transform nested of lists or tuples to a Grasshopper DataTree.
              
              Args:
                  input: A nested list of lists to be converted into a data tree.
                  root_count: An integer for the starting path of the data tree.
                  s_type: An optional data type (eg. float, int, str) that defines all of the
                      data in the data tree. The default (object) works will all data types
                      but the conversion to data trees can be more efficient if a more
                      specific type is specified
              """
          
          
    def proc(input, tree, track):
                  for i, item in enumerate(input):
                      if isinstance(item, (list, tuple, array.array)):  # ignore iterables like str
                          track.append(i)
                          proc(item, tree, track)
                          track.pop()
                      else:
                          tree.Add(item, Path(*track))

This file has been truncated. show original

I think we get away with using the s_type=object in IronPython because GHPython does type-checking on everything that is output from the component. On the C# end, if you were to use a different s_type when constructing the data tree, I think you can get everything imported as a float instead of the generic object type.