numlike 0.1.2

Numeric traits for generic mathematics. Less restrictive alternative to num-traits.
docs.rs failed to build numlike-0.1.2
Please check the build logs for more information.
See Builds for ideas on how to fix a failed build, or Metadata for how to configure docs.rs builds.
If you believe this is docs.rs' fault, open an issue.
Visit the last successful build: numlike-0.1.5

Repository Docs Crates.io MIT OR Apache 2.0

numlike

Numeric traits for generic mathematics. Less restrictive and less conservative alternative to num-traits.

This crate has no unsafe code and no mandatory third-party dependencies, and is no_std-compatible. However, when operating on floats, pow(), mul_add(), div_euclid(), rem_euclid(), div_rem_euclid() functions and their checked variants still require std.

Why numlike and not num-traits?

We developed numlike because we disagree with many of design decisions in the venerable num-traits crate:

  • num-traits's Zero and One traits respectively require Add and Mul traits to be implemented. This makes it impossible to distinguish a 0 for algebraic structures that don't implement addition (e.g. absorption magma and absorption monoid, aka. monoid with zero), and likewise 1 when there is no multiplication (e.g. because a naive implementation of multiplication for all elements would be inefficient).
    • num-traits also requires Output = Self for Add and Mul, making it impossible to use Zero and One for statically-typed unit of measurement libraries like uom.
      • numlike does not have these problems because it does not have any supertraits for its Zero and One traits.
    • Moreover, num-traits's Zero and One do not provide ZERO and ONE associated constants, but instead return them from ::zero() and ::one() functions. These constants were only later added through new separate traits, ConstZero and ConstOne, presumably to avoid breaking changes.
      • numlike's Zero and One provide ZERO and ONE associated constants.
  • num-traits's Bounded trait only returns finite minimum and maximum values. This makes no difference for integers, but e.g. for floats .max_value() returns f64::MAX, which is actually the largest finite number, not the positive infinity. num-traits has no way to generically obtain positive or negative infinity as min. or max. value.
    • numlike solves that by providing MinExtended/ MaxExtended traits that result in negative and positive infinities for floats, and MinFinite/ MaxFinite traits that give only finite values just as above num-traits's Bounded does.
  • num-traits provides .signum() and .abs() methods only for types implementing Signed trait, which excludes unsigned integer types.
    • But having these methods generically for both signed and unsigned types can be useful for finding canonical denominators and reducing fractions, so numlike provides these methods through decoupled traits, Signum and Abs implemented for all numeric primitives.
  • num-traits does not provide checked mathematical operation traits, CheckedAdd, CheckedSub, CheckedMul, CheckedDiv, CheckedNeg, CheckedRem, for floats.
    • numlike implements its own versions of these traits for all numeric primitives.
  • Developers of num-traits seem to avoid breaking changes, strongly preferring to create new traits instead of making modifications to existing ones. This provides stability for users, but prevents at least some of the above issues from being solved.
    • Because of that, we have decided to roll our own library (this crate). However, because it's in active development, we are lacking the stability of num-traits, as we are likely to have many breaking changes.
  • Furthermore, numlike also has its own features, such as:
    • Equality and order traits that fix NaNs to be the highest value in the set, even larger than positive infinity, allowing for total order: NanPartialEq, NanEq, NanPartialOrd, NanOrd.
      • But if you want core::cmp traits instead, consider using ordered-float crate's OrderedFloat float type wrapper instead. This is obviously often the better choice, because core::cmp traits will work with a much larger number of existing libraries and have Rust's syntactic sugar.