Newest at the top
| 2025-02-25 10:09:55 +0100 | <Athas> | Well, so there's another restriction I'm OK with: the input may be assumed to be isomorphic to a monomorphic sequence of scalars. Many AD libraries make that assumption. The Haskell type system is easily strong enough to make that nice to work with. |
| 2025-02-25 10:09:34 +0100 | <tomsmeding> | I was thinking of that Traversable constraint; that requires all the "input values" to really be exactly the same Haskell type |
| 2025-02-25 10:09:14 +0100 | <Athas> | Oh, I was considering only the types of the underlying scalars. |
| 2025-02-25 10:08:46 +0100 | <tomsmeding> | as is "arrays and scalars" |
| 2025-02-25 10:08:29 +0100 | <tomsmeding> | Athas: mind that having arrays of different ranks in the input is already "heterogeneously typed" |
| 2025-02-25 10:08:15 +0100 | <tomsmeding> | Athas: I tried, but the fact that the forward pass becomes a write to a vector with potential reallocation logic, instead of just allocating an object in the haskell nursery, increases the overhead quite a bit |
| 2025-02-25 10:08:09 +0100 | <Athas> | For example, they occur in none of the ADBench benchmarks. |
| 2025-02-25 10:07:50 +0100 | <Athas> | Heterogeneously typed active inputs are rare. |
| 2025-02-25 10:07:30 +0100 | <Athas> | The tape-based AD libraries in C++ are not slow at all. |
| 2025-02-25 10:07:19 +0100 | <tomsmeding> | Athas: some other component of the interface that is surprisingly tricky: 'ad' uses Traversable as the universal input structure, but if you have heterogeneously typed inputs, that doesn't really work any more |
| 2025-02-25 10:07:16 +0100 | <Athas> | Making the tape more efficient (by storing it in an unboxed and bump-allocated vector) would make a big difference to performance, I think. |
| 2025-02-25 10:06:57 +0100 | <Athas> | I would be OK with the API limiting primal values to types that can be unboxed (and also imposing some strictness requirements). |
| 2025-02-25 10:06:21 +0100 | <tomsmeding> | (though perhaps allocating fewer list nodes is doable) |
| 2025-02-25 10:05:57 +0100 | <tomsmeding> | as in, making them work but slow is easy (fromList . map f . toList), but making them fast is rather difficult |
| 2025-02-25 10:05:47 +0100 | <Athas> | Yes, I know, which is why I wouldn't expect them to work well, and I could sympathise with not having them at all. |
| 2025-02-25 10:05:28 +0100 | <tomsmeding> | Athas: Thanks! Second order operations are fundamentally more difficult to make work with the 'ad'-style algorithm than first-order bulk operations, though |
| 2025-02-25 10:03:21 +0100 | why | (~why@n218250229238.netvigator.com) |
| 2025-02-25 10:02:09 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2025-02-25 10:01:22 +0100 | <Athas> | Then the array type has a vocabulary of first order bulk operations (where I expect good performance for derivatives), and also some second order operations (like map) that should at least work. |
| 2025-02-25 10:01:07 +0100 | chele | (~chele@user/chele) chele |
| 2025-02-25 10:00:44 +0100 | <Athas> | tomsmeding: good question. I'm not terribly imaginatine when it comes to Haskell types, I must admit. I would probably like a type family 'Array sh t', where 'sh' is an Accelerate-like shape (this is not so important for 'ad'), and 't' is heavily constrained to either a some primal number type or dual/adjoint numbers. |
| 2025-02-25 10:00:01 +0100 | acidjnk | (~acidjnk@p200300d6e7283f38a15cd1ba33b15ba0.dip0.t-ipconnect.de) acidjnk |
| 2025-02-25 09:58:45 +0100 | tabaqui1 | (~root@87.200.129.102) tabaqui |
| 2025-02-25 09:58:41 +0100 | zungi | (~tory@user/andrewchawk) andrewchawk |
| 2025-02-25 09:57:50 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
| 2025-02-25 09:57:12 +0100 | zungi | (~tory@user/andrewchawk) (Ping timeout: 264 seconds) |
| 2025-02-25 09:52:36 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 272 seconds) |
| 2025-02-25 09:49:22 +0100 | <tomsmeding> | Athas: suppose I had a library inspired by Kmett's 'ad' library, but with first-class support for arrays somehow, instead of just scalars. (The goal being to significantly reduce the overhead of all those dual-number heap nodes.) What would you expect its interface to be? |
| 2025-02-25 09:49:08 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) Unicorn_Princess |
| 2025-02-25 09:47:37 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-25 09:47:01 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Quit: ash3en) |
| 2025-02-25 09:45:18 +0100 | zzz | yin |
| 2025-02-25 09:45:18 +0100 | yin | (~z@user/zero) (Read error: Connection reset by peer) |
| 2025-02-25 09:43:56 +0100 | tromp | (~textual@2a02:a210:cba:8500:6ddc:c1a9:bc13:1391) |
| 2025-02-25 09:43:32 +0100 | zzz | (~z@user/zero) zero |
| 2025-02-25 09:41:22 +0100 | misterfish | (~misterfis@h239071.upc-h.chello.nl) misterfish |
| 2025-02-25 09:30:57 +0100 | glguy | (glguy@libera/staff/glguy) (Read error: Connection reset by peer) |
| 2025-02-25 09:29:46 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
| 2025-02-25 09:29:28 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Remote host closed the connection) |
| 2025-02-25 09:28:06 +0100 | bitterx | (~bitterx@user/bitterx) bitterx |
| 2025-02-25 09:28:06 +0100 | bitterx | (~bitterx@APN-122-12-44-gprs.simobil.net) (Changing host) |
| 2025-02-25 09:27:56 +0100 | bitterx | (~bitterx@APN-122-12-44-gprs.simobil.net) |
| 2025-02-25 09:24:57 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-02-25 09:24:13 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-02-25 09:18:42 +0100 | alp | (~alp@2001:861:8ca0:4940:9bfe:6d72:595b:d191) |
| 2025-02-25 09:12:21 +0100 | eL_Bart0 | (eL_Bart0@dietunichtguten.org) |
| 2025-02-25 09:06:25 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-02-25 09:02:12 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-25 09:01:02 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2025-02-25 09:00:42 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |