Оригинал не читал, но могли бы взять встроенный AI в SC: запускали клиент с какой-то автоматизацией (логин/создать игру/подождать/получить итог) или использовали библиотеки.
И статистика и AI — это туфта, это не доказательство преимущества при идеальной стратегии. Даже для шахмат этого не доказали (только по статистике белые выигрывают чаще), а в SC степеней свободы и вариантов игр намного больше.
Во втором рабочие тоже проходят сквозь друг друга, иначе было бы невозможно добывать ресурсы большим кол-вом рабочих, они бы мешали друг друга. В первом рабочий ещё может пройти через боевые юниты, если рабочий отправлен на добычу ресурса (был финт-хак: можно было кликнуть по минералам, чтобы рабочий прошёл через свой или вражеский заслон насквозь, через глухую стену).
Это лишь спор о терминах, сути это не меняет. В сабже топика речь про «сжатие». К тому же JPEG умеет сжимать и без потерь ru.wikipedia.org/wiki/JPEG-LS
Да как же не причём — тоже алгоритм компрессии (если конечно сабж можно к ним вообще отнести)), хоть и с потерями, тоже работает на определённых частных случаях данных (фото). Дробями тоже можно приближать исходные данные с потерей точности (1/31 для числа выше), если это допустимо для конкретного вида данных.
Они хорошо работают на каком-то подмножестве входных файлов. Например, PPM — на текстах, JPEG — на фото, PNG — на графике и т. д.
Метод в сабже может сработать, скорее всего, на очень небольшом наборе искусственно сконструированных данных. Пример: если исходные файлы хранят десятичные представления дробей с большой точностью. Например, файл с 1 миллионом знаков после запятой дроби 23/713. Логично, что проще будет сохранить 23 и 713, чем мегабайт вида 0.0322580645161290032258064516129003225806451612900322580645161290…
Да это всё понятно… другими словами: сомнительно, что это может сработать (по крайней мере, пока не показано обратное на каких-то данных). Но приведённое выше док-во к данному методу не имеет никакого отношения и «строго» оно ничего не доказало по отношению к этому методу. Я лишь про это.
Ещё можно сжимать не целиком файл, а искать последовательности бит, которые хорошо представляются короткими дробями. Плюс можно сжимать с потерей точности, если дробь примерно равна исходной последовательности.
Вообще не очевидно, что это нельзя никак применить. Есть подозрение, что математически точно это не доказать, т. к. и существующие форматы данных математически точно не описаны. Даже если описать (хотя бы самый простой — plaintext с известными частотами букв/слогов/слов/фраз), то замучаешься доказывать, что их не сжать каким-то методом. А это придется отдельно доказывать для каждого формата…
Поэтому метод считаем не рабочим, пока не доказано обратное на практике)
Для несжимаемых проверка контрольной суммы всегда будет неуспешной
Почти всегда) Если исходный файл был как раз данные+контрольная_сумма (намеренно или случайно) и его заархивировали (без сжатия, т. к. алгоритм его не смог сжать), то операция разархивирования будет пытаться его разархивировать, т. к. найдет верную контрольную сумму. Только это всё уже далеко от сабжа)
Так тогда и доказывать надо, что этот алгоритм не подходит именно для какого-то типа данных, а не общий случай, что архиваторы не работают на белом шуме. Это неудачная попытка доказать умозрительную очевидность.
на 1-7 битов (http://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%B4_%D0%A5%D0%B0%D1%84%D1%84%D0%BC%D0%B0%D0%BD%D0%B0), можно заменять и большие группы, например, «if (» (http://ru.wikipedia.org/wiki/LZW).
Мне кажется, такое док-во не катит, т. к. про существующие алгоритмы сжатия аналогично можно доказать, что они не работают, но они ведь работают. Да, они учитывают особенности/избыточности существующих форматов, некоторые сжимают с потерями, но и этот странный алгоритм с делением может работать для каких-то наборов данных. Проще сказать, что «очевидно», что он почти никогда работать не будет)
По моим прикидкам близзард на абонентке за вов получает 24к$ примерно за десять минут игрового времени. А общие годовые прибыли того же близзарда за все их «цветные пиксели» исчисляется в миллиардах. Чьи же это миллиарды?
Если ты «честный гражданин», то причем тут 1000$? Это или мошенничество (если выдаёшь себя за владельца патента) или шантаж/вымогательство (если требуешь $ за то, чтобы не писать жалобу).
В последнем абзаце на лицо мошенничество, если выдают себя за владельца патента для выкачивания денег. И тут же пишут: «ведь мы не нарушили закон». В США законно мошенничество?
И статистика и AI — это туфта, это не доказательство преимущества при идеальной стратегии. Даже для шахмат этого не доказали (только по статистике белые выигрывают чаще), а в SC степеней свободы и вариантов игр намного больше.
Метод в сабже может сработать, скорее всего, на очень небольшом наборе искусственно сконструированных данных. Пример: если исходные файлы хранят десятичные представления дробей с большой точностью. Например, файл с 1 миллионом знаков после запятой дроби 23/713. Логично, что проще будет сохранить 23 и 713, чем мегабайт вида 0.0322580645161290032258064516129003225806451612900322580645161290…
Вообще не очевидно, что это нельзя никак применить. Есть подозрение, что математически точно это не доказать, т. к. и существующие форматы данных математически точно не описаны. Даже если описать (хотя бы самый простой — plaintext с известными частотами букв/слогов/слов/фраз), то замучаешься доказывать, что их не сжать каким-то методом. А это придется отдельно доказывать для каждого формата…
Поэтому метод считаем не рабочим, пока не доказано обратное на практике)
Почти всегда) Если исходный файл был как раз данные+контрольная_сумма (намеренно или случайно) и его заархивировали (без сжатия, т. к. алгоритм его не смог сжать), то операция разархивирования будет пытаться его разархивировать, т. к. найдет верную контрольную сумму. Только это всё уже далеко от сабжа)