| 9 Feb 2023 |
 doug-moen | We need to go higher. I will add my thoughts to the fast union brainstorming discussion you started on github, to start. I need to write an essay, matrix isn't the best for this. | 04:20:12 |
| doug-moen | * We need to go higher. I will add my thoughts to the fast union brainstorming discussion you started on github, to start. I need to write an essay, matrix isn't the best for this. https://github.com/curv3d/curv/discussions/169 | 05:19:57 |
|  fractorr joined the room. | 16:19:54 |
| fractorr joined the room. | 16:33:46 |
|  fractorr joined the room. | 16:47:45 |
| 10 Feb 2023 |
 Lee | Read it all, great stuff doug 👍️ | 15:41:26 |
| Lee | I really can only advocate for the simplest solutions - time, barrier of entry, etc are all things I really care about | 15:41:48 |
| Lee | The linear_union sounds like a great first step. | 15:42:22 |
| Lee | I would really love to avoid anything the involves a ton of upfront study. I think there's a lot of power and longevity in keeping it simple. | 15:52:41 |
| Lee | I think maybe our goals diverge a bit on this - I think you want to see curv as the be-all end-all tool which is completely fair, but I think it's a hard goal | 15:53:20 |
| Lee | (Maybe I'm completely wrong, which I'd like to be :D) | 15:53:42 |
| 11 Feb 2023 |
|  YagoF joined the room. | 21:28:53 |
| 12 Feb 2023 |
|  @volhard:monero.social joined the room. | 13:05:50 |
| @volhard:monero.social left the room. | 13:24:41 |
| 13 Feb 2023 |
| Lee | Going to peck at iterative_union today, see what needs to be done | 14:09:56 |
| Lee | I think visible usage of curv would attract more minds... | 14:16:29 |
| 14 Feb 2023 |
 hrgdavor | definitely, needs more ppl involved or it will stagnate, and many more to keep an active core base | 08:51:26 |
| hrgdavor | * definitely, needs more ppl involved or it will stagnate, and many more to keep an active core user base | 08:52:23 |
|  matt3o#0 changed their display name from matt3o to matt3o#1392. | 08:52:51 |
|  @garyalvarez:matrix.org joined the room. | 17:46:09 |
| Lee | So with my Internet out for almost 24h I had some nice quality time with curv's source. There's a few things that I saw that could stop us. One is re-assigned in SC compiler causes a segfault, i.e. do local r = 0; in for (i in 1..10) r := min shape.dist[x,y,z,t] r; | 18:14:36 |
| Lee | * So with my Internet out for almost 24h I had some nice quality time with curv's source. There's a few things that I saw that could stop us. One is re-assignment in SC compiler causes a segfault, i.e. do local r = 0; in for (i in 1..10) r := min shape.dist[x,y,z,t] r; | 18:14:46 |
| Lee | Another is the inability to pass in non-constants from outside the shape compiler | 18:15:14 |
| Lee | I think if we resolved these two issues, we could have iterative_union | 18:15:28 |
| Lee | While doing it I asked myself a lot, how would iterative_union be used? | 18:16:13 |
| Lee | You don't want to define many many shapes. You want to define one shape, and then a list of arguments that create many different variants of the shape with the loop | 18:16:43 |
| Lee | At the very top, you'd "normal" union these iterative_unions | 18:17:13 |
| Lee | which would just be r := min iterated_union_stuff my_model | 18:17:34 |
| Lee | I think in the end, curv needs to track some sort of "result" value, and allow arbitrary read and write to it. | 18:18:18 |
| Lee | I'll need more time to evaluate what to add or change. | 19:29:49 |
