Prof Avery's weblog
touched by an anvil

<spool@kenytt.net>

Geek News

del.icio.us bookmarks

Learn to Program
I'm a big fan of the Pragmatic Programmers, so when Ruby first appeared on the scene I bought a copy of the first edition of Programming Ruby.

Honestly, it failed to grab me. It looked like a nice enough language, but its syntax is sort of a hybrid of Perl and Python. Given that I already know both Perl and Python, I couldn't see the point of spending much time on Yet Another Language, especially one that was more of the same.

Still, buzz continued to grow. I picked up a copy of Hal Fulton's book The Ruby Way. This one included Appendices explicitly for Perl and Python programmers, as well as several "real-world" examples, so I gave it another shot.

Actually, I started to give it another shot. But since the Appendices were squarely aimed at me, I started there. Big mistake -- I fell asleep. Several times. I put the book aside and figured I was done.

Three years later, in 2004, along came Ruby on Rails. Wow. Do I really need to tell you how impressive Rails is? But at the time I wasn't working on any web applications, I still wasn't thrilled with Ruby as a language, and I certainly wasn't thrilled at the prospect of learning a whole new language just to write web apps.

More recently I've been looking at the cavalcade of Rails clones. I think I've settled on CakePHP as the best documented, most mature, and easiest to learn. But just as I was getting started, it occured to me....

As I tell students, the best way to learn is by going straight to the source, not by reading the n^th re-hash by someone else. I'm still planning to learn Cake, but really, why not start with the best? (Or at least with the original.)

Ok, back to Ruby. In the years since Programming Ruby was published by Addison-Wesley, the Pragmatic Programmers have started their own publishing company, The Pragmatic Bookshelf. Which brings me (finally) to the ostensible subject of this review, Learn to Program by Chris Pine.

The purpose of Learn to Program is, well, to learn to program. The language just happens to be Ruby. Honestly, I don't even remember when I first learned to program -- I must have been 7 or 8 years old. (BASIC, on a Timex-Sinclair 1000, if you must know). I can't really comment on how well the book succeeds in that goal, because I'm clearly not the target audience.

I read through the book fairly quickly, since I already understand the concepts. A couple of things concerned me, though. The explanation of "variables" seemed overly complicated. I think the author was trying to explain references, without actually using the word "reference".

Ditto his explanation of recursion -- I admire the attempt to suggest that recursion is a perfectly natural concept (the title of Chapter 10, on recursion, is "There's Nothing New to Learn in Chapter 10"), especially since most CS1 textbooks for imperative languages make it far too complicated. But c'mon. If it's so easy, why does "nothing new" take 17 pages to explain?

So I can't tell you whether it's a good book for a beginner, but it was a good book for me. The truth is, the only way to learn a new programming language is to write code. You can't just sit and read a book about programming; you need to do it yourself. In this, the author succeeds wonderfully. The exercises he suggests (under the heading "A Few Things to Try") are geared toward putting the concepts you've just read about directly into practice. And they're straightforward enough that, instead of thinking "oh great, another programming exercise," you'll be thinking "hey, that sounds easy enough," and you'll dive right in.

Even better, they're fun. No lame "Hello, world" or farenheit-to-celsius converters here. (Oops, I think I just insulted K & R.) Instead you'll find such gems as

• An "Angry Boss" program, which rudely asks you what you want, then yells and fires you.
• Generating .m3u playlists for use in WinAmp
• 99 Bottles of Beer on the Wall

