|
Algorithms are a lot easier to solve if you can solve them visually.
Then walk yourself through the steps your brain takes to solve it.
For example, if I have to scan a list of items with my eyes in order to solve it, I'll need a for loop to enumerate the items in the code.
But sometimes I forget to "watch myself" and then I make my job a lot harder.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Is that normal? Do most coders think visually?
I always thought myself in the minority, never occurred to ask how others create algorithms.
|
|
|
|
|
Based on the dreck posted to Q&A here and on stack overflow, I'm pretty sure the average so called coder can't think beyond Ctrl+C Ctrl+V.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
I'm not sure. I do know that I'm weird, even among coders generally, but I'm not sure if that's one of the reasons why.
I think in kinda funny ways.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Actually, it's more a ball of goo. A (new) problem induces a feeling of what to do - usually (but not always) right. Maybe best described as running on instinct.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
I personally think that most coders think visually. If I cannot picture it in my head - it is time to start drawing. If it looks to complex, then diagram it to see why. If you cannot diagram it, then you do not understand it and should probably avoid modifying it.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence." - Edsger Dijkstra
"I have never been lost, but I will admit to being confused for several weeks. " - Daniel Boone
|
|
|
|
|
Anyone else write trap doors in their code or just me? Now and then I add alligators for some added protection, unless the client demands crocodile traps, which I never understand. They cost more due to salt water upkeep. Maybe clients see my tier pricing and just assume the highest priced is best.
|
|
|
|
|
I think visually. If I can visualize it, I can do it. I can visualize abstract things that you can't exactly draw a picture of.
|
|
|
|
|
I think visually in almost everything, not just coding. When reading directions or instructional texts I usually have to convert the words and concepts into pictures in my head before they make complete sense.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
|
I've often solved harder problems by not thinking about them. Leave the machine, go for a walk / ride, go shopping... I'll be wandering along [not thinking about the problem] and suddenly the answer just pop into my head. To often trying to solve while at the machine, seem to get stuck in a loop.
But I'll readily admit I'm forgetful, for instance can wander off to the shops to buy something, and about 3/4 way back realize I've got everything except the item I originally planned to get and really needed most. (But I'll probably have an answer to something else.) And anyway mundane simple things like shopping what wives are for isn't it? ... yeah, she don't read this group 
Message Signature
(Click to edit ->)
|
|
|
|
|
That sounds like me. And yeah, sometimes just do the dishes, or something. Wax on wax off, and the problems solve themselves in the background.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Lopatir wrote: I've often solved harder problems by not thinking about them. Leave the machine, go for a walk / ride
Same here. I go out for a run over lunch and by the time I get back, all those endorphins have rinsed away the brain cramps and I figure out the problem.
Or I'm a whole lot less frustrated and simply don't care, one of the two  .
Software Zen: delete this;
|
|
|
|
|
What about those nights that all your dreams are series of indirect attempt to solve the problem. Or you solve it in your dream and can't remember the answer when you wake up. 
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence." - Edsger Dijkstra
"I have never been lost, but I will admit to being confused for several weeks. " - Daniel Boone
|
|
|
|
|
I generally draw weird diagrams on a white board - thinking visually helps me a lot.
I used to work at a place where the room we two coders lived in had a special paint on the walls that turned them into whiteboard style surfaces. I loved just writing on the walls when I needed to.
A human being should be able to change a diaper, plan an invasion, butcher a hog, navigate a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects! - Lazarus Long
|
|
|
|
|
"Visual thinking" isn't unusual.
There is a story told about August Kekule, the chemist who discovered the benzene ring. At the time, all known hydrocarbons had a linear structure - a line of carbon atoms, with hydrogen atoms branching off. According to this, benzene should have been very reactive, but it wasn't.
One day, Kekule fell asleep in his carriage on the way to town, and dreamt that the carbon atoms were dancing in a circle. Waking up, he realised that this must be the answer - and it was!
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
One of the benefits of having been writing software since the 1980's the dawn of time is that you've solved most of the problems you see day-to-day any number of times. The 'design problem' therefore becomes one of recognizing the problem(s) to be solved and decomposing them in a fashion that makes sense. It becomes a lot easier to choose algorithms based on concerns other than "it's the only one I know how to implement". You can choose simple algorithms to make it easier to maintain. Some algorithm choices let you refactor and reuse existing code. Others might adhere to a standard you need.
It's fairly rare nowadays for me to sit down and consciously devise an algorithm. In fact, I think the last time I did that of any significant scope was my last article for CP.
Software Zen: delete this;
|
|
|
|
|
I've been coding since 1986 so i feel you.
I like to find unexplored problems though. The one that inspired this post was left factoring grammars.
as here Left Factoring[^]
Never done it before. The goal is to be able to programmatically modify a target grammar like the following so it can be parsed with an LL(1) parser. It must not be left recursive, and must not have two productions with the same starting right hand and left hand side such that A = B b | B c is illegal, and so is A = A a (but A = a A is fine)
Here's the target grammar - an EBNF describing its own syntax
grammar<start>=productions;
productions= productions production | production;
production=identifier ["<" attributes ">"] "=" expressions ";";
expressions= expressions "|" expression | expression;
symbol = literal | regex | identifier | "(" expressions ")" | "[" expressions "]";
expression = symbols;
symbols= symbol symbols |;
attributes= attributes "," attribute | attribute;
attribute= identifier ["=" attrval];
attrval= literal | integer | identifier;
literal = '"([^"\\]|\\[.])*"';
regex = '\'([^\'\\]|\\[.])*\'';
identifier= '[A-Z_a-z][\-0-9A-Z_a-z]*';
integer='\-?[0-9]+';
whitespace<hidden>= '[ \v\f\t\r\n]';
In the end I did it. This can parse itself using LL(1) after I feed it through my transformation algo
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Ok, but I've been paid as a programmer since 1973, so I've seen a lot of algorithm in a lot of languages.
Now we need an Esperanto for programminglanguages, but I'sguess that might be Pascal or Java or some such language that companies are willing to pay people to write in.
Unfortunately it might be Javascript and I fin that thought terrifying.
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
Much complexity is reduced visually and often by reversing the problem.
I had to come up with an algorithm to figure out whether certain failure modes on a switch-ring network (things used in satellites) still had a solution using spare amplifiers. We're talking trillions of switch combinations to analyze. (Scroll down to figure 4.29 to see a very very simple example.[^]
I discovered that when I looked at a switch ring network, I could easily identify failure points because the logic was simple: the switch has two inputs and two outputs (configurable, so inputs can also be outputs.) But the point was, if the switch was handling 3 inputs, that's fail. If the switch was handling 2 inputs and one of the output paths was known to route to a failed amplifier, that configuration was a fail.
Anyways, the other thing I realized was that I was thinking in terms of the mindset of signal flow, from inputs on the left to outputs on the right. But actually, it was much easier to work the problem from right-to-left, particularly given that the solution had to be found for failures on the output.
Ultimately, the problem reduced down to not even dealing with switch state, but simply whether the switch had inputs <= non-failed output paths.
Funny thing about that was, the algorithm could tell you whether a failure mode could be compensated for with spares, but I couldn't tell you what the switch states were to redirect to the spares! That turned out to be a separate algorithm.
Latest Article - A 4-Stack rPI Cluster with WiFi-Ethernet Bridging
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
Marc Clifton wrote: Funny thing about that was, the algorithm could tell you whether a failure mode could be compensated for with spares, but I couldn't tell you what the switch states were to redirect to the spares! That turned out to be a separate algorithm.
I had something similar happen to me recently creating LALR tables, which involves a lot intermediary tables and the like, including (get this) an intermediary state machine, you just walk it and then throw it away!
So I had a lot of different ways to traverse a lot of different structures in the end, and I wound up with some overlapping algorithms, but it couldn't easily be helped.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Sometimes it helps me to draw stuff on paper.
|
|
|
|
|
I primarily rely on interpretive bag dance.
But it is the case that sometimes I find myself too lazy to actually get up and find a piece of paper and I try to just bull my way through a problem, where it would probably save me some time if I did a bit of drawing. I find this particularly the case in recursive algorithms where I can get myself lost in my head in terms of keeping up with what the info is at each recursion, and dealing with special case 'prime the pump' issues on the initial entry.
Also, I will commonly 'write' the thing in the header comments, and refine that a number of times before actually writing any code, because having to write out what I think that I think that I'm thinking makes me actually think what I think I'm thinking. But, sometimes that backfires because I miss things that show up in the practical application that my 'in a perfect world' comments version didn't get me to, and that changes the nature of the thing substantially in terms of actual implementation.
Explorans limites defectum
|
|
|
|
|
I probably should, but the last time I wrote out a problem was the 1990s.
It stopped getting useful for me, as I started being able to just take notes directly in code.
LOL
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
When I saw the subject of your post, I thought you were going to reference some Buddhist wisdom I could apply to coding. 
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
