snap_hysteresis's tolerance band is asymmetric at two of its eight edges

Ouverte
  • Quelque chose ne va pas ?
#76 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
rust
Domaine
embedded-iot

Piste de recherche

Start with src/lib.rs and run ops_tests::hysteresis::the_band_edges_are_asymmetric, which records the current behavior. Decide whether the tolerance policy should remain approximate or change to midpoint, scaled tolerance, or inclusive slack. Done means a deliberate behavior choice, updated tests, and a changelog-visible commit if behavior changes.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

bug

ops::snap_hysteresis (src/lib.rs) rejects an input further than
HYSTERESIS_TOLERANCE from the nearest legal setting. The constant is
0.05f32, whose exact value is 0.05000000074505805969, and the
comparison is against a subtraction whose result depends on which side
of its decimal value each f32 literal rounded to.

Measured

Both functions were transcribed verbatim into a scratch binary and run
under rustc -O rather than reasoned about on paper:

Setting −0.05 edge diff +0.05 edge diff
0 °C accepted 0.05 accepted 0.05
1 °C rejected 0.050000012 accepted 0.049999952
2 °C accepted 0.049999952 accepted 0.049999952
4 °C accepted 0.049999952 rejected 0.05000019

Six of eight edges are accepted, and the two rejections fall on
opposite sides — the low edge at 1 °C, the high edge at 4 °C. No
single description of the band is correct for all four settings.

So a caller asking for 0.95 °C of hysteresis gets InvalidInput, while
one asking for 1.05 °C gets Hysteresis::OneC. Both are the same
distance from 1 °C as written; only their f32 representations differ.

Status

Pinned as measured by
ops_tests::hysteresis::the_band_edges_are_asymmetric, added while
closing #66, so any change to it is deliberate rather than silent.
Whether it should change is this issue.

Note the ±0.05 °C band is driver policy, not a datasheet tolerance —
SBOS663A §7.5.3.1 Table 9 specifies the four discrete encodings and
says nothing about how an arbitrary float should reach one. #66 Part 2
records the band as a legal choice.

Options

Roughly in increasing order of disruption:

  1. Leave it. Document the band as approximate. A caller sitting
    within 0.05 °C of an edge is already asking for a setting it did not
    name, and the four settings are 1 °C apart.
  2. Compare against the midpoint between adjacent settings, or
    against a tolerance scaled per setting, so the decision does not
    turn on one constant's representation.
  3. Make the comparison inclusive with slack — e.g. > against
    HYSTERESIS_TOLERANCE + f32::EPSILON, making all eight edges
    accept.

Any of 2 or 3 changes behaviour for callers currently on the rejected
side of an edge, so it needs a changelog-visible commit.

Provenance

Raised while closing #66. Not a regression — the behaviour predates
that work; it was simply never asserted.

Langage dominant
Rust
Étoiles
2
Forks
7
Aucune PR mergée en 30 j

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de OpenDevicePartnership/tmp108

Toutes les issues de OpenDevicePartnership/tmp108

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.