Oh, and my impressions of Ruby now that I've written a few short programs? It's kind of a nice language. You can slurp the contents of a file in a single line. It switches seamlessly between fixed-sized integer types and "big" integers. (As it turns out, so does Python, but I'd never seen it before). YAML is nicer than Perl's Data::Dumper. I like that you can add easily add methods to built-in classes, even if it's probably a bad idea -- being able to type 3.factorial is coool.

Ruby strikes me as being sort of like Python, if Python had been written by someone who liked Perl. I don't think, though, that it goes the other way: Ruby is not sorta like Perl. It just has enough Perl-ish bits to make the transition less painful.

I'm having trouble deciding on my next Ruby book. I'm leaning toward the Pickaxe Book, but Ruby for Rails looks good, too. After all, that's why I was planning to learn Ruby in the first place.

By the way, click here for some bits of Ruby code. Nothing spectacular, but they're sitting here on my hard drive -- no point in not sharing them.

/var/spool/reviews #

Compiling Fl-Inventor on Windows
Another option for Open Inventor programming on Windows is the Fl-Inventor library. Here's how I got it to build:

1. Download the latest version of FLTK 1.1 from http://www.fltk.org/. At the time of this writing, the latest is fltk-1.1.7-source.zip
2. Unzip somewhere convenient, say C:\fltk-1.1.7
3. Open visualc\fltkdll.dsw with Visual Studio. (I'm using 6.0. If you're using a later version, your mileage may vary.)
4. Choose Build, Set Active Configuration... and choose fltkdll - Win32 Release

   

5. Choose Build, Build fltkdll.dll.
6. Download and install an older version of CMake from http://www.cmake.org/files/. (The latest version won't work without change, and the last thing I need to learn is a new build tool.) I used CMSetup14.exe.
7. Download fliv-1.0.1.tar.gz and oiv_linux_w32-4.tar.gz from http://fl-inventor.sourceforge.net/. Unzip them both into the same place.
8. Change to C:\fl-inventor and type "cmake ."
9. Back in Visual Studio, open FLINV_ALL.dsw
10. Set the Active Project Configuration to "ALL_BUILD - Win32 Release".

    

11. Choose Project, Settings.... Settings For: should be set to "Win32 Release", and all sub-projects should be selected.
12. Holding down the Ctrl key, de-select ALL_BUILD. Some more tabs should appear to the right. Select the C++ tab, and change Category: to "Preprocessor". Under Additional include directories:, add C:\fltk-1.1.7.

    

13. Holding down the Ctrl key again, de-select FL, FreeType2, and Jpeg. A Link tab should appear to the right. Select it and Change the Category: to "Input". Under Additional library path:, add C:\fltk-1.1.7\test. Click Ok

    

14. Choose Build, Build. The build will take several minutes.
15. Exit Visual Studio. You should be able to run the example programs from C:\fl-inventor\install\bin

/var/spool/graphics #

Open Inventor on Windows
The Open Source version of SGI Open Inventor is Linux-specific, and while it probably ports easily enough to other UNIX platforms, it doesn't look like a very attractive option for Windows.

If you want to do Open Inventor programming on Windows, the options seem to be:

1. TGS Open Inventor, a commercial product
2. Coin3D, a GPL clone of Open Inventor
3. a Win32 port of the Open Source SGI Open Inventor that requires the SoQt library from Coin3D

Alternatively, the Win32 port of Open Inventor does incldue pre-compiled DLLs of Inventor, but not of the SoQt library or command-line tools.

I'm honestly not sure what the best solution is. I'll post some instructions when I come up with something.

/var/spool/graphics #

Minimal Ray Tracer
Some code to accompany tonight's lecture: a version of Paul Heckbert's Minimal Ray Tracer from Graphics Gems IV.

I've updated the code to do the following:

• compile with GNU C
• output plain PPM
• generate a 1024 by 1024 image instead of the tiny 32-pixel original

If you want to experiment with changing the scene defined in ray.h, you'll probably want to download NetPbm for Windows.

/var/spool/courses/csuf/2006/spring/cpsc465 #

Assignment 10
If you didn't finish Assignment 10, you can download assignment10.c as a starting point for Assignment 11.

/var/spool/courses/csuf/2006/spring/cpsc465 #

Demos for tonight's lecture
There are two demonstration program for tonight's lecture:

• shading.c
• texture.c

/var/spool/courses/csuf/2006/spring/cpsc465 #

Pixar's On-line Library
I happened across this the other day: Pixar has made available an On-line library of technical papers. Many of them are probably a bit advanced, but worth a look if you're considering further study.

/var/spool/courses/csuf/2006/spring/cpsc465 #

Is this normal behavior?
Have you noticed that the lighting calculations don't seem to be affecting your windshield the same way they affect the rest of the car?

I wonder which part of the illumination equation isn't being evaluated normally.

/var/spool/courses/csuf/2006/spring/cpsc465 #

Material Colors
Here's a function to set the current drawing color, whether or not lighting is enabled:

    void color(double r, double g, double b)
    {
        float color[4] = { r, g, b, 1.0 };

        if (glIsEnabled(GL_LIGHTING)) {
            glMaterialfv(GL_FRONT_AND_BACK, GL_AMBIENT_AND_DIFFUSE, color);
        } else {
            glColor3f(r, g, b);
        }
    }

Alternatively, you could try reading about GL_COLOR_MATERIAL.

/var/spool/courses/csuf/2006/spring/cpsc465 #

Chapter mismatch between HTML and PDF versions of the Red Book
HTML and PDF versions of the Red Book -- they're different editions, with different Chapter divisions. The Chapter 12 you want is "Selection and Feedback", not "Evaluators and NURBS." The next chapter, "Lighting", has the same problem.

/var/spool/courses/csuf/2006/spring/cpsc465 #

Assignment 9
Assignment 9 is available. Trust me -- the assignment will be easier if you attend class and implement the version of the algorithm that we discuss.

/var/spool/courses/csuf/2006/spring/cpsc465 #

Slides for tonight's lecture
For the second half of tonight's lecture, we'll be looking at the Aliasing and Antialiasing slides in the ACM SIGGRAPH 1993 Education Slide Set. There are some visual effects here that I couldn't draw on a whiteboard to save my life.

/var/spool/courses/csuf/2006/spring/cpsc465 #

A note on doing the work yourself
I realize that in Assignment 6 and Assignment 7 where we deal with well-known algorithms, it will be especially tempting to use someone else's implementation -- they are, after all, readily available on teh interwebs.

Note, however, the following:

1. Turning in code you didn't write yourself is Academic Dishonesty.
2. Using someone else's pseudocode is fine, as long as you credit the source.
3. If you do use someone else's pseudocode, make sure you understand what it does.
4. There will be at least one question on each algorithm on the Final Exam.
5. If you take the time to implement the algorithm yourself, you will be more likely to remember it well enough to earn full credit on the exam.

Hint: pick a partner who's smarter than you are.

/var/spool/courses/csuf/2006/spring/cpsc465 #

Announcements
Assignment 6 is available.

Note the updated office hours shown to the left: I've been able to rearrange my work schedule in order to be available before class. Be sure to drop by and visit.

/var/spool/courses/csuf/2006/spring/cpsc465 #

GLIntercept
Here's a cool debugging tool for OpenGL on Windows: GLIntercept. You can use it to track every OpenGL function call along with its parameters. (For those of you familiar with UNIX, this is like truss(1) or strace(1), only for OpenGL calls instead of system calls.)

Here's a 30-second walkthrough:

1. Download and run the Windows installer. You'll end up with a new directory, C:\Program Files\GLIntercept0_5.
2. Copy OpenGL32.dll and gliConfig_FullDebug.ini to the same directory as your program. Rename gliConfig_FullDebug.ini to gliConfig.ini
3. Run your program. A new file will be created in the same directory called gliInterceptLog.txt, containing every OpenGL call your program makes. (You may also find that your program is a little slower).

    glClearColor(0.000000,0.000000,0.000000,0.000000)
    wglGetCurrentContext()=0x10000
    wglGetCurrentDC()=0xb70114f8
    wglGetCurrentContext()=0x10000
    wglGetCurrentDC()=0xb70114f8
    glViewport(0,0,600,300)
    glMatrixMode(GL_PROJECTION)
    glLoadIdentity()
    glOrtho(0.000000,2.000000,0.000000,1.000000,-1.000000,1.000000)
    glMatrixMode(GL_MODELVIEW)
    glLoadIdentity()
    glClear(GL_COLOR_BUFFER_BIT)
    glColor3f(1.000000,1.000000,0.000000)
    glBegin(GL_LINES)
    glVertex3f(1.000000,0.000000,0.000000)
    glVertex3f(1.000000,1.000000,0.000000)
    glEnd()
    glViewport(300,0,300,300)
    glMatrixMode(GL_PROJECTION)
    glLoadIdentity()
    glFrustum(-1.500000,1.500000,-1.500000,1.500000,2.000000,8.000000)
    glMatrixMode(GL_MODELVIEW)
    glLoadIdentity()
    glMultMatrixf([1.000000,0.000000,0.000000,0.000000,
                   0.000000,1.000000,0.000000,0.000000,
                   0.000000,0.000000,1.000000,0.000000,
                   0.000000,0.000000,0.000000,1.000000])
    glTranslated(0.000000,0.000000,-6.500000)
    glPushMatrix()
    glPushMatrix()
    glColor3f(1.000000,0.000000,0.000000)
    glBegin(GL_LINE_LOOP)
    glNormal3fv([0.000000,0.000000,-1.000000])
    glVertex3fv([0.500000,0.500000,-0.500000])
    glVertex3fv([0.500000,-0.500000,-0.500000])
    glVertex3fv([-0.500000,-0.500000,-0.500000])
    glVertex3fv([-0.500000,0.500000,-0.500000])
    glEnd()

To make the best use of a tool like this, you'll probably want a utility to tail the log as your program is running. (I'm told there are also GUI versions).

