Sender | Message | Time |
---|---|---|
14 May 2022 | ||
14:10:35 | ||
14:10:40 | ||
16:50:26 | ||
23:24:48 | ||
23:46:30 | ||
23:46:34 | ||
15 May 2022 | ||
Apparently OCaML multicore has an ability to limit the consequence of data races with formally proved properties. https://github.com/snu-sf/promising-ldrf-coq | 02:57:22 | |
* Apparently OCaml multicore has an ability to limit the consequence of data races with formally proved properties. https://github.com/snu-sf/promising-ldrf-coq | 02:57:48 | |
This is referenced in the memory models section here: https://kcsrk.info/slides/mcocaml_gallium.pdf , and it's apparently been launched in 5.0 https://github.com/ocaml-multicore/ocaml-multicore | 03:00:46 | |
OCaml is really something. | 13:09:08 | |
16:31:04 | ||
Is there a conjunction B , such that x uBv y ←→ (u x) v yIn other words, reverse-hook | 20:44:11 | |
In another form: (v~ u)~ | 20:52:17 | |
There is not a primitive that is built for that, but aside from reversing the order of u and v, you have already defined one. You can declare it tacitly in J903. | 21:35:18 | |
Okay, thanks! | 21:38:42 | |
16 May 2022 | ||
06:18:31 | ||
11:16:49 | ||
15:04:09 | ||
17 May 2022 | ||
14:24:18 | ||
17:30:17 | ||
New here and to Array languages. Going thru J primer, watching tangentstorm videos and also found the ngn/k tutorial 3 days ago. | 17:45:24 | |
jpf thank u | 19:26:09 | |
19:30:44 | ||
Download unknown.png | 20:30:16 | |
Interested in perspectives on boxing efficacy. The chart above shows boxed / unboxed space utilization, per the gist below. Boxing seems to use 30-70x as much memory on my machine, which makes boxes infeasible for even moderate amounts of data. For example, reading a 1GB CSV file fails entirely, as each element is boxed in the default implementation. https://gist.github.com/interregna/ad3ea2a33412c2daa4048020ecc007d1 | 20:30:16 | |
Makes sense | 22:15:45 | |
The advice that I have heard is to stay away from boxing whenever possible and when you do need to use it, make sure that you are boxing and boxing as little as possible. So when you unbox then perform a sequence of operations before you box again, rather than boxing and then unboxing between each operation. | 22:27:04 | |
* The advice that I have heard is to stay away from boxing whenever possible and when you do need to use it, make sure that you are boxing and unboxing as little as possible. So when you unbox then perform a sequence of operations before you box again, rather than boxing and then unboxing between each operation. | 22:27:29 | |
I think this fundamentally conflicts with the use of strings that aren't the same length, unfortunately. | 22:49:26 | |
Well you could just save them as strings that would be padded with blanks or the character of your choice to fill. You can't get around the extra spaces, but perhaps if you were able to sort longer strings together on input then the padding would be minimized. I don't know if this would work for you, I am just tossing out ideas that I might try. | 22:55:06 |