Computer Science Canada

Programming tasks for a slow afternoon
Author:  wtd [ Mon Jun 05, 2006 3:57 pm ]
Post subject:  Programming tasks for a slow afternoon
Ever had one of those days that just crawls by? You're bored to tears with no idea what to do?

Well, share with us the programming-related tasks you've come up with for yourself to fill these times.
Author:  Mr. T [ Mon Jun 05, 2006 5:36 pm ]
Post subject:  Alex's Opinion
Re-learn Turing after a long hiatus. Rolling Eyes Although I'll probably get ragged on for doing so. Sad
Author:  wtd [ Mon Jun 05, 2006 5:38 pm ]
Post subject: 
Nawww... just make sure you follow it up with something else. Variety is the spice of life and all. Smile

VB and Turing do not count as different. Wink
Author:  Cervantes [ Mon Jun 05, 2006 7:11 pm ]
Post subject: 
Just recently I spent a bit of time working the engine for air craft (triplane, specifically Wink) movement, in 2D as seen from the side (not top-down).
Author:  Martin [ Mon Jun 05, 2006 8:05 pm ]
Post subject: 
I've started getting back into C after realizing just how slow Ruby is for contest problems (yeah yeah, 1.9'll be better). And OpenGL. Mmmm, triangles.
Author:  Mazer [ Mon Jun 05, 2006 9:34 pm ]
Post subject: 
Cervantes wrote:
Just recently I spent a bit of time working the engine for air craft (triplane, specifically Wink) movement, in 2D as seen from the side (not top-down).

Confused
Author:  Mr. T [ Mon Jun 05, 2006 10:12 pm ]
Post subject:  Alex's Opinion
wtd wrote:
Nawww... just make sure you follow it up with something else. Variety is the spice of life and all. Smile


I don't plan on doing so any time soon, though. Rolling Eyes
Author:  md [ Mon Jun 05, 2006 10:45 pm ]
Post subject: 
I worked all afternoon... you people should get jobs! Wink

I usually work on a game/sim project I've had for a while; C++/OpenGL or maybe a software renderer... not sure yet.
Author:  wtd [ Mon Jun 05, 2006 10:47 pm ]
Post subject: 
Martin wrote:
I've started getting back into C after realizing just how slow Ruby is for contest problems (yeah yeah, 1.9'll be better). And OpenGL. Mmmm, triangles.


O'Caml, SML, and Scheme (via the various aggressively optimizing compilers like Stalin) will all give you really fast executables, and provide a higher level environment that C. Smile
Author:  Martin [ Tue Jun 06, 2006 2:27 am ]
Post subject: 
wtd wrote:
Martin wrote:
I've started getting back into C after realizing just how slow Ruby is for contest problems (yeah yeah, 1.9'll be better). And OpenGL. Mmmm, triangles.


O'Caml, SML, and Scheme (via the various aggressively optimizing compilers like Stalin) will all give you really fast executables, and provide a higher level environment that C. Smile


But I like C. Call me a control freak, but the thing I liked the least about Ruby is how it's almost too easy to do a lot of things. I'd prefer things to be broken down into three steps than being just one, if only to see what's really happening.
Author:  Bobrobyn [ Tue Jun 06, 2006 7:30 am ]
Post subject: 
On the weekend I went back and fixed some bugs and added music into my ol' frogger game...but that really wasn't much, I was just extremly bored. There's only one more bug to fix, fortunatly. That'll be for another day when I'm bored, hehe.
Author:  codemage [ Tue Jun 06, 2006 7:37 am ]
Post subject: 
If it's a really dead day with nothing to do, I check freelance advertisements and see if there's any quick mercenary work available.

Polish skills & learn new ones & a few bucks on the side.