Note that you don't need access to the source code -- if you have a game at home that uses OpenGL, you can watch what it's doing, too. (Just don't steal their code, and don't tell them I'm the one who told you how.)

GLIntercept has a few more tricks up its sleeve, but I'll leave it up to you to read about them. For Linux people, there's a similar program called BuGLe, but I haven't tried it. And, of course, we smug OS X weenies have the OpenGL Profiler.

For those of you using Igloo, I've put together a new debug package that includes GLIntercept and Windows port of GNU tail. I'm not entirely sure about the legality of all this -- GLIntercept and GNU tail are available under the GNU General Public license, but EiC is still MIA.

/var/spool/courses/csuf/2006/spring/cpsc465 #

Why Microsoft is not my favorite software company
The grade sheet that I posted a few minutes ago is rather hard to read in Internet Explorer. It looks like the bottom few pixels of each row are cut off.

The HTML file was generated by setting a print area and choosing Save As Web Page from the File menu in Excel 2004 for Mac.

I understand cross-browser differences. I even understand cross-platform differences. But if I can't save a web page from the latest version of one Microsoft product and have it readable from the latest version of another Microsoft product, well...

You should all be using Mozilla Firefox anyway. It looks fine there.

/var/spool/courses/csuf/2006/spring/cpsc465/misc #

Homework Grades
I've posted grades as of 10:41pm Friday 3/17.

If you turned in an assignment that isn't recorded, or if you didn't get as high a score on an assignment as you think you should have, please e-mail me.

/var/spool/courses/csuf/2006/spring/cpsc465 #

Assignment 5
Assignment 5 is available. Note that this is the last assignment due before the Midterm Exam on March 24.

/var/spool/courses/csuf/2006/spring/cpsc465 #

Pop-quizzes and pedagogy
A study from Washington University in St. Louis finds that

quizzes -- given early and often -- may be a student's best friend when it comes to understanding and retaining information for the long haul

/var/spool/science/psychology #

Another schedule update
Please note that I've updated the Course Outline again.

For those of you wondering why I've been making changes to the schedule, I've taught the course two different ways in the past:

1. As a lab course with weekly assignments
2. As a lecture course with 4 or 5 larger programming assignments

I'd originally planned to teach this semester as a lecture course, but when it was scheduled for a single class meeting on Friday nights a couple of things became clear:

1. The building would be nearly empty, and we could have our pick of labs
2. In a lecture course, everyone would be asleep by 8:45

/var/spool/courses/csuf/2006/spring/cpsc465 #

Vector Math Tutorial for 3D Computer Graphics
If you need to brush up on your math before the midterm, the Vector Math for 3D Computer Graphics from the Computer Science department at Central Connecticut State University is a pretty good review.

/var/spool/courses/csuf/2006/spring/cpsc465 #

A correction
If you were paying attention over the weekend, you noticed that I updated the screenshot for Assignment 4.

If you compare it with the original screenshot, you'll notice that the original wasn't really a parallel projection.

The problem is that (as you should recall from your reading) OpenGL is a state machine. When you make a function call like gluPerspective() to update the current projection matrix, that change stays in effect until you reset the matrix (e.g., with glLoadIdentity().

My mistake was to draw the parallel projections (calling glOrtho()) without remembering to reset the projection matrix, which had already been set with gluPerspective. The result was that we took a cube in perspective, then drew a parallel projection of the perspective rendering. Oops. I didn't notice because it looks "sort of" right -- there was, in fact, a parallel projection happening.

To avoid making silly mistakes like me, do the following whenever you go to render a model (e.g., in your display callback):

1. Set the viewport.

   glViewport(0, 0, width, height);

2. Set up the projection.

   glMatrixMode(GL_PROJECTION); glLoadIdentity(); glOrtho(-2.0, 2.0, -2.0, 2.0, 0.0, 10.0);

3. Set your viewing parameters.

   glMatrixMode(GL_MODELVIEW); glLoadIdentity(); gluLookAt(0.0, 0.0, 3.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0);

4. Draw the scene.

   glClearColor(0.0, 0.0, 0.0, 1.0); glClear(GL_COLOR_BUFFER_BIT); glColor(0.0, 0.0, 1.0); glutWireSphere(1.0, 10, 10);

/var/spool/courses/csuf/2006/spring/cpsc465 #

Don't cross the streams
If you're still working on Assignment 3, note that the coordinate axes (the lines in gray) should not be moving when you transform the cube. The axes should remain at the center of the world, not at the center of your model.

By the way, Assignment 4 is available.

/var/spool/courses/csuf/2006/spring/cpsc465 #

Assignment 3
Assignment 3 is available.

/var/spool/courses/csuf/2006/spring/cpsc465 #

Best science headline ever
From New Scientist: Hand waving boosts mathematics learning.

So don't complain when I do it in class: it's a pedagogical technique.

On a more serious note, blame computers for this one: Mathematical proofs getting harder to verify:

"Twenty-five years later we're still not sure if it's correct or not. We sort of think it is, but no one's ever written down the complete proof"

/var/spool/science/math #

February 2019
Sun	Mon	Tue	Wed	Thu	Fri	Sat
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28

RSS

Topics

• administrivia (2)
• courses (138)
• . csuf (138)
• . . @2005 (103)
• . . . @spring (103)
• . . . . @cpsc423 (25)
• . . . . @cpsc433 (24)
• . . . . . @misc (14)
• . . . . @cpsc461 (20)
• . . . . @cpsc465 (26)
• . . @2006 (35)
• . . . @spring (35)
• . . . . @cpsc465 (34)
• . . . . . @misc (4)
• graphics (2)
• last (12)
• reviews (2)
• science (2)
• . math (1)
• . psychology (1)
• tools (3)
• . editors (1)
• . graphics (1)
• . security (1)

Archives

• July 2006 (1)
• June 2006 (2)
• May 2006 (7)
• April 2006 (4)
• March 2006 (9)
• February 2006 (16)
• January 2006 (2)
• July 2005 (3)
• May 2005 (15)
• April 2005 (20)
• March 2005 (31)
• February 2005 (34)
• January 2005 (4)
• June 2003 (1)
• May 2002 (3)
• April 2002 (7)
• March 2002 (2)