Twisol
Joined 16 years ago
Joined 16 years ago
I also drilled on a drag-n-drop kana table [1] in a few ways -- sometimes I'd start from the kana and try to figure out where they should go in the table, and sometimes I'd go along rows or columns in the table and try to find the kana that belong there. These two directions drill both recognition and recollection.
Proper pronunciation is a cross-cutting concern. As a whole, it's not something you can reasonably learn solely from kana, but the aspects that are relevant are not difficult to pick up. Every kana breaks into one (vowels and N) or two (the rest) phonemes, and for the most part, the way you pronounce those phonemes is consistent across rows and columns of the table (admitting exceptions like "shi" and "tsu"). If you are taught those basics, learning how to pronounce kana is not hard. Training your ear to "hear" distinctions among English allophones, and to distinguish pitch accent from the more familiar stress accent, is much harder, and really has to come from experience, not just kana.
[0]: https://realkana.com/hiragana, wow it's improved since I last used it
However, translation is an affine transformation, which is a particular case of a projective transformation [0]. It turns out that we can represent 3D affine (and general projective) transformations using a 4x4 matrix -- that is, as linear transformations in one dimension up, in a similar sense as how we can represent complex numbers as particular 2x2 matrices [1]. So yes, projective geometry is the right theoretical lens, even if we're usually able to forget about it (somewhat) when we use matrix representations.
[0]: https://en.wikipedia.org/wiki/Affine_transformation#Represen...
[1]: https://en.wikipedia.org/wiki/Complex_number#Matrix_represen...
I agree so much with this. It's why I feel so stifled when an e.g. product manager tries to insulate and isolate me from the people who I'm trying to serve -- you (or a collective of yous) need to have access to both expertise in the domain you're serving, and expertise in the method of service, in order to develop an appropriate and satisfactory solution. Unnecessary games of telephone make it much harder for anyone to build an internal theory of the domain, which is absolutely essential for applying your engineering skills appropriately.
Olivier Danvy's "Rational Reconstruction of the SECD Machine" [0] explores the idea of this transformation as well, but frames it as a relationship between operational and denotational semantics:
> This deconstruction–reconstruction is actually interesting in itself because it provides a bridge between small-step operational semantics (in the form of an abstract machine) and denotational semantics (in the form of a compositional evaluation function)
His work on (de/re)functionalization is super interesting.
Lots of things that are "just" libraries could also reasonably be thought of as eDSLs.
I'm sure several MUDs did this, but, this sounds an awful lot like my home MUD of Achaea, which started in ~1997, still exists (healthily!), and has this exact system :)
Currently a graduate student at UC Santa Cruz; previously worked at Caltech's Jet Propulsion Laboratory (JPL) on mission planning+simulation software.
Blog: https://www.jonathan.com/
Twitter: https://twitter.com/Twisol
GitHub: https://github.com/Twisol
Email: twisolar <at> gmail (please don't come selling any services; otherwise, please let me know you found me via HN or something, because cold calls are confusing enough)
[ my public key: https://keybase.io/twisol; my proof: https://keybase.io/twisol/sigs/t3hJmOxbrWLW5PpKNS3nbtl1bOYx5bSTwF75FHAW6Hw ]