On Monoids

[Quafadas]

I've been experimenting with the idea of Vectorised operations based on Spire's type class heirachy.

Evidently, this idea is not new - but it doesn't seem to have gained traction anywhere - here's one example I found;

spire/examples/src/main/scala/spire/example/kleene.scala

Line 142 in 4a70e3a

trait Matrix[A] { lhs =>

I've been struggling to get something coherent working (perhaps not surprisingly), but on the journey I've come to the point of questioning the cats Monoid. To focus in on something concrete, let's say that we want to implement an AdditiveMonoid under element wise addition for Array[Double]. Firstly, let's bring up the definition of Monoid.

a monoid is a set equipped with an associative binary operation and an identity element

The operation we get from Semigroup. No questions here.

It's the interplay between the Set and identity pieces which has brought me to the point of questioning the Monoid class.

My claim, is that as I asked for it above (AdditiveMonoid element wise for Array[Double] fits the type constraints of the cats Monoid - but), it actually ... isn't ... a valid monoid. The reason being, that I don't think there is a universal zero element. Under element wise addition, the zero for an array of length 1 would be Array(0) and the zero for an an Array length 2 would be Array(0,0).

However, if we tighten my question slightly

An AdditiveMonoid under element wise addition for Array[Double] for the set of arrays with length n

Then I think we do have a valid, implementable Monoid. I don't think it can be implemented with the current cats.kernel.Monoid, because the zero method has no way to gather information about (in this specific case) the length of the array (unless the array length is encoded in the type system which pushes a nasty series of problems from a library into userland (IMHO) and I wish to avoid).

I actually went off and implemented my own VectorisedMonoid out of a dogged sense of curiosity;
https://github.com/Quafadas/spire_AD/blob/24a92775e84d2531629dd3ffe279c317d05ced5e/spireAD/lawTests/src/vectorisedMonoid.scala#L72

And when I came to test it, I found this artefact, which is suggestive that all of these thoughts, have been thought before
https://github.com/typelevel/cats/blob/e72bb57cd2ae20852e126eb041e747d194d568eb/kernel-laws/shared/src/main/scala/cats/kernel/laws/MonoidLaws.scala#L48

One of my questions, is whether there is hive mind knowledge on why that empty(a: A) method was deprecated? I think it makes Monoid less general, in the sense that fewer monoids are implementable, but, in fairness, probably strictly reliable, in the sense that if you can implement your monoid in the type system, you can be very confident in it's behaviour.

My weird vectorised monoid, will misbehave at runtime if either the array lengths are different or 0. I think it's valid under those runtime constraints and it apparently passes the law tests when those constraints are imposed on the generation.

My other question is whether there is other prior Art here to study in terms of higher dimensional type class / Matrix libraries out there?

I'm going to probably carry on exploring this... although if I have made a mistake in the fundamental reasoning, I'd also love to know about it... if there is anyone out there actually reads these things