`.inf` not within floating point range

[christianrauch]

Since the last lyrical update, the following:

admittance_controller:
  my_param:
    type: double
    default_value: .inf
    validation:
      gt_eq<>: 0

causes:

  what():  parameter 'my_param' could not be set: Parameter {my_param} doesn't comply with floating point range.

This can be reproduced with the generate_parameter_library_example, adding the my_param parameter above and running:

ros2 run generate_parameter_library_example test_node --ros-args --params-file src/generate_parameter_library/example/config/implementation.yaml

I cannot pinpoint the exact change that causes this. It's not just caused by the 1.2 to 1.3 update; there must be other package updates involved. In any case, the above example used to work and I think it should continue to work

[christophfroehlich]

The change comes from ros2/rclcpp#3161
I think there is nothing we can do about this, as we have to set an fom_value and to_value for the floating_point_range parameter descriptor. There is no one-sided version afaik.

[pum1k]

I tried to test this locally and see what is the code generated here.
It looks like the gt_eq validation generates upper bound double max instead of double inf.

This is the relevant part of the generated code:

if (!parameters_interface_->has_parameter(prefix_ + "my_param")) {
    rcl_interfaces::msg::ParameterDescriptor descriptor;
    descriptor.description = "";
    descriptor.read_only = false;
    descriptor.floating_point_range.resize(1);
    descriptor.floating_point_range.at(0).from_value = 0;
    descriptor.floating_point_range.at(0).to_value = std::numeric_limits<double>::max();
    auto parameter = to_parameter_value(updated_params.my_param);
    parameters_interface_->declare_parameter(prefix_ + "my_param", parameter, descriptor);
}

From my test in ros2/rclcpp#3218, I think this should be fixed here by generating std::numeric_limits<double>::infinity() instead of max.

[christianrauch]

I tried to test this locally and see what is the code generated here. It looks like the gt_eq validation generates upper bound double max instead of double inf.

Thanks for looking into this and discovering the root cause.

It turns out that the Python implementation already uses -float('inf') for the bounds float('inf'), and the C++ implementation was using different and stricter bounds. Note that std::numeric_limits<double>::lowest() and std::numeric_limits<double>::max() are finite values, whereas float('inf') and std::numeric_limits<double>::infinity() are non-finite.

The PR #378 fixes my issue.