libera/#sicl - IRC Chatlog
Search
3:08:24
beach
Yesterday, due to better organization of the module that implements the package system, I split the existing system (which contained code for both the package system and for symbols) into two, one for symbols and one for the package system.
3:08:25
beach
Today is Monday, and Monday mornings are chaotic around here, but I will start imagining a test suite for the package system, since I now have an "extrinsic" version of it too.
3:14:42
beach
The package system is interesting for SICL in terms of metacircularity. I mean (in-package #:sicl-package) ... (defclass package...)
3:22:05
zephyr
beach i found your observation of practical vs theoretic great. i would add that the reason the theoreticians keep making this mistake is because practitioners would always rather practice than explain to a (stubborn) theoretician
3:22:33
zephyr
of course, the impatience of the practioner bites them in other ways, and it all evens out :-)
3:23:25
beach
Maybe so. But it works out well for the theoreticians. They get published and admired by their colleagues. I don't think they care whether what they do is practically useful. They leave that aspect to others.
3:27:54
beach
Either way, I have a bit more than 6 month until I retire, so I don't have to deal with them anymore. :)
3:40:29
beach
I once saw a presentation by a mathematician colleague who aspired to become part of our group doing analysis and synthesis of sound, and he explained a way to do frequency analysis using linear algebra.
3:40:33
beach
After several blackboards of matrix manipulations, he made an assumption about eigenvalues that he then said was an assumption about the phases of the partials being statistically independent.
3:40:41
beach
But then I pointed out to him that for most sounds we deal with, the phases are in lockstep. Only for some instruments, like piano, are the phases independent.
3:40:42
beach
He had made this assumption so that he could solve the equations that came up, but without considering the practical implications.
7:21:55
hayley
I am a bit fed up with my naive arrangement adaptation code generator, so I am writing a better one with the original algorithm I had planned.
7:22:16
MichaelRaskin
beach: you are actually describing the _better_ case. I can see solving a simplified case to get understanding what's going on. But then they try to add effects to get closer to practical cases, and oh how their idea of «closer to practice» goes in the wrong direction.
7:22:24
hayley
Would it be possible to spill the current value of RSP to the stack, then use that as a temporary while performing stack-to-stack copies, then restore RSP?
7:25:27
hayley
("that" being RSP rather) If I could use RSP, then it would be unnecessary to find an unused register or spill a register, as otherwise RSP is not going to be used. And I don't think anyone is looking for the value of RSP during an adaptation.
7:31:41
beach
MichaelRaskin: It is fine with me to have them solve their theoretical approximations and get published for it. But it is not fine with me when they then claim to have solved the practical problem, and lament the practitioners for being stupid enough not to use their beautiful solutions.
7:33:06
beach
hayley: How about not allocating some register, say RAX, at all and use it as a scratch register.
7:34:44
hayley
beach: I'm pretty sure it is not too hard to spill a register for adaptation. So that shouldn't be necessary.
7:45:01
MichaelRaskin
beach: reality: they solve the approximation, and a solution of more practically interesting approximation is too annoying to sell because it is not enough improvement over theoretical status quo.
7:45:28
MichaelRaskin
(_then_ optionally act surprised practitioners don't use the theoretical solutions)