Jump to content

View more

Image of the Day

WIP title screen for #DeathOfAPartisan #screenshotsaturday #gamedev https://t.co/qJNhfZCvd4
IOTD | Top Screenshots

The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

Sign up now

Visualizing and writing algorithms

4: Adsense

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 Ahmed Egyptian   Members   


Posted 27 March 2013 - 06:22 AM

Hi All,

I have figured out a problem that I have. I've been developing software for number of years but most of the software I did was just Input/output. No algorithms are involved.

I know for example how binarysearch works, like it divides the array in two, then search left or right and that optimizes the searching.

When I try to write the code off my head, I can't. Even for insertion sorts, things like a[j+1] = a[j], in general playing with arrays or these things, I can't visualize or write them off my head. I don't know why, I didn't CS, but I'm EE :/.

How can I be better in writing algorithms :/ or at least understand the code in my head and visualize it

#2 NightCreature83   Members   


Posted 27 March 2013 - 06:30 AM

When I was learning these algortihms during my CS classes I always draw out the array and use arrows on the elements to see what's going on, and this is really hard to do in ascii.


For the insertion sort case the wikipedia article has a really good graphic about what it does.

Worked on titles: CMR:DiRT2, DiRT 3, DiRT: Showdown, GRID 2, theHunter, theHunter: Primal, Mad Max

#3 irreversible   Members   


Posted 27 March 2013 - 07:06 AM

For me it's usually an iterative approach. I start simple and keep adding on components I get a full map (in my head or on paper).


Visualization comes with practice and to be honest the sentence "I can't visualize or write them off my head" doesn't make much sense. If you're working with simple stuff, then try to always get a picture of code flow in your head. If you have anything slightly involved, use pen and paper! It's the fastest and most flexible way. Sure, you'll end up drawing up examples for specific datasets in the beginning and spend some time making them look intelligible, but in the end it'll help you create a map in your head.


Visualization is a skill you can develop. If you "can't do" it, then you simply need to "do it" more. Sooner or later you'll start seeing patterns. If you want to be a painter, you need to first start painting :).

#4 AgPF6   Members   


Posted 27 March 2013 - 09:17 AM

I would imagine that most architects and drafters can't imagine the entire building they are creating either.  But that doesn't stop them from doing it.


Try to remember that programming is really a translation of an idea into machine language.  The first thing i try to do is imagine and write down what it is i want to do:


I want to have a box that rotates.


then I try to imagine and write down the steps that are involved:


Intialize a window

intialize a system to draw objects

create a cube

draw the cube


I then break down each step into more involved parts.  The pattern here is to start with a simple idea and progressivly make it more detailed, before you wirte a single peice of code.


The more pedesign you do the easier it is to write your code.  I cannot emphasize this point enough.  Great buildings are designed before they are built, and are not trial and errors.  Architects don't stand at the site and direct where to put each support, only to change their mind if it doesn't work.  If you write code by trial and error, your systems will be small and trivial. But if you can learn to design your code before you start to program, you soon realize that you debug less, create more intersting and thoughtful programs, and it will be less stressful and more fun.


BTW, people who write code using one letter variables write code that is usually hard to read, difficult to debug, and probably took a long time to write.  Try using more meangingful names when designing your code.  It will make debugging less difficult, it communicates to the human much easier, and is easier to read by more people. 

#5 incertia   Members   


Posted 27 March 2013 - 08:32 PM

If it's an algorithm that you're trying to implement, I would suggest going over it with pencil and paper first. For example, with bubble sort, you just keep iterating and seeing how things get bubbled around and eventually you'll figure out how to turn it into code. This is also how I managed to figure out an efficient algorithm for converting an infix expression into postfix or prefix, and how I mastered Dijkstra's algorithm. It's hard to see how an algorithm really works without actually some sort of visualization, and for the most part, pencil and paper is going to be the best you can get.

#6 warnexus   Prime Members   


Posted 27 March 2013 - 11:13 PM

I highly recommend drawing what you want your code to do on paper. Then trace through to see if it has problems. Then compile it. If there is a bug, find out where the bug lies and fix it.


I've been programming for 2 years and I am still learning new ways of coding algorithms and fixing bugs.


If you see it in front of you, I would say it is definitely quicker to stop the issue.

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.