Talk:Find Chess960 starting position identifier: Difference between revisions

Content added Content deleted

Inline

Latest revision as of 15:42, 24 July 2022

The original Raku code was correct, but the text algorithm in the task description (and the Commodore BASIC code) was not. It called for discounting the knights instead of the bishops when determining the placement of the queen; unfortunately, with knight location ignoring the queen and queen location ignoring the knights, any position containing an adjacent queen and knight resulted in the same SP-ID no matter which order the two pieces were in. The upshot is that the algorithm would only ever return 708 of the 960 possible SP-IDs. I added two example positions to the text which demonstrate this problem: SP-IDs 601 and 617 both yield 601 from the bad algorithm.

Most of the submitted solutions replicated this error. Rather than mark them as incorrect – hardly fair, since they implemented the task as it was written at the time – I took the liberty of going through and correcting all of them (except J, which Rdm beat me to). In the case of solutions with a fixed set of examples, I also added the two suspect ones to the list. --Markjreed (talk) 15:39, 24 July 2022 (UTC)

Revision as of 15:41, 24 July 2022 (view source) Markjreed (talk \| contribs) mNo edit summary ← Older edit		Latest revision as of 15:42, 24 July 2022 (view source) Markjreed (talk \| contribs) mNo edit summary
Line 1:		Line 1:
	The original Raku code was correct, but the text algorithm in the task description (and the Commodore BASIC code) was not. It called for discounting the knights instead of the bishops when determining the placement of the queen; unfortunately, with knight location ignoring the queen ~~_and_~~ queen location ignoring the knights, any position containing an adjacent queen and knight resulted in the same SP-ID no matter which order the two pieces were in. The upshot is that the algorithm would only ever return 708 of the 960 possible SP-IDs. I added two example positions to the text which demonstrate this problem: SP-IDs 601 and 617 both yield 601 from the bad algorithm.		The original Raku code was correct, but the text algorithm in the task description (and the Commodore BASIC code) was not. It called for discounting the knights instead of the bishops when determining the placement of the queen; unfortunately, with knight location ignoring the queen <i>and</i> queen location ignoring the knights, any position containing an adjacent queen and knight resulted in the same SP-ID no matter which order the two pieces were in. The upshot is that the algorithm would only ever return 708 of the 960 possible SP-IDs. I added two example positions to the text which demonstrate this problem: SP-IDs 601 and 617 both yield 601 from the bad algorithm.

	Most of the submitted solutions replicated this error. Rather than mark them as incorrect – hardly fair, since they implemented the task as it was written at the time – I took the liberty of going through and correcting all of them (except J, which [[User:Rdm\|Rdm]] beat me to). In the case of solutions with a fixed set of examples, I also added the two suspect ones to the list. --[[User:Markjreed\|Markjreed]] ([[User talk:Markjreed\|talk]]) 15:39, 24 July 2022 (UTC)		Most of the submitted solutions replicated this error. Rather than mark them as incorrect – hardly fair, since they implemented the task as it was written at the time – I took the liberty of going through and correcting all of them (except J, which [[User:Rdm\|Rdm]] beat me to). In the case of solutions with a fixed set of examples, I also added the two suspect ones to the list. --[[User:Markjreed\|Markjreed]] ([[User talk:Markjreed\|talk]]) 15:39, 24 July 2022 (UTC)