Newest at the top
| 2024-05-16 20:02:59 +0200 | polyphem | (~rod@p4fc2c1da.dip0.t-ipconnect.de) |
| 2024-05-16 20:00:18 +0200 | euphores | (~SASL_euph@user/euphores) |
| 2024-05-16 19:54:40 +0200 | euphores | (~SASL_euph@user/euphores) (Quit: Leaving.) |
| 2024-05-16 19:51:46 +0200 | jcarpenter2 | (~lol@2603:3016:1e01:b940:892b:2549:5c20:9c9b) |
| 2024-05-16 19:50:05 +0200 | ph88 | (~ph88@2a02:8109:9e26:c800:801e:36ad:9367:33b9) |
| 2024-05-16 19:46:28 +0200 | suvid | (~halloy981@103.144.93.164) (Remote host closed the connection) |
| 2024-05-16 19:45:15 +0200 | <suvid> | hi |
| 2024-05-16 19:45:09 +0200 | halloy9814 | suvid |
| 2024-05-16 19:44:48 +0200 | halloy9814 | (~halloy981@103.144.93.164) |
| 2024-05-16 19:43:19 +0200 | Guest13 | (~Guest13@cpc93370-hers8-2-0-cust590.6-3.cable.virginm.net) (Ping timeout: 250 seconds) |
| 2024-05-16 19:24:47 +0200 | billchenchina | (~billchenc@103.152.35.21) (Ping timeout: 256 seconds) |
| 2024-05-16 19:24:11 +0200 | <ski> | if you think the view pattern version is too clever, or obscure, then you probably shouldn't use it |
| 2024-05-16 19:23:42 +0200 | <ski> | .. you should use whichever version is clearer to you |
| 2024-05-16 19:23:32 +0200 | <ski> | well .. |
| 2024-05-16 19:23:23 +0200 | <Guest13> | its much cleaner like that |
| 2024-05-16 19:23:00 +0200 | <ski> | because i keep the recursive calls `fib (n-1) + fib (n-2)', rather than replacing them with array lookups `fibs ! (n-1) + fib ! (n-2)' |
| 2024-05-16 19:22:59 +0200 | <Guest13> | (y) thank you for the help! ill see if I can let you know how my solution goes, and maybe send it to this channel at some point |
| 2024-05-16 19:22:02 +0200 | <ski> | and also to easily be able to ignore the memoization when reading (when thinking about what it does, without concern for the memoization optimiztion) |
| 2024-05-16 19:21:23 +0200 | <ski> | it's more to clearly seee that you haven't accidentally introduced some bug change in the memoized version |
| 2024-05-16 19:20:49 +0200 | <ski> | well .. that too. but it's not that unclear for the more elaborated versions, either |
| 2024-05-16 19:20:28 +0200 | <ski> | but i localize the differences to a minimal numer of places |
| 2024-05-16 19:20:26 +0200 | <Guest13> | so it is clear where the memoization happens and where the recursion happens |
| 2024-05-16 19:20:08 +0200 | <ski> | no, not really |
| 2024-05-16 19:20:06 +0200 | <Guest13> | or separate the logic |
| 2024-05-16 19:19:54 +0200 | <Guest13> | so you can reuse the non memoized code? |
| 2024-05-16 19:16:41 +0200 | <ski> | but i suppose one reason i played around with view patterns here (or rather, a more complcated function, involving a two-dimensional array, for matching a pattern string inside a text string), was to try to keep the memoized code version as close as possible to the original, non-memoized code |
| 2024-05-16 19:16:12 +0200 | <Guest13> | now |
| 2024-05-16 19:16:11 +0200 | <Guest13> | I think I understand it fairly well know |
| 2024-05-16 19:16:01 +0200 | <Guest13> | I gotta go cook dinner, but I will let you know how the problem goes |
| 2024-05-16 19:14:58 +0200 | patrl | (~patrl@user/patrl) (Remote host closed the connection) |
| 2024-05-16 19:14:56 +0200 | <ski> | of course, there's nothing wrong with naming the intermediate array cache, as well |
| 2024-05-16 19:14:40 +0200 | <ski> | well .. it does look a bit neat |
| 2024-05-16 19:14:15 +0200 | <Guest13> | so defining it as f -> x = y is good |
| 2024-05-16 19:14:01 +0200 | <ski> | we only want to allocate an array on the initial/top call |
| 2024-05-16 19:13:58 +0200 | <Guest13> | ok I see |
| 2024-05-16 19:13:50 +0200 | <ski> | since this would call `memoArray' once for each recursive call, allocating a new array on each recursive call |
| 2024-05-16 19:13:35 +0200 | <Guest13> | because these are two different arrays |
| 2024-05-16 19:13:32 +0200 | <ski> | fib' = memoArray (0,n) fib |
| 2024-05-16 19:13:20 +0200 | <ski> | where |
| 2024-05-16 19:13:18 +0200 | <ski> | fib n = fib' (n-1) + fib' (n-2) |
| 2024-05-16 19:13:08 +0200 | <ski> | or |
| 2024-05-16 19:13:07 +0200 | <ski> | fib n = memoArray (0,n) fib (n-1) + memoArray (0,n) fib (n-2) |
| 2024-05-16 19:12:43 +0200 | <ski> | btw .. note that we should not use |
| 2024-05-16 19:12:28 +0200 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) |
| 2024-05-16 19:12:26 +0200 | ft | (~ft@p508db8fc.dip0.t-ipconnect.de) |
| 2024-05-16 19:12:03 +0200 | <ski> | so, `(!) . tabulate (0,n)' allocates a single array, and makes a new function that, when called, will indirect through this array before calling the original function |
| 2024-05-16 19:11:42 +0200 | <Guest13> | ok ok |
| 2024-05-16 19:11:30 +0200 | <ski> | `(!)' converts back from that array, to the function |
| 2024-05-16 19:11:19 +0200 | <ski> | `tabulate (0,n)' converts the function to an array that lists the results of the function, for each input in the range `(0,n)' |
| 2024-05-16 19:10:47 +0200 | <ski> | (and .. it might be unclear whether there'd be only a single call to `memoArray' here, or three separate calls) |