i've read this : "Read, read code, code"
Posted on 2001-05-15 10:37:00 by karim
I know this sounds like a joke, but I've discovered the following is the only way to learning problem solving, its also the method I sucessfully used to solve every problem I've come across to date. Stare blankly at the problem and kick yourself periodically until you solve it. When you solve it feel smugly superior while continuing to kick yourself for letting it take you so long to come up with a solution. Also, never read source code, never read someones elses solutuion, this should always be a final step you take when everything else fails. If you ever use someones else code in one of your programs you should never feel as if its your code, your work. Always be ashamed of it. Ok, I know alot of people will disagree with my last point preaching about the stupidy of reinventing the wheel, etc, but this is just my way and as far as I'm concerned its been extreemly sucessful to date.
Posted on 2001-05-15 15:39:00 by Zadkiel
80% read, 10% do

  80%
+ 10%
-----
  90%
I wonder, what those last 10 % are. Probably kicking yourself to make you think? Posted on 2001-05-15 16:48:00 by Stefan Krause
My coding style is one of convolution: I think of the problem and try to relate it to other things that I know - other processes. Usually, this is a visual thing for me. (ex. I see a MTF(Move-to-Front) algorithm as folding of the data.) This is my 'High-Level' analysis of code, and I can usually go from this type of thinking to any programming language that I know. On the 'Low-Level' side of things I do the same thing, but I draw pictures from several aspects: data flow, dependancies, etc. The simplest 'unit' of a problem has external/internal dependancies. You can look at a problem at any scale and you will see this 'unit'. In assembly we work with the smallest 'units' that the processor can use - instructions - every 'unit' has data and process. Therefor the data alone isn't a 'unit' - nothing needs to be done to it - the programmer is done. Life is process - you could think of a 'unit' as a cell/life/world/etc. (object I guess is a good word). The external dependancies are defined by what you want the program to do. The internal dependancies are defined by the choice of CPU/OS/APIs/Design choices/etc. From here you can build the software from top-down, and/or bottom-up. I tend to do top-down to easily understood chunks, then do bottom-up overlapping the other. The chunks could be whole programs or sub-routines or whatever (object I guess is a good word). I really think visually, and mathematically. I like breaking things into pieces until those pieces are solvable, and then I back-track a bit - integrating some of the pieces. Hope this helps somebody. :) I hate explaining my mind - it's easy for me to understand, but it doesn't lend itself to easy explaination with words. :) All of you are closer to understanding 'bitRAKE', maybe. :P This message was edited by bitRAKE, on 5/15/2001 9:00:00 PM
Posted on 2001-05-15 19:00:00 by bitRAKE
I have to agree with Zadkiel. Of course I call it "Banging my head againt the problem" I'd say try not to read other peoples source code at first. First I use what I call the "Figure it out for yourself stupid(tm)" method. Lets say some one wrote a libary to make your own games. A few invokes, mov some variables around and its finished. Did you write the game? Yes. Do you know how it all works? No. That dream program we all want to write is the sum-total of many small problems. I belive if you try to take care of the small problems yourself, in the long run you will be a better coder. If you just want to use other peoples code, what are you going to do when you can't find the code you want?
Posted on 2001-05-15 21:05:00 by asm_happy
Did you write the OS? Did you design the CPU/Monitor/Drives/Motherboard? No. We all choose what it is we want to accomplish, and what we want to understand. The level of understanding is a function of time and exposure. Using the code of others is also a learned skill, and some projects are beyond the ability of an individuals lifetime. I program in assembly because I realized there were concepts that couldn't be understood from a HLL. And conversely, there are concepts I'll never understand from where I'm at or going, and I count on the code of others to fill in the blanks. :) This message was edited by bitRAKE, on 5/15/2001 9:30:55 PM
Posted on 2001-05-15 21:16:00 by bitRAKE
disease_2000, what are the external dependancies of that environment? It looks like you have assumed that
DL=00
on entry to you algo? Have you seen Hugi Size Competition? I know this isn't a competition, but it helps to know where one is standing. Or, at least have a better grasp. I'm assuming that we are creating a DOS COM program, or is DOS the only assumption (then your code doesn't work in all cases.) This message was edited by bitRAKE, on 5/16/2001 5:27:25 PM
Posted on 2001-05-16 11:05:00 by bitRAKE
My coding style is very "planned", when I'm coding a program from scratch. First, I create a new folder & copy my template to it. Then I start writing the most important proc's, in which I use calls to procs I haven't even written yet. An advantage to working with a proc that doesn't exist is that you can change the specification and not have to rewrite it. All the pieces of code I'm not sure will work I mark with a ";(!!!)" and all pieces of code that are for debugging I mark with ";;". When I think I'm done, I compile it with my batch file that logs the 50+ error messages that tell me I've forgotten something to a text file. Then I code what's left, and I start debugging.
Posted on 2001-05-16 11:53:00 by Qweerdy
Just want to say thank Disease for rewording what I was saying, I realise I may have taken too hard line a stance. Also to what bitRAKE said, I agree, you can only do so much yourself, theres no point writing an OS to run a small program. Even for the program I'm writing at the moment I use OpenGL for rendering. This however is as much for the hardware acceleration as it is to speed up the development time. My point which I just wish to say it again even though Disease reiterated quite well, is that theres no better way to solve a problem than to solve it yourself; you not only feel better about the solution but you actually improve your problem solving abilities meaning in future it takes an even less time to solve problems.
Posted on 2001-05-16 13:41:00 by Zadkiel
disease_2000, I didn't mean for you to compete in the competition - just that it's an interesting place to look for different coding examples of people trying to accomplish the same goal. The rules are quite strict, and the diversity in what some of these programmer come up with is amazing! All the code is there for the downloading. I tried to compete once, but my entry was late and didn't quite work the way I wanted it to. :)
Posted on 2001-05-16 17:45:00 by bitRAKE
Bitrake, maybe I did not explain myself quite right. My response was purely dictated by the title of this thread: OT: Learning strategies, Improving Logic In a professional enviroment I'd use another persons stable, working, does what I want code, because TIME=$$$.(open source) But if you want to make your own (for learning)OS, game, GUI, compression prog, etc. Read, find out what you can problems/benefits. Then, in my opinion, make your own soloution to the problem on paper or program or in your head. Now your solution might work, or it might not. Now might be a good time to bring in someone else's solution. This is where you can test your logic. You might see something that they did that was really clever, or you might find where they made a mistake. Now you are testing your logic and your should have a deeper understanding of the problem. We individually decide how deep we need to understand about what we wish to understand. Some people are happy using Direct3D or OpenGl, others actually write their own afine perspective-correct texture mappers. I guess because they feel that understanding the problem at this level gives them more insight. My opinion is that removing the irrelevent from you problem/solution is one of the first stepping stones to good, solid logic. That testing your logic, you refine your logic and your abilty to identify relevent/irrelevent factors. The lower level you go in your logic, the more factors there are for you to evaluate. But one of these low-level factor could make a difference in a more high-level problem. Consider Carmack for a second. He has learned alot about architecture, memory bandwidth, video card chipsets, because he has found that knowing the electronic technology that his 3D engines runs on, makes it easier for him to buy a Ferrari than not knowing.
Posted on 2001-05-16 19:01:00 by asm_happy
asm_happy, the fact that I've been really focusing on making money lately didn't really help me to see what you were saying. :) I once tried to explain to a VB programer what I thought programming REALLY was, and it had nothing to do with what he was doing. It bothered me when someone stuck a TV dinner in a microwave, pressed a few buttons, and then tried to claim that they are a chef! I think a little differently now.
Posted on 2001-05-16 21:42:00 by bitRAKE
Working in a large business was very frustrating to me because they weren't just interested in the final product of my work. They wanted to understand the whole process. And I wanted to spend all my time coding. :) Instead, I spent most of my time explaining my code to other people (And it still wasn't enough explaining). Changes happened all the time, and if everybody didn't have a grasp of the direction things were going, then everything fell apart. In was quite a learning experience for me. I don't work there any more. :( I really was trying to do too much there. SIN and COS have features which make them useful in many situations: periodic, continuous, etc. - the same features which make them useful in mathematics. :) If you want to simulate curved features (sprite movement, lens curvature) then you could just store the parameters to a SIN/COS function. I'm sure there are other uses.
Posted on 2001-05-17 13:07:00 by bitRAKE
Sine and Cosine do nothing in programming, hence no simple example will exist. I maths terms Sine and cosine of an angle realate the opposite and adjacant side respectivly of a right angled triangle to the hypotnuse. They are mathmatical functions, not programming tools. The uses for them are so far ranging that I won't try to repeat them here, but mostly as was said they're used in rotation for example take the following lenght five rod.

