v0.6.9 Release

[Mec-iS]

No description provided.

[Mec-iS]

Review

Verified locally on the development branch (this PR's head):

• cargo fmt --all -- --check — clean
• cargo clippy --all-features -- -Drust-2018-idioms -Dwarnings (and again with -Drust-2024-compatibility) — clean
• cargo build / cargo build --all-features / cargo +1.85.0 build --all-features (MSRV) — all build
• cargo test and cargo test --all-features — 501 unit tests + 72 doctests pass, including the new cross_validate_with_precision_and_integer_labels regression test for Trait bounds of RandomForest::fit conflict with those of predict and other metrics #322
• Confirmed RandomForestClassifier's TY: Number + Ord bound (no RealNumber), which is exactly the mismatch reported in Trait bounds of RandomForest::fit conflict with those of predict and other metrics #322: precision/recall/f1 previously required Number + RealNumber + FloatNumber, which no integer type implements.

Code correctness looks solid:

• label_bits correctly widens any Number to f64 via ToPrimitive::to_f64(). I checked to_f64() returns Some for every current Number impl (f32/f64/all integer primitives), so .expect("class label must convert to f64") can't panic today.
• Bonus fix: the old RealNumber::to_f64_bits for f32 did self.to_bits() as u64 (widening the raw 32-bit pattern into a u64, not actually converting the value to f64). label_bits now does a real value conversion. Never mattered in practice (y_true/y_pred are always the same T), but it's a latent correctness improvement.
• Per-class precision/recall/F1 math and binary vs. multiclass macro-averaging are unchanged — only the label-keying mechanism and generic bounds changed.

One inconsistency worth fixing before/after merge (not caught by tests/clippy since it's an unused path):

ClassificationMetrics::<T>::precision()/recall()/f1() (src/metrics/mod.rs:122) was not updated and still requires T: Number + RealNumber + FloatNumber, while the standalone precision()/recall()/f1() functions (mod.rs:189-214) now bypass ClassificationMetrics and construct Precision::/Recall::/F1::new() directly with only T: Number. This fails to compile:

ClassificationMetrics::<u16>::precision();
// error[E0599]: trait bounds not satisfied: `u16: RealNumber`, `u16: FloatNumber`

So the struct-based entry point still can't be used with integer labels even though Precision<T> itself and the free precision() function now can. Not a regression, but it leaves the fix for #322 half-applied on the ClassificationMetrics surface, which the module docs point to as the primary entry point. Suggest relaxing the impl<T: Number + RealNumber + FloatNumber> ClassificationMetrics<T> bound the same way (or documenting that integer labels should go through the free functions / Precision::new() directly).

Minor nit: the CHANGELOG entry says labels "no longer need to implement RealNumber" but doesn't mention FloatNumber was also dropped from the bound — harmless, just slightly incomplete.

Otherwise LGTM — approve after the ClassificationMetrics bound is addressed (or explicitly deferred with a note/issue).