try_from_degrees rounds away from the nearest sixteenth at two f32 inputs

Aberta Para iniciantes
  • Algo errado?
#79 0 comentários 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
2/5
Tempo estimado
1-3 horas
Facilidade para iniciantes
84/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
rust
Domínio
embedded-iot

Direção de pesquisa

Comece em src/lib.rs:441 e leia os testes existentes ties_round_half_away_from_zero e the_rejection_boundaries_are_exact_and_closed. Verifique os dois valores f32 reportados e o oráculo f64 documentado; em seguida, adicione cobertura para os limites internos de meio LSB e confirme que try_from_degrees retorna os valores arredondados documentados sem alterar o comportamento de rejeição.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

audit:SBOS663A bug impact:field-visible

Celsius::try_from_degrees documents its rounding as:

Values are rounded to the nearest
sixteenth of a degree, half away from zero.

src/lib.rs:404-405

It does not do that for two inputs. Both are the f32 immediately below
±1/32 — strictly nearer to zero than to one sixteenth, so both must round
to 0. Both round to ±1.

Measured

Exhaustive, not sampled: the function was transcribed verbatim into a
scratch binary and run under rustc -O against an f64 oracle over
all 2^32 f32 bit patterns.

exhaustive sweep of all 2^32 f32 inputs
TOTAL DISAGREEMENTS: 2

  bits=0x3cffffff  x= 3.12499981373548508e-2  driver=Ok(1)   documented=Ok(0)
  bits=0xbcffffff  x=-3.12499981373548508e-2  driver=Ok(-1)  documented=Ok(0)

The oracle applies the documented contract in f64: scale by 16 (exact),
round half away from zero, then reject if the rounded value leaves
-2048..=2047. Two disagreements, and no others anywhere in the domain.

Cause

src/lib.rs:441:

let rounded = if scaled >= 0.0 { scaled + 0.5 } else { scaled - 0.5 };

degrees * 16.0 is exact — multiplying by a power of two. The error is in
the half-add. For x = 0.031249998137354851, scaled is 0.49999997,
and 0.49999997f32 + 0.5f32 is 0.99999997 exactly, which is not
representable in binary32; it rounds to 1.0 (ties-to-even against
0.99999994). Truncation then yields 1 instead of 0.

So the tie test happens after a rounding step that can manufacture a tie
that the input did not have.

Scope

Narrow but real. try_from_degrees is the public boundary feeding
set_low_limit / set_high_limit, so an affected input programs a
threshold one LSB (0.0625 °C) away from its advertised value. The two
inputs are not values anyone types as a decimal literal; they arise from
computed floats.

This is a defect against the driver's own documented contract, not
against the datasheet — SBOS663A §7.5.2 specifies the 0.0625 °C
resolution and two's-complement format, and says nothing about how an
arbitrary float should reach a representable value. Rounding policy is
driver policy, as it is for snap_hysteresis in #76.

Why the existing tests miss it

ops_tests covers exact ties (ties_round_half_away_from_zero,
src/lib.rs:4079) and the outer rejection boundaries
(the_rejection_boundaries_are_exact_and_closed, src/lib.rs:4106).
Neither covers the representable neighbours just inside a tie, which is
precisely where the half-add misbehaves.

Options

  1. Round without an intermediate half-add. Compare against the tie
    directly, or perform the add in a wider type. Deletes the failure mode
    rather than special-casing it.
  2. Widen to f64 for the rounding step only. One cast; no_std safe;
    the oracle above is exactly this and is correct over the whole domain.
  3. Document the exception. Cheapest, but the contract sentence would
    have to name two specific bit patterns, which is worse than fixing it.

Any of 1 or 2 changes observable output for two inputs, so it wants a
changelog-visible commit.

Suggested test

Enumerate every internal half-LSB boundary and its two f32 neighbours
(12,285 cases) against an independent oracle, rather than a hand-picked
list. The full 2^32 sweep runs in ~2 s on 16 threads if you ever want it
as a one-off.

Provenance

Raised by the datasheet compliance audit of PR #77, then reproduced
independently. Not a regression — the behaviour predates #77; it was
simply never asserted.

Linguagem predominante
Rust
Estrelas
2
Forks
7
Nenhum PR com merge em 30d

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de OpenDevicePartnership/tmp108

Todas as issues de OpenDevicePartnership/tmp108

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.