The simple explanation is that I attached the link to the wrong record, as can be seen from the SPOT extract below.
****
SPHERICAL RP RAIA 8.99 9-68 2431
Rainbow Arts Arcade: Platform
A @@ 9.99 p. 0 .AP @ Probe Software
F YS 9.90 p. 66 .C Complete Guide to Puzzle games
F YS 9.90 p. 66 YY http://www.ysrnry.co.uk/articles/completeguidetopuzzlegames.htm
H CR 6.90 p. 34
H CR 7.91 p. 26
N GM 3.89 p. 11
N YS 9.89 p. 7
P GM 6.89 p. 10
P NE 2.89 p.328
R AC 8.89 p. 58 .N not a Spectrum article
R CR 12.89 p. 67
R SU 12.89 p. 97 CO http://www.crashonline.org.uk/71/spherical.htm
R YS 12.89 p.104 YY http://www.ysrnry.co.uk/articles/spherical.htm
T AC 10.89 p. 76
T CR 1.90 p. 44
T CR 1.90 p. 46
T SU 6.90 p. 16
T SU 7.91 p. 17
T SU 4.92 p. 16
T YS 4.90 p. 38
****
Aaahh, that would certainly explain why I couldn't find what caused this particular problem!
Thanks for the information; I was beginning to pull hairs (of my guinea pigs, not my own, mind. :razz:)
But let me again sing the praises of SPOT and Infoseek - there are 4699 virtual double-page spreads on the YSRnRY, and cross-referencing mistakes are very few and far between. SPOT and Infoseek helps make the YSRnRY look good.
There is a problem with the display generator in this regard, but I haven't been able to put my finger on it yet...
Here's an example of where there is still a problem. Check the Crash 9.89 entries for Sceptre of Bagdad. The database has two entries for the same page, one for cover tape instructions (V) and one for a solution (S), but Infoseek shows the solution entry twice and doesn't show the cover tape entry at all. This is related to the solution entry actually comprising two records, one with a description and one with a URL; when merged for display the result gets jumbled. It only goes wrong when there is more than one type of entry for the same program on the same page and one of them is a paired entry with a separate description and URL.
What you describe is exactly what I thought would be the problem (and I reckoned this was also what was causing the problem this thread started with!)
However, since I still couldn't find it, I played with the SPOT data a bit.
I'm afraid the problem seems to be caused by the SPOT database... Infoseek follows the rule of page numbers along with a digit, which you invented to combat this exact problem, so that couldn't be it.
On close inspection, the Crash references are as follows:
It might solve a problem, but by introducing another one, as it removes a valid link. Page 8.1 (S) is Sceptre "solution first half" (1231) linked to URL www.crashonline.org.uk/68/tape.htm (2772). Page 8.2 (V) is Sceptre cover tape instructions on the same page and thus also linked to URL www.crashonline.org.uk/68/tape.htm (2772). As you point out, that's what the decimal digit on page is for, to distinguish otherwise similar entries without having to check the type as well. The idea was that the Infoseek code wouldn't have to be changed to handle multi-type entries on the same page, as it was already checking the page number. For display purposes 8.1 & 8.2 should be treated as different pages, which for the purposes of comparison they are, as the decimal digit is different.
D'oh, I misread your report and thought the problem was that the problem was creating a link at all! :oops:
I found the problem, but am baffled by why this is happening:
What I do to create the sorting sequence includes taking the page number and multiplying it by 10. This is the code:
For some as yet obscure reason, it believes that an input of 8.2 should result in 81 instead of 82, so the sequence gets the same value as with input 8.1.
Only an input of 8.2 appears to do this, all other page numbers get their correct values.
Using a double instead of a float makes no difference (of course).
Changing the 8.2 to 8.3 "fixes" the problem.
Does anyone have any idea why the calculation is broken?
Edit: although I'm still wondering what is wrong, I decided to write my own little subroutine to convert the string to an int. So it works as it should now.
It's probably a floating point rounding error... if the closest possible floating-point representation of 8.2 is actually 8.1999999999999, then casting to an int will cause 81.9999999999 it to be rounded down to 81. The same thing is liable to happen with a double, just with more decimal places involved.
The cheap and cheerful fix would be to add 0.000001 before casting to an int...
Probably true, but still rather shocking in my mind.
If even such a really simple number gets converted incorrectly, what does that say about the mathematics library?
If even such a really simple number gets converted incorrectly, what does that say about the mathematics library?
Nothing really. :-) It's a well-known gotcha with floating-point numbers as a concept, not any particular library: just as 1/3 can't be represented exactly in decimal places, 1/5 can't be represented exactly as a binary fraction.
Probably true, but still rather shocking in my mind.
If even such a really simple number gets converted incorrectly, what does that say about the mathematics library?
Mathematics libraries (like math.h) have specific functions for rounding, like round()/lround()/lrint() and many others.
These tricks are known for a while now, in fact, even in spectrum books that teaches about the INT function (like this one), will tell you that you should +.5 before using INT to make sure you're rounding off to the nearest integer. (Let's assume that they're talking about positive integers for the moment ;))
This is weird - I knew about adding .5 before casting it to an int, but completely forgot about this yesterday...
Can I plead temporary insanity? Perhaps caused by staring at the debugger for too many hours?
I knew about adding .5 before casting it to an int, but completely forgot about this yesterday...
Martijn, just in case you've modified your code to adding .5 before casting, beware that when you store floats into variables like 7.2, they can be stored as 7.19999 as well as 7.20001. If you add .5 you can solve problems like 7.19999, but you'll also create problems with 7.20001.
In these cases you should something a lot less than .5, just in case .5 get rounding errors as well :)
Martijn, just in case you've modified your code to adding .5 before casting, beware that when you store floats into variables like 7.2, they can be stored as 7.19999 as well as 7.20001. If you add .5 you can solve problems like 7.19999, but you'll also create problems with 7.20001.
In these cases you should something a lot less than .5, just in case .5 get rounding errors as well :)
As stated in post #17 in this thread, I use my own routine to determine page numbers now, which does not rely on floats and is therefore without problems. :-)
Comments
Thanks for the information; I was beginning to pull hairs (of my guinea pigs, not my own, mind. :razz:)
The link in the daily YS fix links to a page with an ad instead of a review. The same is in the infoseek database of Deliverance.
Who can I ask for this problem?
Games List 2016 - Games List 2015 - Games List 2014
Indeed that solved the problem.
Thanks, Battle Bunny!
It's on page 53 instead of page 51; this has been corrected in my local copy of SPOT, so Infoseek is now correct again.
Aha, I'll update mine too - good catch Timmy.
Games List 2016 - Games List 2015 - Games List 2014
That was quick - I just uploaded the update!
But let me again sing the praises of SPOT and Infoseek - there are 4699 virtual double-page spreads on the YSRnRY, and cross-referencing mistakes are very few and far between. SPOT and Infoseek helps make the YSRnRY look good.
Here's an example of where there is still a problem. Check the Crash 9.89 entries for Sceptre of Bagdad. The database has two entries for the same page, one for cover tape instructions (V) and one for a solution (S), but Infoseek shows the solution entry twice and doesn't show the cover tape entry at all. This is related to the solution entry actually comprising two records, one with a description and one with a URL; when merged for display the result gets jumbled. It only goes wrong when there is more than one type of entry for the same program on the same page and one of them is a paired entry with a separate description and URL.
However, since I still couldn't find it, I played with the SPOT data a bit.
I'm afraid the problem seems to be caused by the SPOT database... Infoseek follows the rule of page numbers along with a digit, which you invented to combat this exact problem, so that couldn't be it.
On close inspection, the Crash references are as follows:
Notice the last two entries both carry an FESEQ 2772.
Changing the FESEQ for the last line to '0' solves the problem.
I found the problem, but am baffled by why this is happening:
What I do to create the sorting sequence includes taking the page number and multiplying it by 10. This is the code: For some as yet obscure reason, it believes that an input of 8.2 should result in 81 instead of 82, so the sequence gets the same value as with input 8.1.
Only an input of 8.2 appears to do this, all other page numbers get their correct values.
Using a double instead of a float makes no difference (of course).
Changing the 8.2 to 8.3 "fixes" the problem.
Does anyone have any idea why the calculation is broken?
Edit: although I'm still wondering what is wrong, I decided to write my own little subroutine to convert the string to an int. So it works as it should now.
So it seems to be the cast to int which is the problem, as doing the calculation in two steps works. There's probably other numbers which do this. It seems such a simple thing that I'm inclined to think that I'm missing an obvious explanation.
Making it 2 steps doesn't work for me either.
This is the routine I now use instead:
int GetPageNum (char *PageNum) { char *Cp; int Result; Result = 0; Cp = PageNum; while (*Cp && (isdigit (*Cp) || *Cp == '.')) { if (isdigit (*Cp)) Result = Result * 10 + *Cp - '0'; Cp ++; } return (Result); }The cheap and cheerful fix would be to add 0.000001 before casting to an int...
If even such a really simple number gets converted incorrectly, what does that say about the mathematics library?
Nothing really. :-) It's a well-known gotcha with floating-point numbers as a concept, not any particular library: just as 1/3 can't be represented exactly in decimal places, 1/5 can't be represented exactly as a binary fraction.
These tricks are known for a while now, in fact, even in spectrum books that teaches about the INT function (like this one), will tell you that you should +.5 before using INT to make sure you're rounding off to the nearest integer. (Let's assume that they're talking about positive integers for the moment ;))
Games List 2016 - Games List 2015 - Games List 2014
Can I plead temporary insanity? Perhaps caused by staring at the debugger for too many hours?
In these cases you should something a lot less than .5, just in case .5 get rounding errors as well :)
Games List 2016 - Games List 2015 - Games List 2014
As stated in post #17 in this thread, I use my own routine to determine page numbers now, which does not rely on floats and is therefore without problems. :-)