|
__TOC__
== J ==
I smiled at that end comment, but there may be an issue with the choice of an end value to search over. It seems that unlike testing incrementing values you have to put a ceiling on the range searched for.
I do have to put in a ceiling - that gives me bound search time and protects me from "infinite loop" bugs while I'm playing with the code. But if a given value doesn't give me good results, it's trivial for me to multiply it by 10 and try again. I guess what I'm saying is that for this problem, this approach saved time for me. (But I guess you basically said this already, in your second paragraph.) --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 11:55, 3 May 2015 (UTC)
== Analysis ==
--[[User:Nigel Galloway|Nigel Galloway]] ([[User talk:Nigel Galloway|talk]]) 09:44, 5 May 2015 (UTC)
:Nigel, it's a great analysis, but technically adding an answer based on this is excluded from the task as I did not want people to just copy an analytical solution from somewhere (OEIS has one) and use that.
:What to do? Right now I've added a note to your example on the page to discourage others from going down the same route but left it in place.
:A workable compromise? --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 06:19, 12 May 2015 (UTC)
==Haskell version==
::Well you certainly seem to like these silly notes, certainly not a mathematician or a lawyer, so this should be interesting. According to the task description I should calculate the starting value. By what stretch of the English language do any of the solutions calculate the starting value?
::Let us compare my solution with the Python solution. On numerous combinatronics problems I have stressed the importance of separating the verification of candidates from the selection of candidates. In spite of this and whatever the drivel "Parameterised the number of sailors using an inner loop including the last mornings case" means the Python solution does not do this, and for that alone is worth no more than 0 out of 100.
Testing the Haskell version here with GHC 7.8.4 and finding that ''pure'' is out of scope.
::I contend that my solution does meet the task requirements because _ng verifies each candidate by applying the problems constrains using integer divisions and remainders and tests on remainders.
::The question is how do I select the candidates? To answer this I introduce the oxymoron 'honest sailors' as a literary device to add dramatic effect and a technical device to explain the selection.
Perhaps add '''Control.Applicative''' to the imports ? [[User:Hout|Hout]] ([[User talk:Hout|talk]]) 19:04, 28 October 2015 (UTC)
::The case when 4 sailors are honest and one dishonest is constructed as the initial basis:
<pre>
26 5
20 4
</pre>
::It is impossible to have 2 dishonest sailors unless at least 1 sailor is dishonest. So I suggest the case for 2 dishonest sailors is a proper subset of the set of solutions for 1 dishonest sailor which I shall represent as 20+g*20. I try each of these values against my verification procedure which returns false until g=2 giving the answer:
<pre>
96 19
76 15
60 12
</pre>
::It is impossible to have 3 dishonest sailors if at least 2 sailors are dishonest. So I suggest the case for 2 dishonest sailors is a proper subset of the set of solutions for 1 dishonest sailor which I shall represent as 60+g*80. I try each of these values against my verification procedure which returns true with g=0 giving the answer:
<pre>
121 24
96 19
76 15
60 12
</pre>
::It is impossible to have 4 dishonest sailors if at least 3 sailors are dishonest. So I suggest the case for 4 dishonest sailors is a proper subset of the set of solutions for 3 dishonest sailors which I shall represent as 60+g*320. I try each of these values against my verification procedure which returns false until g=2 giving the answer:
|