IRC channel logs
2025-07-31.log
back to list of logs
<hadderly>How does transpose-array work? I understand that for a 2D matrix, it makes rows columns and vice versa. I also understand that for 3D+ arrays, they are reversed (ie 3x2x2 array becomes 2x2x3). However, I don't understand how the order is returned when DIM value positions are different (ie 2 0 1, etc. instead of 3 2 1) I also don't understand how the transpose of a 3D+ array to a lower dimension works. I haven't been able to find <lilyp>hadderly: the way to true understanding consists of fucking around and finding out <lilyp>the identity function is (transpose-array #n(…) 0 1 2 … n) <lilyp>from there you can find out variations, e.g. by exchanging two neighbour dimensions <lloda>hadderly`: maybe the explanation in the manual isn't the clearest, but it's pretty simple. The order of the arguments corresponds to the axes of the source array. The value of the arguments corresponds to the axes of the result array. <lloda>so in (define b (transpose-array a 2 0 1)) <lloda>and axis 2 of a is axis 1 of b <lloda>this way you can see that the reverse must be (transpose-array b 1 2 0) <lloda>fwiw numpy.transpose works the other way, which i suppose is a matlabism bc permute in matlab is the same <hadderly>lilyp: I have played around with different positions for DIM values before but couldn't make sense of the orders returned. I figured maybe it's because I'm not strong in math ("identity function" is a completely new term to me for instance), or it's because the procedure's description assumes a background in programming already. I'll look into what you said more and try playing around again to see if I understand better. <lilyp>identity function means it that the output is the same as the input <hadderly>lloda: That might help me make sense of the returned order better. I thought the order of the arguments corresponded to the source array's dimensions in reverse (ie DIM 1 was dimension 3 for a, DIM 2 was dimension 2 for a, and DIM 1 was dimension 3 for a). <hadderly>oops worded that last part wrong. meant DIM 1 was dimension 2 for a, DIM 2 was was dimension 1 for a, and DIM 3 was dimension 0 for a. <lloda>indeed it doesn't work like that <lloda>ArneBab: advantage is that you don't need to write the (let () ...) yourself when you have internal defines <lloda>re: optimization i think it isn't better or worse <lloda>hadderly: you also asked about transposing to lower dimension. That happens when some of the arguments are repeated, because then there are fewer destination axes, which are the values of the arguments <lloda>to pick up the example from earlier, if you do (define b (transpose-array a 0 1 0)) <lloda>axis 0 of a goes to axis 0 of b <lloda>axis 1 of a goes to axis 1 of b <lloda>axis 2 of a goes to axis 0 of b <lloda>so you see b only has two axes <lloda>the way this works is that when you move along axis 0 of b, you move along both axes of a at the same time <lloda>the simplest example of this is (transpose a 0 0) = the diagonal of a, if a is a matrix <hadderly>lloda: Yeah, I understand what the arguments mean and what they correspond to. It’s just that for 3D+, I am unable to transpose the array “by hand,” whether it’s to lower or same number of dimensions, so I don’t feel like I fully understand the procedure. But maybe I’ve gotten too in the weeds and it’s unnecessary to understand it this deeply. <ArneBab>lloda: ah, yes, supporting inline defines is a big advantage! Thank you! <dpk>is there any news on merging apteryx’s patch to fix R7RS library ‘include’? it’s bally annoying <dthompson>dpk: one thing I'd recommend is for apteryx to open a codeberg pull request for it. that will reduce friction for review. <dpk>is there a Codeberg repository for Guile now? <ArneBab>dpk: but my own patch has been lying there for two weeks already now. So I don’t think this is an infrastructure problem. <ArneBab>A difference is: on savannah I can push obviously correct fixes, on codeberg I can’t merge, so there’s one fewer person who can merge code. <dthompson>the codeberg switch hasn't fully gotten off the ground and there is still a lack of reviewers but it's much easier to review on codeberg <dthompson>this email thread is hard to follow with all the patch changes <ArneBab>I must admit that I still failed with setting up mumi <ArneBab>(I don’t want to push any of my own changes -- that’s for the reviewers -- just reduce the friction for obviously correct patches) <dthompson>it's possible that I could become a committer in the future, but it's not the case now. <ArneBab>I already sent an email asking for access to guile-devel, but didn’t get a response. So at the moment the switch to codeberg made our bottleneck worse. <dpk>yeah, if everyone with commit rights on the old platform wasn’t automatically given commit rights on the new one … then wtf <dthompson>there hasn't been a proper switch yet. I think there is a need for someone to migrate the open issues <dthompson>wingo is on vacation iirc so hopefully he can resolve this issue when he returns. or ludo when he's around. <ArneBab>so will a push to savannah be merged to codeberg automatically? If yes, I can check the patches by apteryx later/tomorrow (I already read most of them, just need to test them locally) and push them. <dthompson>I honestly don't know how that's being handled rn. I doubt it. <lloda>i don't think you need to wait on codeberg permissions to push patches to savannah that you wouldn't hesitate pushing if there was no codeberg.