Newest at the top
| 2025-12-03 22:51:27 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 22:49:12 +0100 | <EvanR> | also answers what fromInteger does |
| 2025-12-03 22:48:54 +0100 | <EvanR> | by producing nonsense when you mess up |
| 2025-12-03 22:48:39 +0100 | <EvanR> | now it's not partial and fails on you just like untyped languages |
| 2025-12-03 22:47:57 +0100 | <EvanR> | compute the answers lazily, fits any finite use case |
| 2025-12-03 22:47:38 +0100 | <EvanR> | to simplify the "untyped matrix" thing, make it an infinite grid with cell 0 0 at the center |
| 2025-12-03 22:44:51 +0100 | <EvanR> | xD |
| 2025-12-03 22:44:45 +0100 | <EvanR> | it's the first choice in the list |
| 2025-12-03 22:43:57 +0100 | <tomsmeding> | that makes only slightly less sense than a 1x1 matrix |
| 2025-12-03 22:43:44 +0100 | <EvanR> | tomsmeding, a zero by zero matrix |
| 2025-12-03 22:43:25 +0100 | <tomsmeding> | (which is ameliorated by binary operations auto-broadcasting their operands when one of their dimensions has size 1) |
| 2025-12-03 22:42:36 +0100 | <tomsmeding> | this instance returns a 1x1 matrix in fromInteger, which is about the best you can do |
| 2025-12-03 22:42:25 +0100 | <tomsmeding> | https://hackage.haskell.org/package/hmatrix-0.20.2/docs/src/Numeric.Matrix.html#line-48 |
| 2025-12-03 22:42:09 +0100 | takuan | (~takuan@d8D86B9E9.access.telenet.be) (Remote host closed the connection) |
| 2025-12-03 22:40:47 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2025-12-03 22:40:32 +0100 | dhil | (~dhil@5.151.29.137) (Ping timeout: 240 seconds) |
| 2025-12-03 22:40:27 +0100 | ljdarj1 | ljdarj |
| 2025-12-03 22:40:27 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 252 seconds) |
| 2025-12-03 22:40:11 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-12-03 22:39:58 +0100 | <tomsmeding> | (yes, if the dimensions are in the type all is fine) |
| 2025-12-03 22:39:28 +0100 | <tomsmeding> | I'd say an untyped matrix type with (+) and (*) makes some amount of sense, even if the operations are necessarily partial. I have not even a partial definition to give for fromInteger |
| 2025-12-03 22:38:58 +0100 | <tomsmeding> | less! |
| 2025-12-03 22:38:51 +0100 | <Leary> | tomsmeding: Yep, hence "makes as much sense as your `Num`." |
| 2025-12-03 22:38:50 +0100 | <haskellbridge> | <lucabtz> What if you want a Monoid neither of those? |
| 2025-12-03 22:38:40 +0100 | <tomsmeding> | I can't even suffice with a partial fromInteger -- well, one that is defined as `error` is possible, yes |
| 2025-12-03 22:38:27 +0100 | <monochrom> | Yeah, a phantom type that specifies the binary operator. |
| 2025-12-03 22:38:25 +0100 | <tomsmeding> | Leary: well, the other operations are partial. |
| 2025-12-03 22:38:02 +0100 | <tomsmeding> | and (+) :: Semigroup Sum a => a -> a -> a |
| 2025-12-03 22:37:57 +0100 | <Leary> | tomsmeding: Square matrices of a /given dimension/ will be. If that dimension is in your type, fine. If it isn't, your other operations are screwed too. |
| 2025-12-03 22:37:47 +0100 | <tomsmeding> | monochrom: where the first parameter is a phantom parameter? |
| 2025-12-03 22:37:26 +0100 | <haskellbridge> | <lucabtz> And AdditiveGroup = Group + |
| 2025-12-03 22:37:15 +0100 | <monochrom> | "instance Semigroup Sum Int", "instance Semigroup Product Int". |
| 2025-12-03 22:37:13 +0100 | <haskellbridge> | <lucabtz> Yeah it's the same as I'm saying where Additive = Monoid + |
| 2025-12-03 22:37:00 +0100 | <tomsmeding> | you need exactly the same number of instance declarations and constraints, though |
| 2025-12-03 22:36:47 +0100 | <tomsmeding> | I guess it floods the namespace less |
| 2025-12-03 22:36:32 +0100 | <tomsmeding> | monochrom: how does that help? |
| 2025-12-03 22:36:17 +0100 | <monochrom> | I would do this. Semigroup takes one more type param, it specifies the operator. Likewise for Monoid and Group. Then you just have 3 type classes, and they cover +, negate, *, recip, and, or, ... |
| 2025-12-03 22:36:14 +0100 | <tomsmeding> | (there's probably a way to make precise exactly what it is) |
| 2025-12-03 22:35:49 +0100 | <tomsmeding> | Leary: my answer would be: no, it's some kind of indexed ring. It's morally a ring, kind of, but it isn't in the strict sense, and bye goes your unique fromInteger |
| 2025-12-03 22:35:38 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-03 22:34:58 +0100 | <tomsmeding> | lucabtz: I was talking about the declarations rather than the user side. But yes, the user side is even worse -- fortunately mostly addressed by synonyms, as you say |
| 2025-12-03 22:34:52 +0100 | <haskellbridge> | <lucabtz> Num would become something like AdditiveGroup & MultiplicativeGroup & FromInteger etc. |
| 2025-12-03 22:34:12 +0100 | <tomsmeding> | Leary: do matrices form a ring? |
| 2025-12-03 22:34:10 +0100 | <haskellbridge> | <lucabtz> tomsmeding that could be fixed by having an alias for a set of constraints |
| 2025-12-03 22:33:31 +0100 | <Leary> | The good reason to separate `fromInteger` is to allow literals when you don't have a ring. When you do, you always have a unique homomorphism from `Integer`, so `fromInteger` makes as much sense as your `Num` instance. |
| 2025-12-03 22:33:10 +0100 | <tomsmeding> | it would be most flexible if it was all split out, yes, though then you do get that you have to give 6 instance declarations to get anywhere for a number-like thing |
| 2025-12-03 22:32:13 +0100 | <haskellbridge> | <lucabtz> Yeah there should be Additive with just + and Multiplicative with just *, no inverses either I think |
| 2025-12-03 22:31:53 +0100 | <tomsmeding> | a six-by-seven matrix, it has been decided |
| 2025-12-03 22:31:42 +0100 | <Rembane> | Six, seven! |
| 2025-12-03 22:31:29 +0100 | <tomsmeding> | matrices can be Num just fine except that fromInteger makes no sense (what size to return?) |