gjf2a / bare_metal_modulo Goto Github PK

I've found myself in need of a library like this, and it fulfills almost all of my uses! However, I also need to count how many times the modulated value is wrapped around the modulus when performing an addition. For example, if I have 8 mod 17, and add 42 to it, I'd get the usual 16 mod 17, along with a 2 to indicate that the modulated value wrapped around the modulus twice.

I'm happy to add this functionality myself and make a PR, but wanted to get feedback beforehand. Namely, I'd love some advice on what to name this method.

Assess whether OffsetNumC ought to work with signed values only. If so, enforce this at the type level.

Currently, inequalities between a ModNum and a regular integer compare .a() against the integer value.

Would it be better to compare against the integer (mod m)? Currently, my doc test demonstrates the former comparison. This would be a backwards-incompatible change.

I need to think this over.

Currently, the Pow trait allows the .pow() operator to be overloaded for both raw numbers as well as modular numbers. I would like to introduce similar PowSigned and PowAssigned traits to enable the same treatment for .pow_signed() and pow_assign(), which at the moment are only defined for raw number rhs arguments.

This isn't hugely important, because one can always use .a() to transform the right-hand side. But it would make these methods consistent with how everything else in the crate works.

I didn't yet implement .pow() for WrapCountNum and WrapCountNumC, as tracking the wraps would significantly disrupt the current implementation. But I would still like to do this. It will require creating a separate implementation from the current one that is engineered to track the wraparounds as the multiplications and additions occur.

let mut off = OffsetNum::<usize>::from(1..=10);
assert_eq!(off.a(), 1);
assert_eq!(off, 1);

The above test fails.

Right now, subtraction on the wrapped types requires a Signed value. Relax this restriction.

OffsetNumC needs documentation tests. It also needs a ModNumIterator implementation and methods to return its minimum and maximum values.

Hi, finding this crate very useful, but I discovered an unexpected, or non-intuitive behavior with the way OffsetNum arithmetic works. Consider the following:

let x = OffsetNum::new(3, 10, 1);

println!("{:?} {}", x, x.a());
let y = x - 1;
println!("{:?} {}", y, y.a());

This results in:

OffsetNum { num: 2, modulo: 10, offset: 1 } 3
OffsetNum { num: 2, modulo: 10, offset: 1 } 3

whereas I would have expected:

OffsetNum { num: 2, modulo: 10, offset: 1 } 3
OffsetNum { num: 1, modulo: 10, offset: 1 } 2

That is, I would have expected arithmetic with integers to always be relative regardless of the offset. After some experimentation, it seems that the integer is first being converted to OffsetNum::new(1, 10, 1), which is equivalent to 0 due to the offset so that the subtraction has no effect. It is obvious how I can accomplish what I want, but is this the intended behavior or an oversight due to just simply doing the obvious conversion before the subtraction?