The Ray Tracer Challenge: use of a type code (pg. 3-4)

@jamis

After introducing the ideas of tuples, vectors, and points, the book goes on to say:

But looking at (4, -4, 3) and (-4, 4, -3) , it’s impossible to know that one is a point
and the other is a vector. Let’s add a fourth component to these (x, y, z) tuples,
called w , to help us tell them apart. Set w to 1 for points, and 0 for vectors.
Thus, your point becomes (4, -4, 3, 1) , and your vector becomes (-4, 4, -3, 0) .
Now, the choice of 0 or 1 for w probably seems arbitrary just now, but sit
tight! It’ll make more sense when you get to Chapter 3, Matrices, on page 25,
where it turns out to be rather important for multiplying matrices and tuples.

This advice seems misguided to me, as it amounts to using the fourth component as a type code, and not even a symbolic one–you just have to remember that 1.0 in the fourth component means a vector and 0.0 indicates a point. Especially given that this book appears to be aimed towards fairly junior developers, that’s not a practice we should be encouraging.

I agree that it’s necessary to differentiate between vectors and points, and the best way to do it depends largely on the language you’re using. That said, every mainstream language that I know of has a better way to do that than what is suggested here.

@jamis

I feel this. But let me give my two cents. I’m coding in Java.
I’ve just started the book today and got stuck when it came to implementation of the different operations on Tuples, Points and Vectors.

TL;DR: in the end, the current description in the book allows for two main points:

  • it has me thinking really hard on what the best approach is. And in the spirit of TDD, I came to the realisation that the stage I’m in now needs me to not overthink all of that too early and go with the flow and trust the process.
  • the loose description gives you the full freedom. Sticking to only point and vector is a too narrow view. Using Tuple with the convenient “w” component allows for a broader understanding of the underlying mechanisms

Here’s a more detailed description of what happened to me:
I’ve started immediately with a type system, Tuple, Point and Vector. Now, may it be to language restrictions or inherently complex design, implementing the different rules per Type seemed to create an enormous mess. I.e. is Tuple allowed to add two “points” but the Point type isn’t? Does each type need an extra implementation to return the correct type, depending on the operation (e.g. returning a vector when adding point+vector)?
Does every type have to implement this? The inheritence tree looks like garbage after a few tries.
From my point of view: using narrow types requires much more design skill from a beginner developer and is more prone to end up in a mess that is really hard to refactor your way out of.
Using a “flag” on a single type is way easier for the initial design.

My current solution is to just stick to the Tuple type with some convenience methods. This is clean and I expect most flexibility with this approach.

I’d just like to point out that according to ProgPrag, this book is aimed at expert level programmers, and not beginners.

I thought of implementing Tuple as a sealed class and then Point and Vector as its implementations, but in the end, I figured I didn’t see what might be forthcoming and it made more sense to not do so only to have to go back and substantially rewrite my implementation.

@srmo, the interactions between points and vectors should be fairly easy to handle:

  1. Point - Point gives Vector.
  2. Point + Point is an illegal operation.
  3. Point + Vector gives Point.
  4. Point - Vector gives Point.
  5. Vector + Vector gives Vector.
  6. Vector - Vector gives Vector.
  7. Vector - Point is an illegal operation.
  8. Vector + Point is an illegal operation.
  9. scalar * Point is an illegal operation.
  10. scalar * Vector gives Vector.
  11. Dot product and cross product only work for Vector and Vector and give scalar and Vector respectively.

It does end up messy if you’re not careful.

As it stands now, I have some exception handling which would be rendered unnecessary if I switched to 3D Tuples. I may go back and try to rework the code now that I’m done the book to see if I can get it to function with the sealed Tuple class. It might speed things up somewhat as well.