If it weren't for the alarming and increasing number of Indian, Chinese & Slovakian programmers out there, it'd be more than a few bucks, too.
Author:  rizzix [ Tue Jun 06, 2006 2:13 pm ]
Post subject: 
Martin wrote:
But I like C. Call me a control freak, but the thing I liked the least about Ruby is how it's almost too easy to do a lot of things. I'd prefer things to be broken down into three steps than being just one, if only to see what's really happening.
I don't think you have the right mindset when using Ruby... =/
Author:  wtd [ Tue Jun 06, 2006 3:46 pm ]
Post subject: 
Martin wrote:
wtd wrote:
Martin wrote:
I've started getting back into C after realizing just how slow Ruby is for contest problems (yeah yeah, 1.9'll be better). And OpenGL. Mmmm, triangles.


O'Caml, SML, and Scheme (via the various aggressively optimizing compilers like Stalin) will all give you really fast executables, and provide a higher level environment that C. Smile


But I like C. Call me a control freak, but the thing I liked the least about Ruby is how it's almost too easy to do a lot of things. I'd prefer things to be broken down into three steps than being just one, if only to see what's really happening.


Perhaps on a slow afternoon you could learn to use the Ruby C API? Best of both worlds. Smile
Author:  Clayton [ Tue Jun 06, 2006 4:54 pm ]
Post subject: 
i work on learning and expanding my skills (right now working on *gulp* OOT) to get me through the day Very Happy
Author:  [Gandalf] [ Tue Jun 06, 2006 7:07 pm ]
Post subject: 
SuperFreak82 wrote:
right now working on *gulp* OOT

Though this statement is probably correct, I'm not sure you meant it that way... In any case, let me correct you. Wink OOT refers to Object Oriented Turing, while the actual concept of creating classes, objects, etc is called Object Oriented Programming (OOP).

On a boring day... I used to make Turing games which I played for 30 seconds and then threw them into a folder containing oh so many pointless Turing games. Nowadays, it's either that or else reading the two programming books I own (C and Java) or else testing out random 'features' of Ruby, C, C++, Java, and some other stuff.

Oh, and when I'm really bored, I try to make random stuff like so look as good as possible:
code:
var z : real
setscreen ("graphics:max;max")
for x : 1 .. maxx
    for y : 1 .. maxy
        z := cosd (((x ** 2) + 2 * (y ** 2)) / 4)
        Draw.Dot (x, y, RGB.AddColour (1 - z, 1 - z, 1 - z))
    end for
end for
Hit Wall
Author:  GlobeTrotter [ Tue Jun 06, 2006 7:55 pm ]
Post subject: 
A modification:

code:

var z : real
setscreen ("offscreenonly")
for j : 100 .. 160 by 5
    for x : 1 .. 360 by 1
        for y : 1 .. 360 by 1
            z := cosd ((((x ** (j / 100)) + (y ** (j / 100))) ** (j / 100)))
            %z := cosd (((x ** 2) + (y ** 2)))
            Draw.Dot (x, y, RGB.AddColour (1 - z, 1 - z, 1 - z))
        end for
    end for
    View.Update
end for
Author:  wtd [ Tue Jun 06, 2006 8:18 pm ]
Post subject: 
[Gandalf] wrote:
code:
var z : real
setscreen ("graphics:max;max")
for x : 1 .. maxx
    for y : 1 .. maxy
        z := cosd (((x ** 2) + 2 * (y ** 2)) / 4)
        Draw.Dot (x, y, RGB.AddColour (1 - z, 1 - z, 1 - z))
    end for
end for
Hit Wall


Does Turing support local scoping? Such that z could be local to the inner loop?
Author:  rizzix [ Tue Jun 06, 2006 8:54 pm ]
Post subject: 
yes
Author:  _justin_ [ Tue Jun 06, 2006 8:55 pm ]
Post subject: 
GlobeTrotter wrote:
A modification:

code:

var z : real
setscreen ("offscreenonly")
for j : 100 .. 160 by 5
    for x : 1 .. 360 by 1
        for y : 1 .. 360 by 1
            z := cosd ((((x ** (j / 100)) + (y ** (j / 100))) ** (j / 100)))
            %z := cosd (((x ** 2) + (y ** 2)))
            Draw.Dot (x, y, RGB.AddColour (1 - z, 1 - z, 1 - z))
        end for
    end for
    View.Update
