These are chat archives for non/algebra

15th
Jan 2015
Avi Bryant
@avibryant
Jan 15 2015 22:01
huh, cool
Erik Osheim
@non
Jan 15 2015 22:11
yeah it's pretty neat.
the markdown/latex integration is nice, and it's cool that it pull things in from github
so far i've already met spire users who'd never spoken on the ML/IRC so i consider it a win.
(being able to give someone a link is really nice too.)
Miles Sabin
@milessabin
Jan 15 2015 22:15
+1
Same for shapeless.
Avi Bryant
@avibryant
Jan 15 2015 22:24
trait Bar {
   def foo[T:Monoid](bar: T) = ???
}
P. Oscar Boykin
@johnynek
Jan 15 2015 22:42
so I was looking at updating the Band pull request.
Then I realized, I could not think of a single example of a Band. Any ideas for something somewhat easy to implement that is idempotent and associative?
Erik Osheim
@non
Jan 15 2015 22:42
hm.
P. Oscar Boykin
@johnynek
Jan 15 2015 22:42
I thought of one:
matrices with frob norm <= 1
wait.
clearly not idem unless == 1
and (norm == 1) would not be closed under product.
I can't think of any then.
Erik Osheim
@non
Jan 15 2015 22:44
yeah me neither. that said, we can always test the band laws with a semilattice right?
until we think of one.
P. Oscar Boykin
@johnynek
Jan 15 2015 22:44
I guess, but should we add a construct defensively?
I'm worried about complexity.
Erik Osheim
@non
Jan 15 2015 22:45
right. it's not a bad idea that if we can't think of a std instance to test on, we shouldn't add something.
P. Oscar Boykin
@johnynek
Jan 15 2015 22:45
(i, j) \cdot (k, \ell) = (i, \ell) \,
Erik Osheim
@non
Jan 15 2015 22:45
(although we probably have some gaps to fill in if we want to be strict about that policy.)
P. Oscar Boykin
@johnynek
Jan 15 2015 22:45
I guess that is one.
(i, j) + (k, l) = (i, l)
not commutative, is associative and idempotent.
Erik Osheim
@non
Jan 15 2015 22:46
ohhh, interval addition might work
or sorry, interval union
P. Oscar Boykin
@johnynek
Jan 15 2015 22:46
is that not commutative?
Erik Osheim
@non
Jan 15 2015 22:46
oh you're right, it does commute.
P. Oscar Boykin
@johnynek
Jan 15 2015 22:46
I can take that example above...
Anyway... what do you see as needed before we do the Algebird/spire work?
Erik Osheim
@non
Jan 15 2015 22:48
so. obviously we need to get the @sp changes merged, and get bands added if we want them.
after that i would be fine with publishing a beta jar.
and then we could work on spire/algebird integration (which i'm certain will uncover issues).
P. Oscar Boykin
@johnynek
Jan 15 2015 22:48
ok. That semifield business? do we need that?
I had never heard of it.
Erik Osheim
@non
Jan 15 2015 22:48
wellllll. i'm not sure. yeah me neither.
my feeling is that it wouldn't disrupt the existing hierarchy to add it later.
P. Oscar Boykin
@johnynek
Jan 15 2015 22:49
does spire have an implementation of finite fields?
Erik Osheim
@non
Jan 15 2015 22:49
and your idea about magmas and properties might mean that it's not necessary immediately.
P. Oscar Boykin
@johnynek
Jan 15 2015 22:49
GF(9) or something...
Erik Osheim
@non
Jan 15 2015 22:49
i do have one i was working on, but nothing committed.
i wasn't sure if it belonged in spire or not.
P. Oscar Boykin
@johnynek
Jan 15 2015 22:50
the magma stuff seemed like it didn't get much traction.
Erik Osheim
@non
Jan 15 2015 22:50
i was feeling standoff-ish but maybe it's grown on me a bit
P. Oscar Boykin
@johnynek
Jan 15 2015 22:51
I really can't think of a use case, I was in "complete description of algebra" mode.
Erik Osheim
@non
Jan 15 2015 22:51
i would just need to test it out a bit, make sure (A with B) and (B with A) both work
i'll think about it, but i'm fine leaving it out too.
assuming i have example implementations of semifield structures i'm not opposed to adding them (in algebra.ring) but we can talk about that in a PR if we get one.
but i think we should publish a milestone or beta soon and try it out.
one final question: the std.Rat type is clearly a toy compared to spire.math.Rational. i'm a tiny bit worried folks might start "standardizing" on it.
am i just being paranoid?
P. Oscar Boykin
@johnynek
Jan 15 2015 22:54
you know, people are going to do their thing.
Erik Osheim
@non
Jan 15 2015 22:54
haha yeah
P. Oscar Boykin
@johnynek
Jan 15 2015 22:54
It is a legitimate concern, I suppose. I mean, you'll have two on the class path with spire.
but, the whole goal of all of this is to write functions that are abstract. When would you want Rational, but not something less concrete (Field, Ring, etc...)
Erik Osheim
@non
Jan 15 2015 22:56
agreed. algebra is for standardizing our notions about algebras not concrete types.
i think it will probably be fine.
P. Oscar Boykin
@johnynek
Jan 15 2015 22:56
but you could certainly move that into the test code if you like.
Erik Osheim
@non
Jan 15 2015 22:57
alright, well, i should get going. i think once that @sp PR is merged, i'll create a "milestone release" PR and email the list we have about it.
P. Oscar Boykin
@johnynek
Jan 15 2015 22:57
I don't think we have made it too clear what std is for, but I thought it was for implementations that are common and good.
(Like IntRing or something)
I can see adding the Map rings in there as well.
Erik Osheim
@non
Jan 15 2015 22:57
right. yeah that is probably the correct purpose.
i'll think about moving Rat to laws (or a new tests project)
anyway, once i've emailed the list if i don't hear any objections i'll publish a milestone.
and the testing can begin. then if i have a spire branch building against algebra, and you have an algebra branch, we can test some interop cases.
P. Oscar Boykin
@johnynek
Jan 15 2015 22:59
sounds good.
Erik Osheim
@non
Jan 15 2015 22:59
to me that is the defining thing i want to be sure we can do before a "real" release of algebra.
(^ meant algebird above, i think you got the idea)
P. Oscar Boykin
@johnynek
Jan 15 2015 23:01
cool, sir. Thanks for the hard work. Progress is happening.
Erik Osheim
@non
Jan 15 2015 23:05
yes!!!
thanks for your input. it's great having real mathematicians working on this stuff.