These are chat archives for non/algebra

8th
Feb 2015
Erik Osheim
@non
Feb 08 2015 01:12
btw, would love feedback on non/algebra#44
Avi Bryant
@avibryant
Feb 08 2015 03:44
@non can you explain what you're saying about Semigroup[Option[A]] and orElse?
Erik Osheim
@non
Feb 08 2015 03:49
ok, so for any type A, i can construct a Semigroup[Option[A]] whose combine is associative
namely def combine(x: Option[A], y: Option[A]): Option[A] = x orElse y
what i mean is -- that is often not what people want, but sometimes it might be.
Avi Bryant
@avibryant
Feb 08 2015 03:51
got it. Yeah I don't much like that as a default.
Erik Osheim
@non
Feb 08 2015 03:51
no it's a terrible default! :P
i just wanted to bring up the fact that i wasn't sure if we wanted to include it as a possibility.
similarly, we currently use the map-as-vector interpretation for Map[K, V] when defining Eq[Map[K, V]]
but you could imagine also providing a stricter instance.
which requires exactly the same keys with exactly the same values, but which doesn't need a Monoid[V] for zeros
(i mean map-as-sparse-vector)
Avi Bryant
@avibryant
Feb 08 2015 03:53
the lack of that stricter instance has been a common bug I've seen with algebird
or rather
the fact that because Map() is equal to Map(someKey -> zero)
you sometimes get the former when you expect the latter
causes bugs all the time.
(algebird aggravates this by explicitly converting to the former as the canonical form when it can)
Erik Osheim
@non
Feb 08 2015 03:54
do you think we should default to the strict instance and have an import to get the sparse instance instead?
Avi Bryant
@avibryant
Feb 08 2015 03:54
I do, yeah
IMHO.
Erik Osheim
@non
Feb 08 2015 03:55
when i created the std module i was imagining these as just being primarily for testing or defaults. but if we expect folks to use them in anger (which is the new understanding i have) then obviously we need to be careful about this.
ok great.
Avi Bryant
@avibryant
Feb 08 2015 03:56
re that particular combine for Option... you could equally have y orElse x... and of course it could exist without the Option, too... I think of this as a FirstSemigroup and a LastSemigroup
Erik Osheim
@non
Feb 08 2015 03:57
@avibryant right.
Avi Bryant
@avibryant
Feb 08 2015 03:57
I don't know if they belong in std or not but they are totally reasonable instances to have somewhere
Erik Osheim
@non
Feb 08 2015 03:57
interestingly, the reason they are on my mind is that Cats has a concept of universal monoids (MonoidK[F])
the idea there being that if you have MonoidK[F] you can combine F[A] values for any A
Avi Bryant
@avibryant
Feb 08 2015 03:58
without needing a Semigroup[A]
Erik Osheim
@non
Feb 08 2015 03:58
right.
which happen to be able to be specialized to Monoid[Option[A]] for particular A types.
anyway, maybe the whole issue is a bit of a digression.
i am torn between wanting to hurry up and release a milestone since Cats depends on Algebra, and also to slow down and think hard about this stuff.
Avi Bryant
@avibryant
Feb 08 2015 04:01
I think a release that has very few std instances is fine
as long as the traits are right
Tom Switzer
@tixxit
Feb 08 2015 21:30
@non +1 for strict by default
I think we have that in Spire too - where you must explicitly import vectorEq or vectorOrder to get the Map() == Map(k -> zero) behaviour
both ways can cause some confusion, but I think strict-by-default is less surprising (though perhaps means some laws must explicitly use a different order)
Erik Osheim
@non
Feb 08 2015 21:32
right.
ok yeah that's great. i'll update that PR then.
Tom Switzer
@tixxit
Feb 08 2015 21:33
also - quick question - do you know of any tradeoffs to using package object x extends XInstances vs object x extends XInstances?
package objects always seem to be slightly more nuanced, so wondering if we should make them plain objects
Erik Osheim
@non
Feb 08 2015 21:34
it's possible?
Avi Bryant
@avibryant
Feb 08 2015 22:41
I know people are always suspicious of package objects but I don't have any good reasons why
I think on balance I'd prefer using them
Tom Switzer
@tixxit
Feb 08 2015 22:46
They have, in the past, caused some unnecessary recompilation (Spire hit this issue before)
but I don’t think we’d hit that w/ the way they are used here
Tom Switzer
@tixxit
Feb 08 2015 23:12
@non once that PR is merged, I think I’ll make a PR removing the NRoot/Is* type classes, then we can add the BigDecimal instances in
Sound OK?
Erik Osheim
@non
Feb 08 2015 23:17
@tixxit perfect
@tixxit how do you feel about non/algebra#44 ?
anything you need to see before signing off?
(i'm guessing maybe the vector -> strict change?)
Tom Switzer
@tixxit
Feb 08 2015 23:20
yeah - aside from that it’s looking pretty good
also, I think I had some GCD tests in Spire… not sure if it is worth copying them over
the Double/Float stuff is pretty bit-mangly; I’m not sure how well it’d survive a refactor
though of course they now require NumberTag - so :\
Erik Osheim
@non
Feb 08 2015 23:24
mmm yeah
Tom Switzer
@tixxit
Feb 08 2015 23:25
I can write some more Float/Double specific tests for it instead - I do find myself having some free time now :)
also - can hopefully fix up the miniboxing stuff
Erik Osheim
@non
Feb 08 2015 23:25
hahaha :smile: :cry:
Tom Switzer
@tixxit
Feb 08 2015 23:27
mostly :)
Erik Osheim
@non
Feb 08 2015 23:27
yeah yeah :) it just never pays to seem too happy about someone else being unemployed even if it's great for them
Tom Switzer
@tixxit
Feb 08 2015 23:31
yeah, it is a pretty crappy situation on the whole, just doesn’t pay to dwell on the bad bits