Milktrader

Iterating Until Convergence

Friday, July 23, 2010

My First C Program

Before I sat down to read Programming In C by Stephen Kochan, I had to set the table. This is no small matter for someone who was using Excel and Windows just a few short months ago. I wanted to do things proper, so I installed Ubuntu on my laptop via the VMware Player. I am going to learn C and I'm going to do it on a linux machine. Part of learning to program requires writing and compiling programs that the author provides for examples. Keeping track of these can become a nightmare without a system. I chose to learn the svn utility to serve this purpose. Also, I needed some basic command-line skills to get me around linux, so I got some resources to help me along there as well. And to do command line programming, you need a compiler and text editor. Okay, no bigs. I decided to learn VIM because it requires no mouse and is itself programmable (loving it, by the way). The compiler comes with Ubuntu and is called gcc.

After some fits and starts, I got myself all set to go with being able to write a simple example program in VIM, compile it with gcc, run it from command line (there is a ./ trick that took a while to figure out) and then commit it to a repository that I previously set up in my Dropbox account. Now it was a matter of going through Kochan's book and compiling all his example code. I've almost finished the book and probably will finish it within a week. After getting through pointers, it's basically knowledge acquisition and not conceptual grasping any more.

I will use C to turbo-charge some R functions that I have planned. And I will use C as a building block to learning C#, which I plan on using quit a bit in deploying neural network solutions to market prediction.

It may not seem like much, this first program of mine. But actually, I'm quite pleased. It actually works. Here is what we want to do. Enter price data from the terminal and have the program return the Open, High, Low and Close in that order. Sort of like an echo. It's a 'knock, knock, anybody there?' sort of program. But the potential is there for more functional things to come.

// Here we will randomly enter the OHLC data manually from the terminal
// And essentially spit it out in a new order, that being OHLC

#include <stdio.h>

int main (void) {
      
 float  O,H,L,C;

 printf("Enter the High of the Day: \n");
 scanf("%f", &H);
 
 printf("Enter the Low of the Day: \n");
 scanf("%f", &L);
 
 printf("Enter the Open of the Day: \n");
 scanf("%f", &O);
 
 printf("Enter the Close of the Day: \n");
 scanf("%f", &C);

 printf("The OHLC data is: %.2f, %.2f,  %.2f,  %.2f  \n", O,H,L,C); 

 return 0;

}















Feel free to copy this code and compile it yourself. Admittedly it's not very exciting. It did take me a while to get here though, and the fun is just starting. Markets, beware.






6 comments:

  1. Good for you-- keep us posted as you learn more. Your PPT colleague, lindsay
    ReplyDelete
  2. I'd suggest replacing float with double. The performance hit is negligible on modern FPUs and you'll be saved from many precision-related problems.

    In the future when you have your fancy app completed and profiling shows that memory bandwidth is a bottleneck you may always switch back to float.
    ReplyDelete
  3. thanks @lindsayrl.

    @wburzyns there is a story behind my selection, and I'm afraid it does not belie my commitment to best practices, but rather my succumbing to the expediency of "getting the code out".

    I will rewrite pivot1.c shortly with your suggestion in mind and call it pivot1A.c, because I'm already at pivot5.c in my laboratory. You know what they say, you can never go back home.
    ReplyDelete
  4. I wanted to use double from the get go, but when I put %d in place of %f in the scan function, I got compile errors stating it was expecting an int pointer not a double pointer. Huh? Well (and this is very strange) %d is actually an int pointer to a decimal. Hmmmm.

    It turns out that if you want to point to a double, you must use %lf, which make perfect sense of course, if you think about it.

    The way I corrected the above code is with the following line in VIM command line:

    :%s/%f/%lf/g

    which means, : (command) %s (substitute it all) %f (finding %f), %lf (replacing it with %lf) g (good, I guess - or maybe globally - not sure on this one)

    And of course I replaced float with double in line 8 with the following VIM command:

    :s/float/double/g

    Don't let the % thing get you confused as it means different things in different context.

    It works fine now and I regret not stackflow.com "ing" the answer to my question before 'forging' ahead with a reckless compilation.

    It works both ways in the final printf statement in line 22 to state either %.2f or %.2lf, which is a matter of concern to me at the moment. We all know what the .2 portion indicates significant to 2 decimal places (100th - or cents in the real world). But does it create trouble to use %.2f versus %.2lf?

    Not sure on this one.

    Ah, I have much to learn.
    ReplyDelete
  5. Here is the answer to your question:
    http://stackoverflow.com/questions/210590/why-does-scanf-need-lf-for-doubles-when-printf-is-okay-with-just-f
    ReplyDelete
  6. Thanks for the stackoverflow reference. Some unkind words for the scanf function over there. I'll be migrating the fgets for future applications.
    ReplyDelete