Food for thought (Algorithm Complexity and R&D discoveries)
-
Complex algorithms? 1000 c/c++ lines? My last 'Hello World' took that many!
Opacity, the new Transparency.
Hmm, must have been in assembler on a Z80... Haha
"Make everything as simple as possible, but not simpler." -- Albert Einstein
-
Hmm, must have been in assembler on a Z80... Haha
"Make everything as simple as possible, but not simpler." -- Albert Einstein
-
I have to disagree with you completely. It's not a good read. The topic is interesting, his style could be better. When he gets to the meat, most of his readers have been drowned in vague blabber. He isn't clearly identifying what a "complex algorithm" is, and a paragraph title of "Complex algorithms are difficult" (well, duh!) doesn't help. Second, the point is not to create a complex algorithm. Rather, implementing an algorithm of given complexity in a way that it's provably correct, avoids all the pitfalls and still outperforms a dead pig. Frankly, your attitude towards complexity collides with your sig.
Personally, I love the idea that Raymond spends his nights posting bad regexs to mailing lists under the pseudonym of Jane Smith. He'd be like a super hero, only more nerdy and less useful. [Trevel]
| FoldWithUs! | sighist | µLaunch - program launcher for server core and hyper-v serverpeterchen wrote:
I have to disagree with you completely.
Okay cool, np. Sometime the write is not just attempting to write a technical assessment, you can clearly see that he has many degrees, I think that his intention is to provoke the reader to think about why developing complex algorithms is 'complex' work. And to show a short coming in the available tools and training of degree programs. It's kind of like the missing ingredient method. You put all the cards out on the table and you incite the subjects to make their own conclusions as to what cards are missing and why by describing the nature of the inherent problem. That was the effect it had on me, it made me question my preconceptions about algorithm complexity.
peterchen wrote:
He isn't clearly identifying what a "complex algorithm" is, and a paragraph title of "Complex algorithms are difficult" (well, duh!) doesn't help.
He has a PHD in CS, I think if he really wanted to write an article on Cyclomatic complexity[^] complexity he would have done just that. I think it's not the block of marble he is getting at but the methods of crafting a work of art and how the methods have not improved at the same rate at the builders chose their building medium.
peterchen wrote:
Frankly, your attitude towards complexity collides with your sig.
Hmm, I don't know, e=Mc^2 is okay until Einstein and Heisenberg had their little discussion on Quantum Mechanics, thus the Special Theory of Relativity and the new forms of relativity pertaining to different phenomena: STR Equations[^] So a single (simple equation) can not describe the 'unified theory' of relativity that Einstein was really looking for. Thus, as simple as possible, but no simpler.
"Make everything as simple as possible, but not simpler." -- Albert Einstein
-
Sadly, very few people pick that part up. Many of those people invoke Occam's Razor in the hopes that their "theory" will be given credibility. The same people should have invoked a psychiatrist... (No Dave, I'm not talking about you. :))
-- Kein Mitleid Für Die Mehrheit
Jörgen Sigvardsson wrote:
The same people should have invoked a psychiatrist...
Okay who needs the shrink, I know I need one! Geesh!
"Make everything as simple as possible, but not simpler." -- Albert Einstein
-
Dalek Dave wrote:
No, your right,
Is that grammatically correct? Shouldn't it be "you're right"? Just asking to know. :)
“Follow your bliss.” – Joseph Campbell
Dude, it's my right! ;)
-- Kein Mitleid Für Die Mehrheit
-
peterchen wrote:
I have to disagree with you completely.
Okay cool, np. Sometime the write is not just attempting to write a technical assessment, you can clearly see that he has many degrees, I think that his intention is to provoke the reader to think about why developing complex algorithms is 'complex' work. And to show a short coming in the available tools and training of degree programs. It's kind of like the missing ingredient method. You put all the cards out on the table and you incite the subjects to make their own conclusions as to what cards are missing and why by describing the nature of the inherent problem. That was the effect it had on me, it made me question my preconceptions about algorithm complexity.
peterchen wrote:
He isn't clearly identifying what a "complex algorithm" is, and a paragraph title of "Complex algorithms are difficult" (well, duh!) doesn't help.
He has a PHD in CS, I think if he really wanted to write an article on Cyclomatic complexity[^] complexity he would have done just that. I think it's not the block of marble he is getting at but the methods of crafting a work of art and how the methods have not improved at the same rate at the builders chose their building medium.
peterchen wrote:
Frankly, your attitude towards complexity collides with your sig.
Hmm, I don't know, e=Mc^2 is okay until Einstein and Heisenberg had their little discussion on Quantum Mechanics, thus the Special Theory of Relativity and the new forms of relativity pertaining to different phenomena: STR Equations[^] So a single (simple equation) can not describe the 'unified theory' of relativity that Einstein was really looking for. Thus, as simple as possible, but no simpler.
"Make everything as simple as possible, but not simpler." -- Albert Einstein
As you, I don't think the author discussed "cyclomatic complexity" as such - but he is very hazy, unfocused with the terms he uses. I don't get much more out of it than "lifting heavy objects - they are heavier than you think! Because it's amazing how heavy they are". Regarding the "missing card": If I understand the authors intention correctly, Robert Glass put it into one single sentence - which was the result of an actual study, not just musings: Fact 21 of 55[^]. Not to be misunderstood: I wasn't expecting a technical analysis. I think the author has a point, but unfortunately he's very bad at making it.
I still see a stark contrast between Einsteins demands for simplicity and your "complexity? Bring it on!" attitude which sounds a little bit on the arrogant side. Because what I learnt in my years as developer is this:: it is easy to solve a complex problem in a complex way, much much harder it is to solve a complex problem in a simple way. (exactly because you can't make it more simple than the minimum required to solve a problem).
Personally, I love the idea that Raymond spends his nights posting bad regexs to mailing lists under the pseudonym of Jane Smith. He'd be like a super hero, only more nerdy and less useful. [Trevel]
| FoldWithUs! | sighist | µLaunch - program launcher for server core and hyper-v server -
Point 1: Agreed! It's really not written that well - I think the guy has tried to be too Generic. Point 2: Agreed - with a small picky point. In this instance a 'complex' algorithm defines an algorithm of or beyond a given complexity (however what that level is, is not really clear!). So if you UNDERSTAND what you have modeled and proven and written it up in a logical and correct manner, your 'complex' algorithm shouldn't be that [i]complex[/i] to you or your target audience...
On Point 2 - let's assume there is a suitable measure of complexity. The problem is that this complexity is not alone, when you try to implement it you run into all kinds of other problems - e.g. memory footprint, performance, numerical limitations are complex issues by themselves that you have to solve, too. SOlving all of them requires a minimum of familiarity with the mathematical formalism, to be able to spell out equivalences, transform the problem, add validity checks etc. What i said is most software developers lack that kind of training - they are good enough on calculus, maybe they can do some linear algebra, but they usually suck at applied math. (I include myself in that - I've had a good chance to dabble in "real" math, but in practice I still suck at it. I regret that I didn't take this more serious)
Personally, I love the idea that Raymond spends his nights posting bad regexs to mailing lists under the pseudonym of Jane Smith. He'd be like a super hero, only more nerdy and less useful. [Trevel]
| FoldWithUs! | sighist | µLaunch - program launcher for server core and hyper-v server -
As you, I don't think the author discussed "cyclomatic complexity" as such - but he is very hazy, unfocused with the terms he uses. I don't get much more out of it than "lifting heavy objects - they are heavier than you think! Because it's amazing how heavy they are". Regarding the "missing card": If I understand the authors intention correctly, Robert Glass put it into one single sentence - which was the result of an actual study, not just musings: Fact 21 of 55[^]. Not to be misunderstood: I wasn't expecting a technical analysis. I think the author has a point, but unfortunately he's very bad at making it.
I still see a stark contrast between Einsteins demands for simplicity and your "complexity? Bring it on!" attitude which sounds a little bit on the arrogant side. Because what I learnt in my years as developer is this:: it is easy to solve a complex problem in a complex way, much much harder it is to solve a complex problem in a simple way. (exactly because you can't make it more simple than the minimum required to solve a problem).
Personally, I love the idea that Raymond spends his nights posting bad regexs to mailing lists under the pseudonym of Jane Smith. He'd be like a super hero, only more nerdy and less useful. [Trevel]
| FoldWithUs! | sighist | µLaunch - program launcher for server core and hyper-v serverpeterchen wrote:
I still see a stark contrast between Einsteins demands for simplicity and your "complexity? Bring it on!" attitude which sounds a little bit on the arrogant side. Because what I learnt in my years as developer is this:: it is easy to solve a complex problem in a complex way, much much harder it is to solve a complex problem in a simple way. (exactly because you can't make it more simple than the minimum required to solve a problem).
Sorry, I don't see my attitude as arrogant, I am just point out that even when simplicity in design has been discovered; IE. Relativity Theory, an unforeseeable event can occur which make a simple design become a complex design of individual components which all gravitate around a center point of interest. Surly 'Time Dilation Effect' can be explained using many different mathematical and algorithmic approaches, but it's discovery is usually not evident until the breakthrough of the principle 'Law' or 'Algorithm' has been discovered which in turn leads to other complexities in the original law. This is a feed-back effect. So while trying to arrive at a simple algorithm it may be found that other factors are adding to complexity which were originally out of scope for the application intended. Think about the simple transistors on a microchip, much of the chip is redundant because the of effects of quantum effects between layers in the sub straight. You never know it's happening but interference between instructions in the CPU causes problems that are usually filtered out using statistical methods built into the microchip. So yes the chip could be much smaller and faster, but the quality would be such that it would be unusable. :-\
"Make everything as simple as possible, but not simpler." -- Albert Einstein
-
Your right Rajesh* However, a lot of english speaking people do not care to do it right. (And I'm getting the feeling some americans don't even know how to do it right) *Place Sarcasm punctuation[^] here
-
On Point 2 - let's assume there is a suitable measure of complexity. The problem is that this complexity is not alone, when you try to implement it you run into all kinds of other problems - e.g. memory footprint, performance, numerical limitations are complex issues by themselves that you have to solve, too. SOlving all of them requires a minimum of familiarity with the mathematical formalism, to be able to spell out equivalences, transform the problem, add validity checks etc. What i said is most software developers lack that kind of training - they are good enough on calculus, maybe they can do some linear algebra, but they usually suck at applied math. (I include myself in that - I've had a good chance to dabble in "real" math, but in practice I still suck at it. I regret that I didn't take this more serious)
Personally, I love the idea that Raymond spends his nights posting bad regexs to mailing lists under the pseudonym of Jane Smith. He'd be like a super hero, only more nerdy and less useful. [Trevel]
| FoldWithUs! | sighist | µLaunch - program launcher for server core and hyper-v serverI agree completely - again, in my CS program (at least the path/electives that the Majority of ppl take across the Uni's that I've been exposed to) there isnt a real focus on those Highly Complex Algebraic questions, nor how they directly related to performance/limitations... In fact, the connections are rarely pointed out; you sort of are left to stumble across them yourself. Problem with that approach is, the kids straight out of high school, dont always make those connections (I'm a 'late bloomer', with a good few years experience under my belt, thankfully!)... I regret not getting more into Maths the first time I was at Uni (1994); all those years on the Mathematical sidelines since High School has again proven that Maths is a perishable skill. I LOVE Practical Discrete Maths, its awesome; but when it comes to Calculus and that high level maths knowledge (Proofs), I'm like most CS guys - its core, so we do what we have to do to get over the hurdle... It would have been nice to have done a Math Major or B.Math straight out of High School.