Newest at the top
| 2025-03-26 12:30:21 +0100 | alp | (~alp@2001:861:8ca0:4940:dd1f:b4e6:4fbb:e5d8) |
| 2025-03-26 12:29:29 +0100 | <tomsmeding> | Athas: section 3.1 of the FunMem paper is very unsurprising to me, so I guess that's a good thing |
| 2025-03-26 12:29:24 +0100 | xff0x | (~xff0x@2405:6580:b080:900:6185:acb4:363b:5fd3) (Ping timeout: 260 seconds) |
| 2025-03-26 12:28:49 +0100 | ash3en | (~Thunderbi@149.222.157.169) ash3en |
| 2025-03-26 12:26:05 +0100 | <tomsmeding> | and yes, these things have IsList instances, but that's cheating |
| 2025-03-26 12:25:17 +0100 | <tomsmeding> | I think you get the point. :) |
| 2025-03-26 12:25:08 +0100 | <tomsmeding> | the (:$$) and ZSS are for shaped shapes, not for mixed shapes |
| 2025-03-26 12:24:56 +0100 | <tomsmeding> | er, `SKnown (SNat @3) :$% SUnknown 5 :$% SKnown (SNat @7) :$% ZSX` |
| 2025-03-26 12:24:37 +0100 | infinity0 | (~infinity0@pwned.gg) infinity0 |
| 2025-03-26 12:23:54 +0100 | <tomsmeding> | It works, technically. :P |
| 2025-03-26 12:23:39 +0100 | <tomsmeding> | you get `SKnown (SNat @3) :$$ SUnknown 5 :$$ SKnown (SNat @7) :$$ ZSS` as the shape of an array with type-level shape [Just 3, Nothing, Just 7] |
| 2025-03-26 12:22:59 +0100 | <tomsmeding> | but shape values (i.e. the return type of the function that returns the shape of an array) are type-indexed by the type-level shape/rank/etc. too, and a shape value indexed by a partially-unknown type-level shape is annoyingly verbose |
| 2025-03-26 12:21:52 +0100 | <tomsmeding> | perhaps, yes |
| 2025-03-26 12:21:35 +0100 | <Athas> | Many applications can probably divide the sizes into constants and unknown, with no great loss of safety. |
| 2025-03-26 12:21:15 +0100 | <Athas> | Well, selective unknown sizes seems like it would go a long way towards avoiding the awkward cases. |
| 2025-03-26 12:19:20 +0100 | <tomsmeding> | Futhark has quite the advantage of having custom syntax and a custom type system. :) |
| 2025-03-26 12:18:57 +0100 | <tomsmeding> | But this being embedded in haskell, it's clumsy and verbose all around |
| 2025-03-26 12:18:46 +0100 | <tomsmeding> | They can be used in user code too, of course; the idea there is that it sometimes makes sense to e.g. have a "batch dimension" in your computation that's any length, but then have the actual data dimensions be shape-typed because you're doing interesting things with them |
| 2025-03-26 12:17:52 +0100 | <tomsmeding> | the downside is that these nested arrays are not actually as flexible as you'd like: the whole thing still has to be rectangular, so it's not very different from a large multidimensional array. |
| 2025-03-26 12:17:20 +0100 | <Athas> | Mixed arrays sound interesting. Do they work out nicely in practice? |
| 2025-03-26 12:17:15 +0100 | <tomsmeding> | the goal of that was to support nested arrays too: essentially the trick that Data.Vector.Unboxed does, but then also give a `data instance` for nested arrays. If you nest ranked inside shaped, or the other way round, you end up having to represent the result using an array with mixed type information |
| 2025-03-26 12:17:09 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-03-26 12:16:08 +0100 | <tomsmeding> | ox-arrays, my thing on top of orthotope, supports ranked arrays, shaped arrays, _and_ mixed arrays (indexed by [Maybe Nat]): the natural generalisation of the two |
| 2025-03-26 12:16:01 +0100 | <Athas> | That's nice. I find fully shaped arrays a bit awkward in Haskell, but ranked should be a nice compromise. |
| 2025-03-26 12:15:28 +0100 | <tomsmeding> | I linked the ranked one |
| 2025-03-26 12:15:23 +0100 | <tomsmeding> | orthotope has three copies of the array API: one for ranked arrays (multi-dim. arrays indexed by their rank), one for shaped arrays (~ indexed by their shape, a type-level [Nat]), and one for dynamic arrays (not indexed) |
| 2025-03-26 12:14:57 +0100 | <Athas> | Oh wait, 'n' is the rank? |
| 2025-03-26 12:14:30 +0100 | <Athas> | tomsmeding: is 'n' a shape in the multidimensional case? |
| 2025-03-26 12:14:08 +0100 | <Athas> | I always suspected they'd work fine as a run-time structure for an array library, so I'm happy to see that is the case. |
| 2025-03-26 12:13:52 +0100 | <Athas> | If you're curious, section 3.1 in https://futhark-lang.org/publications/ifl22.pdf describes how LMADs work in Futhark. |
| 2025-03-26 12:13:30 +0100 | <tomsmeding> | yes; this is the data type that the user sees https://hackage.haskell.org/package/orthotope-0.1.7.0/docs/Data-Array-Internal-RankedS.html#t:Array |
| 2025-03-26 12:13:19 +0100 | <Athas> | Ah, I see, so it's just a question of factorisation. |
| 2025-03-26 12:13:10 +0100 | <tomsmeding> | Athas: the size of the array is also there, one data type higher up |
| 2025-03-26 12:13:02 +0100 | <tomsmeding> | Athas: horde-ad was originally built on orthotope directly, but it was rather crippled by the fact that orthotope is all-Haskell, and so the stuff that should be fast is actually disappointingly slow |
| 2025-03-26 12:12:57 +0100 | <Athas> | Actually, there is one difference. LMADs also contain the size of each dimension. How can you get away with not knowing the size of the array? |
| 2025-03-26 12:11:24 +0100 | <tomsmeding> | I see |
| 2025-03-26 12:11:20 +0100 | <Athas> | Statically when possible, dynamically when necessary. |
| 2025-03-26 12:11:06 +0100 | <tomsmeding> | oh so you're doing this dynamically too! I had no idea |
| 2025-03-26 12:10:56 +0100 | <tomsmeding> | right |
| 2025-03-26 12:10:47 +0100 | <Athas> | This means you can have a branch where one returns a row-major array and the other a column-major, without any copies being necessary. |
| 2025-03-26 12:10:44 +0100 | <Athas> | Yeah, lift out the components where they differ. |
| 2025-03-26 12:10:30 +0100 | <tomsmeding> | "anti-unify"? |
| 2025-03-26 12:10:09 +0100 | <Athas> | One particularly nice property of this representation is that you can anti-unify representations as long as they have the same rank. |
| 2025-03-26 12:09:46 +0100 | <haskellbridge> | <Man of Letters> oh yes, it rocks |
| 2025-03-26 12:09:37 +0100 | <tomsmeding> | I have some nice CPP-generated C code in ox-arrays too. :) |
| 2025-03-26 12:09:19 +0100 | <Athas> | Hello Man of Letters! |
| 2025-03-26 12:09:17 +0100 | <tomsmeding> | Athas: cool! |
| 2025-03-26 12:09:15 +0100 | <Athas> | We used to have a much more elaborate representation than this, but this LMAD/orthotope-strided turns out to be a lot of bang for the buck. |
| 2025-03-26 12:09:03 +0100 | haskellbridge | Man of Letters is Mikolaj |
| 2025-03-26 12:08:55 +0100 | <haskellbridge> | <Man of Letters> hello! |