trying to simplify an algorithm

Bennett Todd bet at
Tue Mar 1 12:47:48 PST 2005

2005-03-01T19:59:23 Ian Molton:
> [...] my other points stand, however :)

I can see two other potential criticisms of that construct.

One is stylistic: some folks find it more obscure, less easy to
understand. I'd attribute this in part to programming background;
folks who have learned to really think in APL, or some other
strongly FP arithmetic-focused language find that style of
expression quite clear, and its compactness lends it a certain
simplicity to analyze and understand as well.

The other criticism regards optimization; it's certainly a fair
observation that one currently-popular compiler fails to optimize
it as well, at least for some architectures, as it can optimize
equivalent constructions using more typical coding style. One
response might be that this shows an opportunity to improve the
optimization of that compiler, not alone to empower it for this
programming style, but also for potential payoff in handling complex
arithmetic expressions in general.

But relative performance of arithmetic operations -vs- conditional
branches, in conjunction with more -vs- fewer instruction counts,
vary from architecture to architecture, and vary over time as well.

I liked it. I'm not sure I'd take that approach if I were coding up
something like this, but I dunno, any time problem structure leads
to one or more lines for each of the most elementary sub-clauses of
the problem statement, I find the resulting code dissatisfying, I
don't _like_ verbose code, where screenfulls of nested conditionals
are each doing an utterly trivial subset of the problem, and the
code ends up being many times longer than a reasonable and clear
statement of what it's supposed to accomplish.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <>

More information about the lfs-chat mailing list