
pdarnowsky
The Ray Tracer Challenge: use of a type code (pg. 3-4)
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.
First Post!

srmo
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.
Popular Prag Prog topics










Other popular topics










Latest in PragProg
Latest (all)
Categories:
Popular Portals
- /elixir
- /rust
- /wasm
- /ruby
- /erlang
- /phoenix
- /keyboards
- /js
- /rails
- /python
- /security
- /go
- /swift
- /vim
- /clojure
- /java
- /haskell
- /emacs
- /svelte
- /onivim
- /typescript
- /crystal
- /c-plus-plus
- /tailwind
- /kotlin
- /gleam
- /react
- /flutter
- /elm
- /ocaml
- /vscode
- /opensuse
- /ash
- /centos
- /php
- /deepseek
- /zig
- /scala
- /html
- /debian
- /nixos
- /lisp
- /agda
- /react-native
- /sublime-text
- /textmate
- /kubuntu
- /arch-linux
- /revery
- /ubuntu
- /manjaro
- /spring
- /django
- /diversity
- /nodejs
- /lua
- /julia
- /c
- /slackware
- /neovim