|
01:29
nine left
01:30
nine joined
01:40
hulk joined
01:41
kylese left
02:15
hulk left,
kylese joined
03:39
Aedil joined
03:43
guifa left
05:08
phogg left,
phogg joined
05:12
floyza joined
05:22
dg left
05:25
dg joined
05:30
Sgeo left
|
|||
| ab5tract | Grok output reads as super try-hard | 05:56 | |
| "Here's the spicy truth" ... seriously? why would anyone want a robot to write this way? | 05:57 | ||
| oh, it's "fun" mode, so at least the user asked for it | 06:00 | ||
|
06:30
floyza left
06:47
teatime left
07:16
teatime joined
|
|||
| teatime | huh, that's odd, where'd my irc go | 07:16 | |
| wrong channel | |||
|
09:08
MasterDuke left
09:37
sena_kun joined
10:01
sena_kun left
10:04
sena_kun joined,
sena_kun left
10:52
doomlord joined
|
|||
| doomlord | timo, antononcube: I came to the conclusion that we should reimplement shaped arrays around Bufs | 10:53 | |
| Maybe in module space | |||
| Either Buf or CArray | 10:56 | ||
|
10:56
doomlord left
11:00
doomlord joined
|
|||
| doomlord | I mean, now it’s implemented in MultiDimArray.c. And it doesn’t use strides | 11:02 | |
| Meaning that many optimizations are precluded | |||
| Im not sure if having it implemented in c gives significant performance boosts, if that is the case then one could modify the repr and the api to have strides in c | 11:04 | ||
| But my guess is that the Buf or CArray implementation would also be fast thanks to the jit compiler | 11:05 | ||
|
11:06
doomlord left
11:10
wayland76 joined
11:13
doomlord joined
11:20
doomlord left,
doomlord joined
11:21
guifa joined
11:24
doomlord left
11:25
doomlord joined
11:29
doomlord left
11:52
doomlord joined
11:54
doomlord left
11:55
doomlord joined
11:59
doomlord left
|
|||
| antononcube | @ab5tract It is an interesting question when I see LLMs with “fun modes” how exactly their fun modes operate. 90% I suspect it is just a global, “header” prompt change or augmentation. | 12:35 | |
| But sometimes it seems an LLM is deliberately trained to be “fun.” Alternatively, all LLMs are “fun”, but kind of ugly too (because are trained with “The Internet”). Hence, civil discourse conditioning global prompts are always needed. | 12:38 | ||
| @doomlord “Oh but that takes more mental effort than a reshape function for multidimensional arrays” — I tried to “fix” these kind of concerns in my DSL packages, and more concretely for data wrangling, with “DSL::English::DataQueryWorkflows”, raku.land/zef:antononcube/DSL::Eng...yWorkflows | 12:43 | ||
| It supports multiple stride styles. | |||
| I.e. specifications for array views. | |||
| A package Ecosystem question: | 13:15 | ||
| Before and during Milton 🌀 🌪️ passing here I was trying to track it using Raku functionalities. (It was, say, 1/3 to 1/2 successful endeavor.) One big obstacle, for me at least, was importing and parsing KML and KMZ files. So, what is the best approach for getting these packages? | |||
| *"these packages" = "these packaged functionalities". | |||
| 1) Making a dedicated package named, say, "Data::Geographics::KML" or just "Geo::KML". 2) Just using "Data::Importers" and making it to know how to deal with KML/KMZ files. 3) Extending an existing package with plugin, for example, the current "XML" with "XML::KML". | 13:18 | ||
| @grenzo Ingesting KMZ files is a perfect application of "IO-Archive". | 13:26 | ||
|
13:28
wayland76 left
13:31
wayland76 joined
14:34
wayland76 left
14:38
wayland76 joined
14:40
teatwo joined
14:43
teatime left
14:50
Sgeo joined
15:37
wayland joined,
wayland76 left
15:45
Aedil left
15:46
Aedil joined,
Aedil left
17:42
sena_kun joined
18:41
wayland76 joined
18:42
wayland left
20:13
wayland76 left
22:05
sena_kun left
22:19
sena_kun joined
22:26
sena_kun left
|
|||