Użytkownik "cbnet" <c...@n...pl> napisał w wiadomości
news:gd7k38$2bii$1@news2.ipartners.pl...
> Wydaje mi się, że w twojej metodzie ilość elementów w zbiorze
> potencjalnych rozwiązań po 4-ej odpowiedzi może być różna
> zależnie od konkretnej sytuacji i formalnie nie jest ściśle określona.
No to ja Ci mówię: NIE ;)

Przypomnę np. przykład trenera:
4. Is the number in: 1, 2, 3, 4?
Yes
Piątka przelatuje do K, 067 idzie w zapomnienie. Pozostaje:
C={4} K={1235}

Mamy jeden element w C, 4 w K ;)
Nie ma innej możliwości. W każdej iteracji ze zbioru C odpada zawsze połowa
elementów,
bo jak tak to wywalam jedną połówkę, jak nie - to drugą..
Podobnie z K - zawsze wywalam połowę a jednocześnie przyjmuję 'połówkę' z C.
0. N(C)=16 N(K) = 0
1. N(C)=16/2=8 N(K) = 0/2+16/2 = 8
2. N(C)=8/2=4 N(K) = 8/2+4 = 8
3. N(C)=4/2=2 N(K) = 8/2+2 = 6
4. N(C)=2/2=1 N(K) = 6/2 + 1 = 4

Przykład Trenera pokazuje, że między liczbami nie musi zachodzić zasada
odległości
bitowej - pojawia się ona dopiero, jeśli dobieramy liczby wg. klucza
bitowego (co
uczyniłem w osttnim przykładzie)
Za to, zgodnie z tym, co mówi JanB a wcześniej zauważył vB - to kwestia
odpowiedniej
permutacji. Jeśli się umówimy, że liczby 0-15 mają inne reprezentacje
bitowe, niż mają
'z nadania' (do przykładu trenera np. umawiamy się, że 4=1111), to Twoją
metodą
także możemy uzyskać po 4-tym pytaniu zbiór C={4} i K={1,2,3,4}.

Można się więc pokusić o twierdzenie, że Twoja ( ;) ) metoda po modyfikacji
typu "dowolnie przypisz 4-bitowe kombinacje do liczb 0-15" będzie generować
zapytania równie różnorodne jak metoda FT ;)