Re: [dev] a suckless computer algebra system

On Fri, Nov 20, 2009 at 3:20 PM, Jukka Ruohonen <jruohonen_AT_iki.fi> wrote:
> On Fri, Nov 20, 2009 at 02:57:24PM +0000, David Tweed wrote:
>> I was pointing out more how the simple-minded software metrics would
>> condemn you to around about the level of performance acheived by the
>> reference LAPACK (white bars) in the paper referenced, which to my
>> mind suggests there's a flaw in the software metrics. I'd also query
>> that the code quality is terrible in most numerical software: what I'd
>> say is that they've got a task to acheive (ie, using as much of the
>> computing power as possible) and make the software as simple and
>> maintainable as it can be given the task. (What they don't generally
>> do is say "if we reduce what portion of the task we'll implement for
>> users, we get wonderfully simple code".)
>
> I think there is no misunderstanding here; the "suckless metrics" do not
> apply here. But given that this is a suckless list, with the "terrible code
> quality" I meant that numerical software is often terrible against
> conventional metrics of code quality; cryptic, hard to read and understand,
> full of little "hacks", difficult to change and maintain, badly formatted,
> etc.
>
> Take the aspects of software quality mentioned in ISO 9126-1:
>
> * Functionality (suitability, accuracy, compliance, security, etc.)
> * Reliability (maturity, recoverability, fault tolerance, etc.)
> * Usability (learnability, understandability, operability, etc.)
> * Efficiency (time and space performance, etc.)
> * Maintainability (stability, analyzability, testability, etc.)
> * Portability (installability, replaceability, adaptability, etc.)
>
> Against these abstract concepts of general software quality, I'd say that
> numerical software is generally par excellence in some aspects, but terrible
> in others.

I think it's just a difference in when we'd use words like terrible.
It sounds like if code is difficult to read on some absolute scale
you'd call that terrible but say that it's justified in being terrible
in order to acheive efficiency. I'd rate difficulty of reading
relative to other ways of acheiving _exactly the same_ programming
goal (including efficiency level targets), so if there's not a simpler
way of programming it I'd rate that as having good readability. (Of
course, if there is a simpler way of coding to acheive the exact goal
then it has poor readability.) Likewise, portability is relative to
the goal: if the goal is to extract as much performance from the
particular processor the code is running on, then portability implies
different things than a portable implementation of "wc", etc, etc.
It's a difference in when we would use particular terms rather than a
real difference.

The other thing is that the only code I've looked at in depth is ATLAS
and Goto-BLAS, which both seem quite readable given their targets.
Mayber there's a corpus of much worse numerical code I just haven't
seen.

(In case it confused people, the comment in my original mail about
sending some people on this list mad was more a comment on those
people's software values than a criticism of numerical code.)

-- 
cheers, dave tweed__________________________
computer vision reasearcher: david.tweed_AT_gmail.com
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot