Spire integration

[tixxit]

Hey, first off, great library. I'm one of the authors of Spire (w/ Erik Osheim @non). Looking over some of the type classes, we seem to be duplicating some work (wrt algebra type classes). Breeze has a much larger scope than Spire, so I was wondering if there was anything you'd like to see in Spire that'd let you replace breeze.math with Spire's type classes (checkout spire.algebra). A VectorSpace typeclass seems a minimum, but is there anything else?

If you all are amenable, I could try submitting a PR for a version of breeze that uses Spire's type classes where appropriate. If you aren't interested, than no worries, just le me know and I won't do the work :)

https://github.com/non/spire

[dlwh]

Thanks!

I think it's definitely a good idea. For basic types, it would be nice to see a Semiring[1] and a ClosedSemiring[2]. Then, basically everything in the VectorSpace hierarchy is necessary, including InnerProductSpace, CoordinateSpace and TensorSpace, and their mutable variants.

CoordinateSpace and TensorSpace don't correspond to anything in math that I know about. The former is basically for VectorSpaces with a finite basis (or countably infinite basis... so basically not function spaces), and the latter (which is not like what is actually called a Tensor Space) adds the ability to reduce all the elements with an arbitrary function. In practice, MutableCoordinateSpace covers

Another operation that would be useful is a scaleAdd/axpy operation. axpy(a: S, x: T, y: T) = a * x + y, with an in-place version for MutableVectorSpace. I've been meaning to add that...

I also don't know the right way to describe the relationship between a DenseVector and a DenseMatrix... Something to think on?

[1] https://github.com/dlwh/breeze/blob/master/math/src/main/scala/breeze/math/Semiring.scala
[2] Semiring + closure operator p* = \sum_0^\infty p^n. Probablity Semiring gives 1/(1-p). There's also KClosedSemirings, which have \sum_0^\infty p^n = \sum_0^K p^n for some K.

[tixxit]

Good to hear :) We have a Rig, which is just a Semiring and can add a closed variant. I'll dig into the other classes.

A couple of potential issues is that our Rig (and Ring, etc.) don't define equality, so we'd also be missing methods like "close." I also saw close defined in VectorSpace. I was thinking of perhaps adding a MetricSpace type class to Spire, which would have a way of getting a double approx. to distance (NormedVectorSpaces would get a MetricSpace implicitly). This could be used to define a close method on NormedVectorSpace, and for Rigs if an implicit ToDouble is also available.

Anyways, I'll be sure to have more questions as I go.

[dlwh]

Sounds great, thanks!

I've not heard Rig before. What's the mneumonic? I know a Rng is a Ring
without identity, but...

On Sat, Dec 1, 2012 at 9:48 PM, Tom Switzer notifications@github.comwrote:

Good to hear :) We have a Rig, which is just a Semiring and can add a
closed variant. I'll dig into the other classes.

A couple of potential issues is that our Rig (and Ring, etc.) don't define
equality, so we'd also be missing methods like "close." I also saw close
defined in VectorSpace. I was thinking of perhaps adding a MetricSpace type
class to Spire, which would have a way of getting a double approx. to
distance (NormedVectorSpaces would get a MetricSpace implicitly). This
could be used to define a close method on NormedVectorSpace, and for Rigs
if an implicit ToDouble is also available.

Anyways, I'll be sure to have more questions as I go.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/21#issuecomment-10926487.

[tixxit]

Ring without a 'n'egative :)

[jsalvatier]

I would like to mention that I would love to see these packages come together.

[dlwh]

It would definitely be nice to have. I don't think I can get to it any time particularly soon, but I won't get in the way!

[sirinath]

Also some level of interop and merger with AlgeBird would be great also along with Spier.

This will prevent fragmentation and have larger interop issues between libraries using AlgeBird and Breeze.

[dlwh]

Ok, I started looking into this, and a few things annoyed me to the point of giving up.

The big one is that Breeze currently wants to be able to easily find typeclass implicits like Semiring/Rig or Ring, especially for basic types like Double. We currently achieve that by putting implicit instances in the companion of the traits (like Semiring). Spire doesn't put its typeclasses in the companion, but instead in a package object. This means that, at use site to use a method like DenseMatrix.eye, the user has to have import spire.implicits, while currently in Breeze you don't need to import anything other than DenseMatrix.

(EDIT: The reason I care about this is that the compiler error that comes from failing to import spire.implicits._ is fairly uninformative, and I foresee users of Breeze who aren't super well-versed in abstract algebra getting upset because Breeze can't find a Rig instance for Double.)

@non, is there a particular reason for not putting typeclass instances in the companion objects? I would like to offload the algebraic hierarchy onto you, but this feels like a nonstarter (pun not intended) to me.

[tixxit]

The biggest reason for moving type classes to their own importable object was that it was a PITA. For instance, if we have a Ring[Int] in the Ring companion object, then Semiring[Int] doesn't exist. Not unless we create a duplicate there. Or we create a Ring -> Semiring implicit in Semiring's companion object. However, the latter method ended up creating many ambiguities. The current import approach adds 1 line of code and all the implicits work really well now.

[dlwh]

Ok, sure. I feel like I could turn that on its head and say it's only ~10
loc for the builtins per typeclass: just implicit val semiring_double :
Semiring[Double] = Ring[Double].

And then that saves an untold amount of confusion (and LOC) elsewhere. But
different strokes, I guess.

On Mon, Feb 3, 2014 at 5:47 AM, Tom Switzer notifications@github.comwrote:

The biggest reason for moving type classes to their own importable object
was that it was a PITA. For instance, if we have a Ring[Int] in the Ring
companion object, then Semiring[Int] doesn't exist. Not unless we create a
duplicate there. Or we create a Ring -> Semiring implicit in Semiring's
companion object. However, the latter method ended up creating many
ambiguities. The current import approach adds 1 line of code and all the
implicits work really well now.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/21#issuecomment-33955190
.

[patrickyuguo]

Any conclusion/update on this? The world is desperately waiting for these two brilliant library to be combined!

[Make42]

How is the combining going?

[dlwh]

it's not. someone needs to champion it. i don't have the capacity for it.

On Mon, Nov 14, 2016 at 4:44 AM, Make42 notifications@github.com wrote:

How is the combining going?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#21 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAloUmzOeaAxnF7s4prlOVJevwTSHoIks5q-FetgaJpZM4ASWbN
.

[dlwh]

(I'd be happy to provide guidance!)

On Mon, Nov 14, 2016 at 11:27 AM, David Hall david.lw.hall@gmail.com
wrote:

it's not. someone needs to champion it. i don't have the capacity for it.

On Mon, Nov 14, 2016 at 4:44 AM, Make42 notifications@github.com wrote:

How is the combining going?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#21 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAloUmzOeaAxnF7s4prlOVJevwTSHoIks5q-FetgaJpZM4ASWbN
.

[superbobry]

Hi @dlwh, do you think this is still worth doing? If yes, would you have the time to do it yourself or is it up for external contributions?

[dlwh]

It's a big change. I haven't really announced this yet, but I'm thinking of more or less cutting a 1.0 very soon and stopping major new development on that, and thinking through a major redesign 2.0 that would probably include better Spire integration. Whether or not I have actual time to implement a major redesign is another question.

…

On Mon, Dec 11, 2017 at 11:07 AM, Sergei Lebedev ***@***.***> wrote: Hi @dlwh <https://github.com/dlwh>, do you think this is still worth doing? If yes, would you have the time to do it yourself or is it up for external contributions? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#21 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAloQmH3cVn822imYfMSVjG4Z5arQf2ks5s_X1WgaJpZM4ASWbN> .