Keresés

Puzzles

#829-es hozzászólásban A1=3, A1=4 résznél hibás számok szerepelnek.

1 2 3 4 -> 43.252.450.475

1 2 4 3 -> 49.406.551.825

1 3 2 4 -> 48.665.421.671

1 3 4 2 -> 47.575.358.837

1 4 3 2 -> 33.763.518.268

1 4 2 3 -> 40.481.566.029

2 1 3 4 -> 54.238.230.744

2 1 4 3 -> 61.752.436.807

2 3 1 4 -> 47.012.097.221

2 3 4 1 -> 49.169.609.572

2 4 1 3 -> 38.091.331.757

2 4 3 1 -> 34.691.383.923

3 1 2 4 -> 58.839.955.950

3 1 4 2 -> 52.442.646.660

3 2 1 4 -> 42.604.568.949

3 2 4 1 -> 43.707.641.489

3 4 1 2 -> 33.619.464.666

3 4 2 1 -> 35.988.555.073

4 1 2 3 -> 54.252.499.496

4 1 3 2 -> 66.516.506.938

4 2 1 3 -> 50.436.771.360

4 2 3 1 -> 45.445.874.672

4 3 1 2 -> 49.198.235.024

4 3 2 1 -> 53.245.935.272

Az előző "eredményt" egy programhiba okozta.

Y14X3R390

Meg vannak őrülve ezek a bitek.

HAPPY gépem is talált valamit.

Ez azt jelenti, hogy az eddigiekhez képest még 7 puzzle-ról meg tudom mondani, hogy bizonyos orientációval, bizonyos mezőn, nem rakható le.

Ez jó, mert eddig mind triviális eset volt, ezek már nem azok.

Végre, KIWI fogott valamit.

Remélem nem egy újabb programhibát.

470 / Joshua Blackwood

De most már ne add fel!:)

Oké, ezt a módszert sincs miért tovább erőltetni.

Na, akkor eljutottam a 2017 októberi állapotig. :)

Mire nem jó a karácsonyi szünet. :)

A zöld mezőkön még egy kicsit jobbak is az értékek.

Nekifutok a (3,9)-es mezőnek, meglátjuk mennyi értelme volt itt számolgatni.

Ha sikerül faragni belőle akkor volt, ha nem sikerül, akkor csukjuk a boltot. :)

Érdemes megnézni Jef Bucas művét: https://e2.bucas.name

Böngésző segítségével megjeleníthető egy-egy tetszőleges tábla állapot.

Az URL-be paraméterként mezőről mezőre megadható hogy mi jelenjen meg.

Na, akkor most ott vagyok, mint 2016 májusában. :-P

A sebesség miatt újragondoltam a dolgot.

Maradok a 3 táblás módszernél, táblánkénti 2^30 bejegyzéssel.

Nincs extra címgenerálási várakoztatás és több szálon is bírja a memória.

A 3 táblázat némi trükközéssel összesen 10GB (4:4:2) lett.

A 3x3-as blokkok mérete 15,2 GB / blokk ( 76%-os kihasználtság ).

A lerakási sebesség egy szálon, azonosítással együtt 40 millió / mp feletti.

Következő lépés, hogy újraépítem a 196 blokkot. :)

Sikerült még faragni a 3x3-as cellák véletlenszerű azonosításának helyigényén. :)

A LUT-ok száma 4-re redukálódott, de az összméretük 9,25GB lett.

Cserébe a 3x3-as cella bitmátrix 13,56GB-ra zsugorodott.

Ez már elég közel van az elméleti 11,57GB-hoz.

Kb. 5 millió azonosítás / másodperc érhető el normál RAM használatával.

Szerencsére a memóriaárak is kezdenek visszaállni az özönvíz előtti szintre...

Mivel a Yahoo dec 14-én lehúzza a redőnyt az ottani levelező listáknak, így nyitottak egy új fórumot a Groups.io-n eternity2 néven.

3x3-as szűrés utáni állapot.

A nagyobbakhoz kicsit át kell írnom a programot.

