RFR: 8338529: Initial iteration of numerics modeling interfaces [v3]

[Brian Goetz]

Overall I agree with the direction that while we should be _inspired by_ 
algebraic structures, we should not slavishly adhere to them, because 
these are not platonic numbers, and they fail to obey the algebraic 
axioms in all sorts of ways.

I think we can borrow much hard-won experience from our friends in the 
Haskell community.  For example, `Num a` defines both (+) and (*), and 
suggests the existence of additive and multiplicative identities, but 
appeals not to ring-ness but to something more like "be reasonable".  
Specifically, it says "looks like a ring, lots of Nums are rings, but 
actually requiring it would be too restrictive."  And despite the 
seeming complexity of the Haskell numeric tower, there is much 
(sensible) lumping going on in the base Num class.  (All of these 
properties seem like candidates for shameless stealing.)

Haskell also relegates the algebraic structure (ring, monoid, etc) to a 
different corner of the field (heh), separate from the types describing 
numerics, and doesn't attempt to use symbolic operators, instead using 
nominal functions like `mzero`.

The point about implementing both `Num` and `Ord` is one of those 
"obvious not obvious" statements; given that an ordered ring includes 
additional axioms above the union of the ring and ordering axioms, it 
would not be reasonable to expect "witnesses Ord" and "witnesses Ring" 
to mean "witnesses OrderedRing".  Instead, one would need an OrderedRing 
type class, which extends Ord and Eq, and adds additional laws.

> The Haskell Report defines no laws for |Num 
> <https://hackage-content.haskell.org/package/base-4.22.0.0/docs/GHC-Num.html#t:Num>|. 
> However, |(|+ 
> <https://hackage-content.haskell.org/package/base-4.22.0.0/docs/GHC-Num.html#v:-43->|)| 
> and |(|* 
> <https://hackage-content.haskell.org/package/base-4.22.0.0/docs/GHC-Num.html#v:-42->|)| 
> are customarily expected to define a ring and have the following 
> properties:
>
> *Associativity of |(|+ 
> <https://hackage-content.haskell.org/package/base-4.22.0.0/docs/GHC-Num.html#v:-43->|)|*
>     |(x + y) + z| = |x + (y + z)|
> *Commutativity of |(|+ 
> <https://hackage-content.haskell.org/package/base-4.22.0.0/docs/GHC-Num.html#v:-43->|)|*
>     |x + y| = |y + x|
> *||fromInteger 
> <https://hackage-content.haskell.org/package/base-4.22.0.0/docs/GHC-Num.html#v:fromInteger>| 
> 0| is the additive identity*
>     |x + fromInteger 0| = |x|
> *|negate 
> <https://hackage-content.haskell.org/package/base-4.22.0.0/docs/GHC-Num.html#v:negate>| 
> gives the additive inverse*
>     |x + negate x| = |fromInteger 0|
> *Associativity of |(|* 
> <https://hackage-content.haskell.org/package/base-4.22.0.0/docs/GHC-Num.html#v:-42->|)|*
>     |(x * y) * z| = |x * (y * z)|
> *||fromInteger 
> <https://hackage-content.haskell.org/package/base-4.22.0.0/docs/GHC-Num.html#v:fromInteger>| 
> 1| is the multiplicative identity*
>     |x * fromInteger 1| = |x| and |fromInteger 1 * x| = |x|
> *Distributivity of |(|* 
> <https://hackage-content.haskell.org/package/base-4.22.0.0/docs/GHC-Num.html#v:-42->|)| 
> with respect to |(|+ 
> <https://hackage-content.haskell.org/package/base-4.22.0.0/docs/GHC-Num.html#v:-43->|)|*
>     |a * (b + c)| = |(a * b) + (a * c)| and |(b + c) * a| = |(b * a) +
>     (c * a)|
> *Coherence with |toInteger|*
>     if the type also implements |Integral
>     <https://hackage-content.haskell.org/package/base-4.22.0.0/docs/GHC-Real.html#v:Integral>|,
>     then |fromInteger
>     <https://hackage-content.haskell.org/package/base-4.22.0.0/docs/GHC-Num.html#v:fromInteger>|
>     is a left inverse for |toInteger
>     <https://hackage-content.haskell.org/package/ghc-internal-9.1401.0/docs/GHC-Internal-Real.html#v:toInteger>|,
>     i.e. |fromInteger (toInteger i) == i|
>
> Note that it /isn't/ customarily expected that a type instance of both 
> |Num 
> <https://hackage-content.haskell.org/package/base-4.22.0.0/docs/GHC-Num.html#t:Num>| 
> and |Ord 
> <https://hackage-content.haskell.org/package/base-4.22.0.0/docs/Data-Ord.html#t:Ord>| 
> implement an ordered ring. Indeed, in |base| only |Integer 
> <https://hackage-content.haskell.org/package/base-4.22.0.0/docs/Prelude.html#t:Integer>| 
> and |Rational 
> <https://hackage-content.haskell.org/package/base-4.22.0.0/docs/Data-Ratio.html#v:Rational>| 
> do.
>




> One of the implicit design question here is "are these the interfaces that allow operator overloading?" or "are these the interfaces that declare various algebraic properties?"
>
> Since many of the numerical types of possible interest are closer to, say, floating-point-like types that have few algebraic properties rather than integer-like types that have more, I don't want to preclude floating-point-like types from participating in operator overloading because of their lack of strong algebraic properties. Matrices/vectors would also fall closer to floating-point-like rather than integer-like and I would not want to preclude matrices/vectors from benefiting from operators.
>
> I included a slide in my 2025 JVMLS talk on numerics speculating that a future refinement of these kinds of interfaces could include an idiom to indicate "yes, this type actually obeys the ring axioms" or "... the field axioms", etc., but that is not included in this early "lumpy" iteration.
>
> I would fully expect some evolution of the set of interfaces, what methods go where, the set of interfaces, etc. as we can more experience using these trial types with type classes.
>
> Thanks.
>
> -------------
>
> PR Review Comment:https://git.openjdk.org/valhalla/pull/1917#discussion_r2700497372
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20260117/5b6e4288/attachment-0001.htm>