<- 5 ->
o-----o
p1    p2

    0
   / p2
  /
 / \
0 A/
p1
While it horizontal p1 is at (0,0) and p2 is at (5,0). When it rotated by angle A p1 stays at (0,0) and p2 becomes (5*Cos(a), 5*Sin(a)). In fact technically you could say that while it was horizontal that angle A was zero meaning p2 = (5*Cos(0), 5*Sin(0)) which does equal (5,0). Almost everything in maths has a similar relationship with programming, they aren't tool, but functions. They have no more a specific place in programming than addition you just use them where you see fit. If you want more examples I can send them to you, but (and I know your trying top expand your knowledge here, not necessarly do something useful) the best way to learn maths is to ask someone how to implement something, they can then tell you what functions to use, how to use them and also teach you to solve the problems yourself in the future.
Posted on 2001-05-17 18:20:00 by Zadkiel
This has been a funny thread to read, I have my doubts that there is any form of formula that will address the range of people who write software. I am personally an epistemological anarchist which translates out to "if it works, do it" type person. reference material and other peoples code has always been useful but I have always been willing to reinvent a wheel that is too slow in its turning or not round that leaves you with a bumpy ride. I am very anti-formula as it stifles the creativity of code design. Originality is very important and it is the only way to solve new problems and improve older concepts. As far as method, I have never seen better than coding, more coding and even more coding after that. If all else fails code some more until it sinks in. Every new construction that you get to work is like having a new spanner in your toolbox so if you want a BIG toolbox, keep coding. Programming capacity is a very much bottom up affair. The more technique that you learn, the easier it is to think of an idea and then write it. What ruins a lot of good ideas is not having the coding capacity to write what the idea is.. Regards, hutch@pbq.com.au
Posted on 2001-05-17 19:42:00 by hutch--

 thank you all! I think this is it. ;)
Posted on 2001-05-17 21:53:00 by disease_2000