Where should the type information be 175

On Tue, 05 Apr 2005 10:12:22 -0500, Herman Rubin

I've looked at J, briefly, but haven't used it. It didn't seem particularly mathematically friendly, as the lovely typographical operators of APL seemed to have been transliterated into a sort of ASCII by multi-character decoration.

IMO, the most mathematically friendly computer language is (easily) Matlab, a commercial product of the Mathworks Inc, but never-the-less nearly ubiquitous in the field of signal processing and engineering, and probably some of the sciences. It started out as an interpreter over LAPAC, just as IDL (which started out as a similar numerical library) now has an interpreter over the top.

These things work beautifully as long as you can express your problem at the vector level. They tend to bog down badly if you need to finesse something by doing point-by-point work inside for loops: the interpreted nature of the language gets you.

Matlab would almost certainly *not* be an answer to Herman's problems, though, because Herman is dealing with operations down in those inner loops, even below the level of sample-by-sample, becuase he's working with bit-strings. Terje gave some indication that the process could be speeded up by re-structuring it so that more of the work could be done in a "vector" way, but it didn't seem that Herman liked that idea.

There are many processors, now, where the default buttembler syntax is "algebraic", particularly DSP processors. That is, the add instruction is something like:

a0 = a1 + a2

This may look portable, (and I guess that it is a bit more portable than the usual ad-hoc mnemonic syntax), but it isn't really. It doesn't tell you that on a AT&T DSP32C or AD SHARC that the result will be a 40-bit extended precision float, or that on a TI C67xx (if its buttembler had such a syntax) that a0 wouldn't actually have the result in it for another four cycles.

One of the reasons that the TI can't have an algebraic syntax is that the registers aren't typed. You can apply an integer add, or a floating pont add, or a SIMD add to the same set of registers.

Addressing mode syntax and semantics is usually one of the biggest difference between processors, at the buttembler level. Particularly with DSPs, where there are lots of variations on the post-modify-circualr-buffer theme, and (usually) more than one physical address space to select.

Personally, I don't understand Herman's need for pretty, concise syntax. When I need the control of the whole machine that buttembler gives, I'm glad that every little operation takes up a line of code on its own. That way I can put a comment next to it to say what it's for, or why it needs a particular instruction variant. I know I'll have forgotten why, in six months. It also gives room for all of the architecture-specific oddness, like explicitly parallel operations, conditional end, rounding or saturation modes, etc.

Sometimes I like a language to let me operate at something like the "pseudo code" level. Python gets close to that. When I use python or Matlab, I'm in exploratory, "does this work at all" mode. I don't care how long it takes, because I'll only use it a few times. Sometimes, though, I hate it when the compiler-language gets even the slightest bit creative (like ignoring the float cast, mentioned in a previous article). I doubt that these are reconcilable positions, and the fact that some languages (like C++) attempt to operate at both extremes must drive their designers nuts. The difference between "user friendly" and "user inimical" depends on both the problem and the user: languages don't stand a chance.

-- Andrew