end for


ahah thats pretty cool good mod Cool
Author:  wtd [ Tue Jun 06, 2006 8:56 pm ]
Post subject: 
rizzix wrote:
yes


Ok, so why does it seem that no one does this?
Author:  Andy [ Tue Jun 06, 2006 11:01 pm ]
Post subject: 
because new programmers do not see the need for memory efficiency
Author:  Clayton [ Tue Jun 06, 2006 11:14 pm ]
Post subject: 
@Gandalf: i meant i was working on OOP in Turing; affectionately known as OOT Very Happy (very creative name eh?)
Author:  [Gandalf] [ Wed Jun 07, 2006 5:03 pm ]
Post subject: 
wtd wrote:
Does Turing support local scoping? Such that z could be local to the inner loop?

Indeed it does. I do this in basically all code blocks other than loops (unless they iterate only a few times in which case in my mind the advantages outweigh the disadvantages). The reason being, doesn't redeclaring and initializing take longer (I'm trying to be careful with my use of the terms 'resources' and 'efficiency' here) than just initializing? This is what I based my decision off of.
Author:  Martin [ Wed Jun 07, 2006 6:38 pm ]
Post subject: 
No, it's a very easy compiler optimization to do to make it just as fast.

What is slow though is new, which you should use as little as possible. Instead, give your objects that are going to be created and destroyed a lot a 'visible flag' instead of freeing and creating them.

(I'll post an example in a few minutes)
Author:  wtd [ Wed Jun 07, 2006 7:19 pm ]
Post subject: 
Martin wrote:
No, it's a very easy compiler optimization to do to make it just as fast.


You beat me to it.

Essentially. Turing is a highly static language. It knows at compile-time what variables there are and what kind. If it doesn't take advantage of that knowledge.. then that's Turing's fault. Lot of other languages take advantage of this.
Author:  Martin [ Wed Jun 07, 2006 7:25 pm ]
Post subject: 
Basically, when writing a program your goal should be to have as few unused variables as possible.

code:

var j := 6
for i: 1 .. 10
  var x := i * j
  put x
end for
some_proc(j)
...


Is good, because x is declared as deeply as possible. If you want to reuse x, you can just declare it again somewhere underneath the ellipses. If your code starts to get long, it'll make it so you don't have to remember what unused variables you've declared. The cost of doing this is going to be the same as declaring it anywhere else.

With pointers, however, you have to be careful.

code:

var x : array 1 .. 10 of pointer to my_class
for i: 1 .. 10
  x(i) := new my_class(i)
end for
...

Is okay, but if you do this, you have to watch out

code:
for i: 1 .. 10
  var x : pointer to my_class
  x := new my_class(i)
end for

Memory leak! The previous value of x is forgotten about, a new one is created and the old one is left floating around in memory never to be found again.

Also, instead of freeing variables that are going to be created again, flag them as dead. Suppose that particle2d represents a 2d particle.

code:

%Do the particle code
var particles : array 1 .. 10 of particle2d
for i: 1 .. 10
  particles(i) = new particle2d(100,100)
end for
loop
  for i: 1 .. 10
    if particles(i) = null then
      particles(i) := new particle2d(100,100) %reset it
    end if
    particles(i).update_position %move the particle one frame (based on gravity)
    if particles(i).is_outside_valid_area then
      free particles(i)
      particles(i) := null
    end if
  end for
end loop


This will run a lot slower than the following:
code:

%Do the particle code
var particles : array 1 .. 10 of particle2d
for i: 1 .. 10
  particles(i) = new particle2d(100,100)
end for
loop
  for i: 1 .. 10
    if particles(i).is_dead then
      particles(i).move_to(100,100) % move it, and mark it as alive
    end if
    particles(i).update_position %move the particle one frame (based on gravity)
    if particles(i).is_outside_valid_area then
      particles(i).kill %mark the particle as dead
    end if
  end for
end loop


Yar!

:


You can syndicate this boards posts using the file backend.php or view the topic map using sitemap.php.

Terms of Use | Privacy Policy