|
|
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.
|
|
|
|
|
Here you go. I wouldn't want to disappoint. It's not buddhist, but close enough for your purposes, I think. =)
The Tao of Programming[^]
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.
|
|
|
|
|
Close enough to get me to the next level, perhaps. Thanks!
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
also your tagline is ace. But also try writing any sort of complicated state machine without it, even in C# =)
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.
|
|
|
|
|
Don Norman: I wrote the book on user-friendly design. What I see today horrifies me.
The world is designed against the elderly, writes Don Norman, 83-year-old author of the industry bible Design of Everyday Things and a former Apple VP.
Don Norman on how design fails older consumers[^]
Don Norman via article: Take the screen design for Apple’s phones. The designers at Apple apparently believe that text is ugly, so it should either be eliminated entirely or made as invisible as possible. Bruce Tognazzini and I, both former employees of Apple, wrote a long article on Apple’s usability sins ,which has been read by hundreds of thousands of people. Once Apple products could be used without ever reading a manual. Today, Apple’s products violate all the fundamental rules of design for understanding and usability, many of which Tognazzini and I had helped develop. As a result, even a manual is not enough: all the arbitrary gestures that control tablets, phones, and computers have to be memorized. Everything has to be memorized.
Quote: Everyone needs better design
Do not think that thoughtful design is just for the elderly, or the sick, or the disabled. In the field of design, this is called “inclusive design” for a reason: It helps everyone.
Curb cuts were meant to help people who had trouble walking, but it helps anyone wheeling things: carts, baby carriages, suitcases. Closed captions are used in noisy bars. As Kat Holmes points out in her book Mismatch, all of us are disabled now and then. Some of us have permanent disabilities, but all of us have suffered from situational and temporary problems. When outside in the sun, the text message that just arrived is unreadable: wouldn’t it be nice if the display, whether cellphone, watch, or tablet, could switch to large, higher contrast lettering? Are elderly people handicapped? Maybe, but so is a young, athletic parent while carrying a baby on one arm and a bag of groceries in the other (and perhaps trying to open their car door). Ride-share bicycles and scooters cannot be used by people who need to carry bulky packages. Everyone has difficulty hearing people in noisy environments. Noise-canceling headphones are for everyone, not just the elderly. Almost anything that will help the elderly population will end up helping everyone.
modified 10-May-19 9:08am.
|
|
|
|
|
Can't argue with any of that.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Preach it, brother/sister!
When I was first starting with WPF, I heard about Expression Blend. I downloaded and installed it. The app was completely unusable. Monochrome icons and gray text on a darker gray background. I couldn't see anything in the app. Switching themes did no good, as they all had the same low contrast "oh, don't have anything distract from the work" design. I complained on Microsoft Connect about the app's usability. They closed and deleted my issue immediately with no response.
And I only used the phrase "age-ist pricks" once.
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: They closed and deleted my issue immediately with no response.
That's interesting because that's the 7th level of pain/annoyance that these kinds of frustrating issues create: you can't even report the issue because they just close them since it cannot be true that their design is terrible.
|
|
|
|
|
I don't bother reporting issues to Microsoft any longer. Every time I have they've either responded with a form response ("did you try rebooting?"  ), or closed the issue with no comment. My experience has been that they treat most developers with nothing but contempt.
Software Zen: delete this;
|
|
|
|
|
I agree with you. Not sure why they have that attitude about it but that's the same experience I've had in reporting issues to them.
I've reported a couple of real bugs with Visual Studio a couple of times and provided details and screen shots so they can reproduce and they just post back, "not a bug" and close or even delete the issue. The one I had reported was reported by a large number of users and they closed it anyways.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
