4 ms·

I think probably C is a better fit for the kind of things you're doing. Or is it the other way around? The reference implementation for JPEG is in C, and ease o

I think probably C is a better fit for the kind of things you're doing. Or is it the other way around? The reference implementation for JPEG is in C, and ease of implementation in C was probably a significant criterion for this and other standards. I tend to see lots of structs, bit-packing, and bitwise operations that don't make as much sense in APL. I wouldn't say that addition modulo specific powers of two is inherently "practical" or "mathematical", it's just what a CPU provides. APL's not interested. That said, Rosetta Code has many examples of common algorithms in J, an APL relative. I looked up Huffman Coding there and found a link[0] to an implementation that looks okay. But J's likely to stumble on some JPEG-specific details, and you won't get C-level performance with this sort of code. [0] https://code.jsoftware.com/wiki/Essays/Huffman_Coding https://code.jsoftware.com/wiki/Essays/Huffman_Coding

abainbridge 5y ago
Excellent link to the Huffman example. I think it will take me a lot of study to grok it. I'll consider investing that effort. > I tend to see lots of structs, bit-packing, and bitwise operations that don't make as much sense in APL. That's why I mentioned "performance matters". Those things are common in algorithms where performance matters. If APL isn't interested, then it isn't good for most algorithmic work. Those operations aren't some quirk of current CPU architecture. It is less work in our universe to do bit shifts than multiplies. And bit packing reduces storage and IO, which also saves work at a fundamental level. The same operations are used in FPGA/ASIC designs where the architecture is much more free. Maybe quantum or analogue computers would change that picture a little but that's not what APL is for. I'd say the main use for a symbolic thought notation is when working on performance critical stuff. If performance isn't critical then I use a simple algorithm and a simple implementation. Higher level system design stuff is usually better done as diagrams than symbolic notation. I guess when working on a large codebase I'm using the structure of the symbolic programming language to help me think about how distant parts of the code interact. But that doesn't sound like something APL would be good at either.

abainbridge 5y ago

Excellent link to the Huffman example. I think it will take me a lot of study to grok it. I'll consider investing that effort. > I tend to see lots of structs, bit-packing, and bitwise operations that don't make as much sense in APL. That's why I mentioned "performance matters". Those things are common in algorithms where performance matters. If APL isn't interested, then it isn't good for most algorithmic work. Those operations aren't some quirk of current CPU architecture. It is less work in our universe to do bit shifts than multiplies. And bit packing reduces storage and IO, which also saves work at a fundamental level. The same operations are used in FPGA/ASIC designs where the architecture is much more free. Maybe quantum or analogue computers would change that picture a little but that's not what APL is for. I'd say the main use for a symbolic thought notation is when working on performance critical stuff. If performance isn't critical then I use a simple algorithm and a simple implementation. Higher level system design stuff is usually better done as diagrams than symbolic notation. I guess when working on a large codebase I'm using the structure of the symbolic programming language to help me think about how distant parts of the code interact. But that doesn't sound like something APL would be good at either.