-0.5881598.powf(2f32) over/underflowing to 489298620000.0 on thumbv7em-none-eabihf On native its 0.3454914

Not sure where its going wrong. Luckily its far faster to compute with multiplication so I fixed mine, but seems like maybe some edge cases left to test.

Related, maybe pow(2) should short circuit to multiplication?

We have a bunch of high-performance DSP algorithms and functions in https://github.com/quartiq/stabilizer/tree/master/dsp/src and would like to factor them out for wider usage. Before we get started with that, I wonder whether micromath is a good place for them. It matches the mission statement ("Optimizes for performance and small code size at the cost of precision.") but is predominantly integer-oriented (apart from the f32 IIR filter). Opinions?

Note: I'm still relatively new at Rust, so feedback on style is welcome.

The problem with acos() was that it didn't handle the singularity at zero, and it didn't normalize negative numbers. I made the behavior match f32:acos().

~~The only remaining concern I have is that there might still be an underflow very, very close to zero.~~

Closes #74

It would be brilliant for embedded developers constrained to soft floats and a lack of libm support if this crate provided a wrapper type around f32 that implemented traits from num-traits. This would allow increased compatibility with the rest of the ecosystem given that num-traits is the gold standard for numeric values.

removed un-necessary code in fract and utils, added MANTISSA_BITS which is the number of bits reserved for the f32 mantissa (23), and added powi

Was working on another project which needed this functionality in an environment where it wasn't built in. Saw rust had this functionality as well in std and decided to just implement it for micromath

There are about a million different implementations of each, but for exp and ln, you basically end up with a splitting based upon 2^n splitting and Horner schemes, or generated polynomials as the fastest methods. You can tweak the iterations but overall there's really not much more you can do to make things faster, you generally end up with 4 -> 5 multiply adds on top of some bit-twiddling and a few non-iterative additions.

Powf is pretty much always going to be based upon x^logx(b) scheme, and because of this rely heavily on both your exp/expx and ln/logx being reasonably accurate, as powf will inherit both functions error, if you skimp too much on accuracy you get extremely poor results. That said, relative accuracy was pretty high in all of these tests, with powf being 0.002 relative (so not absolute like some of the tests present) in every instance tested (though not exhaustive).

There are also some checks made for inputs of 1.0 and 0.0 in some functions, to provide exact output in those scenarios, I wasn't sure if they were necessary, but error is horrendous at the edges of the polynomial approximations, where 1.0 and 0.0 almost always were, resulting in some pretty bad error (ie I remember something like ln(1.0) == 0.0006... at some point in testing).

The fract and trunc functions should work in all normal scenarios, but its possible that you would want versions which don't care about the sign of what is being extracted. In such cases it might make more sense to have separate functions, but I wasn't sure if that was in the scope of "micromath" in general.

This is my first time writing anything substantial in rust, and I'm not sure I've followed proper idioms, and I'm willing to make massive modifications if need be.

I passed in a slightly negative value, -0.09557510558, and got a very unexpected value near -1.5. The correct output should be near +1.6 (i.e. close to +90 degrees).

I had intended to pass in 0.0, with an expected output of +1.57 (+90 degrees), but when I tried that, I got a panic. (The approximation is dividing by zero.)

There are hints in the associated StackExchange article (referenced in acos.rs) that suggest a fix for this.

Hi,

I noticed that the vector rotation formula used is only valid for quaternions of unit length, so I made the requirement documented and expanded the expression to not need a square root anymore.

The old expression with self.inv() on the quaternion does not transform the quaternion into something valid for rotation. By definition a quaternion is a rotation, if and only if, it has unit length. The same expression can be found here: https://en.wikipedia.org/wiki/Quaternions_and_spatial_rotation, but they are explicit in that the quaternion is of unit length.

Hi,

I added the bog-standard Quaternion -> Euler angles conversion (https://en.wikipedia.org/wiki/Conversion_between_quaternions_and_Euler_angles) Not sure how "unity" constraints are viewed in this library, so I went with the simplest approach.

Since the vector feature uses generic-array, I thought I'd take a look at porting it over to const generics now that Rust 1.51 stabilized min_const_generics.

It seems given the current way the vector types are structured, that isn't possible as the axes are defined using an associated type and support for generic parameters requires const_generics, not min_const_generics.

However, I'm also noticing the way the vector types are implemented is... not great.

I do still like the use of discrete x, y (and for 3D vectors, z) coordinates which more or less follows existing Rust embedded conventions. However these are defined using macros with separate structs for each type, as opposed to making the coordinates generic.

I think perhaps by refactoring to make the coordinates generic, and reducing the trait portion to just the functionality shared by 2D and 3D vectors, it's possible const generics won't be needed at all.

Includes a quoted prose description of the method by Nick Capen originally from:

http://forum.devmaster.net/t/fast-and-accurate-sine-cosine/9648

Unfortunately the site has since gone down, hence including it into the rustdoc.

Hi there,

Is there any interest in supporting f64 in this crate? I am interested in converting a high precision scientific time computation library to no_std, but it requires 64-bit floating point values and a few functions (sin, div_euclid, and rem_euclid). I'd be happy to give it a shot.

Moreover, and maybe that should be a separate issue, using a Pade approximation for the cosine computation might increase the precision of the result if that is desired.

Cheers

Hello! Tried to build for UEFI and got the following error:

$ cargo +nightly build -Z build-std=std,panic_abort --target x86_64-unknown-uefi
// ...
error: linking with `rust-lld` failed: exit status: 1
  |
  = note: rust-lld: error: undefined symbol: fmodf
          >>> referenced by /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/micromath-2.0.0/src/float.rs:489
          >>>               libmicromath-70d91a162d5a686d.rlib(micromath-70d91a162d5a686d.micromath.3zoex4n7-cgu.12.rcgu.o):(_$LT$micromath..float..F32$u20$as$u20$core..ops..arith..Rem$GT$::rem::h2c54b78270aa0a20)
          

error: aborting due to previous error; 7 warnings emitted

error: could not compile `uefi-app1`

To learn more, run the command again with --verbose.

I hacked the sources, removed Rem/RemAssign and built my sample but would like to wonder if this ok in common. Thanks in advance!