consider interpreting "precision": 0 (the default) to mean unlimited precision

[mejohnnaylor]

At present, precision for floats defaults to 0. This turns floats into integers which is almost certainly not what the model designer wants/expects.

Can we have clients interpret precision = 0 to mean precision as wide as the data type supports? About 9 digits for 32-bit floats?

[james-peltzer]

not sure i like this. partially because it is a breaking change and partially because it prevents using a float for a whole number field if that's what the designer chooses - there is no reason why this should not be valid to do.

[mejohnnaylor]

discussion 3/22/24 - there's another way we could go on this: use client_hints to provide precision info. like this:

client_hints: {"w.precision": "2"}

or it could go into the constraints unconstrained and range being the only 2 applicable to float.

"constraint": {
  "type": "FLOAT_RANGE",
  "float32_range": {
     "min_value": 0.0,
     "max_val": 1.0,
      "precision": 3,
     "step": 0.01,
  }
}

one of precision or step needs to be defined (or if both are absent, it gets interpreted as step 1, precision 0)

The w. prefix tells the client that the hint is for the owning param's widget.

Pros: the display precision is wholly client-side, the server won't care. Cons: would need to communicate a common set of client hints as an appendix in standard, possibly

it may be possible to drop precision from the param message altogether.

let's mull on this and revisit next week.