It’s not about less space, something that will rarely matter in the future, it’s about not annoying me by making me look somewhere else.
I thought maybe they should include the alternate reference too, for example:
Grean Beans [Beans,Green] page 27
But who TF cares? This is the 21st century folks, you oughta be able to find something in an index based on any identifying word or phrase. It may be hard for some people to grasp but the information age increasingly maintains unordered lists with no particular starting point. There is no ideal or preferred reference to find information.
I never did answer why. It was a convenience in creating and maintaining an index when that was a manual process. Duplicating the page numbers would increase the chance of using the wrong page number. Corrections can be made in subsequent printings but those printings may also need re-pagination which becomes more difficult with duplicate entries.
Here’s why: if you only list the page number for an index entry in one (and only one) place, then you only have one place in which you have to update the page number if the pages later get renumbered (in a different edition or printing).
If on the contrary you list the actual page number in both places, it’s all too easy to later update one but miss the other one.
(I run into the same issue with construction contract provisions at work. For example, I always tell our procurement folks to put the contract time [e.g. 270 calendar days] in only one place in the contract. If you put it in the contract in six different places, don’t be surprised to find out later only one of them gets updated to a revised contract time, and the rest get missed.)
Somewhat of a diversion, but a textbook I still have from my undergraduate days is “Elementary Number Theory, Second Edition” by Underwood Dudley. In the index, on page 249, is the entry “Sex in number theory, 248”. On page 248 is “Number theory, sex in, 249”.
So another reason for this type of index entry is to amuse authors and students, although this particular example would run afoul of the page re-numbering issue mentioned up-thread.
In the telephone directory for our city, both city and provincial services have that type of thing (eg. “water main breaks” see “breaks, water main”) listed in indexes. Still, they are easier to find than on the various comparable web sites. I’m sure the days of paper directories are limited however, on line directories still need improving.
Even better is the CS book that has the entry
Infinite loop, see Loop, infinite while under Loop, infinite, it says … (you can guess).
There is one book that has a discussion as to how to be careful with set theory to avoid Russell’s paradox and ends the discussion with “This prophylaxis guarantees safe sets.” (Sorry, I just had to tell about that.)
This used to be a big deal in the Yellow Pages business, when there was such a thing. The publishers were in competition and the number of cross references or even advertising under multiple references were touted as features. I think there are a few local books and some overseas but the heyday of the big giant yellow phone book is long gone.
Makes sense, but you would think with modern indexing tools which handle cross referencing automatically you could set it up to hyperlink to the other index entry, so that when the pages linked to by an index entry change, all of the alternative entries that link to it change as well.
There’s also the aspect of the "See " being not quite the same as what you looked up.
To use your example, let’s say you looked up “Green Beans”, and it says “See Phaseolus Vulgaris” because the only example in the book is to beans in general, and only has a vague passing mention of green beans.
This is also a fundamental rule of good database design (which some DB designers seem to understand better than some others). Any specific piece of information should only appear ONCE in a database, not in a bunch of places.
For example, if you need to record a customer’s address, that should appear only ONCE (e.g., in the customer’s record in your Customer table), and should NOT appear again in every purchase order record, billing invoice, or shipping record. All those records should simply refer to the customer’s master Customer record.
A similar rule is often taught in computer programming: A constant should only appear once in program. If you use the constant PI a lot, but carelessly write it as 3.14159 in some places and 3.14159265 in other places, you could end up with inconsistencies in your computations. They they’ll wonder why that Venus probe missed the planet by 50000 miles.
Instead, define a variable or constant like PI := 3.14159265
just once in your code, to the number of decimal places you think you need, and refer to PI through the code thereafter. If you later find you need a few more digits to get the precision you need, you just need to fix it in one place.
Many modern programming languages come with pre-defined libraries of hundreds of commonly-used constants like this.