Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 31 2019 03:07
    SethTisue commented #219
  • Jan 30 2019 21:49
    keithschulze starred typelevel/algebra
  • Jan 30 2019 20:19

    larsrh on gh-pages

    updated site (compare)

  • Jan 30 2019 20:11

    larsrh on gh-pages

    updated site (compare)

  • Jan 30 2019 19:56

    larsrh on revert-216-docs

    (compare)

  • Jan 30 2019 19:56

    larsrh on master

    Revert "fix homepage (#216)" T… Merge pull request #220 from ty… (compare)

  • Jan 30 2019 19:56
    larsrh closed #220
  • Jan 30 2019 19:55
    larsrh commented #219
  • Jan 30 2019 19:55
    larsrh closed #219
  • Jan 30 2019 19:55

    larsrh on v1.0.1

    (compare)

  • Jan 30 2019 19:55

    larsrh on master

    Setting version to 1.0.1 Setting version to 1.0.2-SNAPSH… (compare)

  • Jan 30 2019 18:05

    larsrh on gh-pages

    updated site (compare)

  • Jan 30 2019 17:54

    johnynek on master

    build for 2.13.0-M5 (#223) * b… (compare)

  • Jan 30 2019 17:54
    johnynek closed #223
  • Jan 30 2019 16:41
    sungjk starred typelevel/algebra
  • Jan 30 2019 14:28
    erikerlandson commented #223
  • Jan 30 2019 13:58
    tusharbihani starred typelevel/algebra
  • Jan 30 2019 13:39
    larsrh commented #223
  • Jan 30 2019 13:37
    erikerlandson commented #223
  • Jan 30 2019 13:30
    larsrh commented #223
Denis Rosset
@denisrosset
Otherwise, just prepare the PR with stubs for the Lattice stuff, and I'll try to complete.
Thanks for helping! I'd like to move Spire to cats 1.0.0 as well!
Luka Jacobowitz
@LukaJCB
Okay, I guess my actual question is, should the MeetSemilatticeLaws inherit the SemilatticeLaws?
Luka Jacobowitz
@LukaJCB
And analogously the BoundedMeetSemiLatticeLaws from the BoundedSemilatticeLaws
Denis Rosset
@denisrosset
Not exactly
A semilattice is defined as a specialized semigroup, basically it's commutative and idempotent, i.e. x |+| y |+| y = x |+| y and x |+| x |+| y = x |+| y
A meet semilattice is completely equivalent to a semilattice, except that its operation is called "meet".
A join semilattice is completely equivalent to a semilattice, except that its operation is called "join".
A lattice is both a meet and join semilattice (that's why we define join and meet semilattices)
Think of it the same way as a ring: it has both an additive and multiplicative monoid inside, but they are not the same, so Ring[A] does not directly inherit from Monoid[A], but rather AdditiveMonoid[A] (or actually AdditiveGroup[A]), and MultiplicativeMonoid[A]
(the additive monoid in a ring is always commutative, and the multiplicative monoid can be commutative if it is a commutative ring; a field is actually a multiplicative group over nonzero elements, but you get the spirit)
So I suggest, for the tests, to write them in the same way for the semilattice stuff and the ring stuff
Luka Jacobowitz
@LukaJCB
Okay I might create a PR with the Lattice stuff, and then when we find the solution I can apply it to ring as well :+1:
Pascal GANAYE
@paganaye
merci @jeremyrsmith
Denis Rosset
@denisrosset
@LukaJCB Do you mind sharing your WIP? I will need to interface cats and spire in the same project, so I'd like to move in with the update!
Luka Jacobowitz
@LukaJCB
Yes sure, It’s not close to done yet though, unfortunately
Luka Jacobowitz
@LukaJCB
#206
Denis Rosset
@denisrosset
Cool, thanks!
Luka Jacobowitz
@LukaJCB
I’ll probably have some time to work on it on wednesday or thursday :+1:
Denis Rosset
@denisrosset
@LukaJCB I started as well to port the Spire tests to the new cats style, see https://github.com/non/spire/tree/experimental
(BTW, this branch is a melting pot of several PR that are waiting for a review, see the files IsEq.scala, AdditiveSemigroup* in spire-laws)
In particular, I'd like to have a test harness for primitive types, where the out-of-range behavior is undefined, and thus should not make tests fail
Denis Rosset
@denisrosset
@LukaJCB I've made quite a bit of progress, but not yet on the Lattice stuff (mostly rings)
Luka Jacobowitz
@LukaJCB
Awesome! Thanks for the great work!
Denis Rosset
@denisrosset
@LukaJCB For the ring hierarchy, I've removed the original abstraction (the base stuff, etc...) at the price of duplicating the laws for Group, AdditiveGroup and MultiplicativeGroup. In the end, the code is simpler and not much longer.
Luka Jacobowitz
@LukaJCB
Sounds great! Is there a way I can have a look?
Denis Rosset
@denisrosset
https://github.com/non/spire/tree/experimental in laws/src/main/scala/spire/laws
Martin Duhem
@Duhemm
Hey guys, we're moving to sbt 1.0 with Dotty, so I ported typelevel/algebra's build to sbt 1.0, because it's part of our community build. The changes are not big, but would you be interested in a PR? Here's the commit: dotty-staging/algebra@43cc85a
Luka Jacobowitz
@LukaJCB
Hey @denisrosset I’ve finished up the lattice law conversions
and would love to get your feedback before moving forward
Luka Jacobowitz
@LukaJCB
Or anyone else really :D
Denis Rosset
@denisrosset
@LukaJCB Am having a look now
I think you are missing the semigroup laws, for example associativity
Have a look here
On the other hand, I'm missing the distributive lattice stuff in Spire
(If you want to check the axioms, they are on Wikipedia. Anyway, it's a good idea to document where we pick the definitions.)
Luka Jacobowitz
@LukaJCB
I made it so that they all extend from Band so the laws should be tested there
Denis Rosset
@denisrosset
Ha! thanks, will check it out later
Denis Rosset
@denisrosset
I see, we diverge on the use of bases. I made the choice of using only parents in my version of the laws. Would be happy to discuss about it.
In my understanding, the new laws style of cats is extremely straightforward at the price of some boilerplate and repetition. This is why I dumped the bases-type encoding.
For example, in the lattice laws, I duplicated the laws for the meet operation and for the join operation; then a lattice laws is simply the union of all these. It's then very easy to move from the typeclass, to the laws trait, and follow the inheritance chain.
However, by using bases, the relevant laws cannot be found by looking at the law traits; you have to go to the discipline implementation, and understand how things work together, which imho defeats the purpose of the new style. Any thoughts?
NB: would be happy to move this discussion to the GitHub PR. Feel free to cut'n'paste stuff there.
Luka Jacobowitz
@LukaJCB
Interesting, I haven't put as much thought into it TBH
Denis Rosset
@denisrosset
Can you enlighten me on the motivations of moving from the old laws (basically, everything in Discipline rule sets), and the new style?
Because what I wrote is pure speculation after comparing the code before/after
Luka Jacobowitz
@LukaJCB
I'm sure someone from the cats side can give you a better answer
Luka Jacobowitz
@LukaJCB
Tbh mostly it was just so cats kernel had the same law encoding as cats core
Denis Rosset
@denisrosset
Oh I see