Kb. 10x10-ig lehet gyorsan lefuttatni, utána belassul.

Tipp: 4x4-es kiszűr még 2-őt 15,13-on aztán nagy csönd... :)

ROT tábla 2x2-es szűrés után.

Azt hittem, hogy már ebben a körben kihullanak az eddig is kiszűrt elemek.

Majd posztolom a 3x3-as szűrés utáni állapotot is.

Az előbb ellenőriztem, hogy a Q(2,2)-őn lévő 153.182.029 kombinációból 7.648 "hasonlóságot" mutat valamelyik másikkal.

Ez azt jelenti, hogy ugyanazon puzzle darabokból épül fel és a külső éleik is azonos színűek.

Ez jó... mert ha nem is nagyot, de végre belerúghatok pár mumusba. :-P

Végül is harmadára ( 42GB -> 14,4GB ) sikerült levinni a 3x3-as cellák tárolási blokkméretét.

Az is kiderült, hogy maximum 104.547.960.937 különböző 3x3-as puzzle darabka közül kell kiválasztani azokat amelyek lefedik a táblát.

Ezt sikerült 123.412.020.768 biten ( 14,4GB ) reprezentálni.

Összesen 7 look-up táblát ( ~ 3,4GB adat ) használtam a konvetáláshoz.

Korábban csak 3-at használtam, 8GB adattal.

Köszönöm, bár én is egyre ritkábban tévedek ide. :)

Amíg nem csökken le a memóriák ára legalább a két évvel ezelőtti szintre, addig nagyon nem is lesz előrelépés.

Jelenleg a 916-osban említett metódust reszelgetem, de ez is csak helyben toporgás. Kell a sok RAM. :)

Te aztan nagyon kitarto vagy! Nekem mar 25 masik kihivas jott, azokkal foglalkozom, de elotted meg le a kalappal!

Extrém módon lebutítva: 22,73 órajel / lépés, 25 perces mintán.

XEON E5-2697v2 ( Ivy Bridge EP )

Áttérek az eltérő méretű mezők szűrésére.

A mezők méretét a memória és a számítási kapacitás korlátozza.

Jelenleg egy mező 8-21 puzzle kiterjedésű és 1-32GB méretű.

Összesen 373 mező van a listámon ( ~ 8TB ).

Még keresem, hogy tudok-e további mezőket is bevonni.

Kulcs darabok elhelyezkedése (X,Y,orientáció).

X=0..15, Y=0..15, orientáció=0°,90°,180°,270°

0°-os orientációnál a sarokelemek szürke oldalai a bal illetve alsó széleken látható.

Elforgatás az óramutató járásával egyező irányban.

208 -> (2,2,+270°)

255 -> (13,2,+270°)

139 -> (7,8,+180°)

181 -> (2,13,+270°)

249 -> (13,13,+0°)

Na, nem boldogultam a dologgal, úgyhogy még az újévi fogadalom keretében feladtam a keresést.

A napokban viszont eszembe jutott egy módszer ami egészen más módon közelíti a problémát.

Úgyhogy, felfüggesztettem az újévi fogadalmat. :P

Új sebességrekordot értem el a Brute Force keresővel: ~24,96 CPU órajel / lépés.

( XEON E5-1620v3 - Haswell )

Az eredeti szabályok szerint a darabok színes oldalainak mind a 480 helyen illeszkedni kell.

A srác annyiban módosította a szabályokat, hogy a szürkét is színnek tekintette.

Ez tetszik:) Bar baromi regen volt, megis mintha remlene, hogy a szabaly a szeleken is illeszkedest kert. Aztan tevedhetek. (Ertsd: ha ugy volt, akkor nem kibovitette, hanem szukitette a szabalyokat, aminek a kirakas megfelel.)

peter.mcgavin@callaghaninnovation.govt.nz:

Kicsit kibővítette a srác a szabályokat, de E2 tábla eredeti darabokkal lefedve, minden illeszkedik.

A kezdő elem maradt a helyén, de a szélső elemeket is "interior" elemként használta.

Na, jelenleg itt tartok...: