почему-то гугл, который в пользовательском соглашении говорит, что письма автоматически анализируется вызывает доверия больше, чем почта России, которая говорит «что письма не анализируются»)
Технология 3D печати приносит как свои положительные стороны, так и отрицательные. Интернет, краудфандинг и 3D принтеры в конечном счете уничтожают рыночные отношения, а вместе с ними и капитализм. Плохо это или хорошо, зависит от того, как вы сами вписаны в капиталистическую систему, и готовы ли вы меняться вместе с миром. Наступает эпоха творчества = эпоха качества, а не количества. Количество теперь не имеет значение. Можно и дальше винтить гайки на старом предприятии. А можно поставить свой проект, к примеру, на кикстартер. Выбор как всегда остается за человеком.
Человек, который написал это, видимо, не до конца понимает, что такое рыночные отношения и капитализм)
посмотрите на особенности экономических отношений с общественными благами. Рыночные отношения это механизм координации в условиях ограниченных ресурсов)
От того, что издержки на тиражирование сильно упадут (как сегодня с цифровым контентом) рыночные отношения не пропадут, изменится структура рынков. Ценность будет создавать не тот кто физически воспроизводит товар, а тот кто лучше других понимает что нужно людям, какие у них потребности и за что они готовы платить (тратить свои ресурсы).
Кстати весь мир уже давно живет по этим законам, проблема производства (уже и без 3д принтеров) во многих отраслях вторична, относительно проблемы продажи. Ну будет человек тратить на физические товары 0-1% свое бюджета, посмотрите сколько занимают сейчас расходы, но исключительно нематериальные блага и услуги и станет ясно, что 3д принтеры это скорей логичное продолжение современных тенденций) Т.е. скорей это дальнейшая эволюция системы, а не революция)
Кстати, все эти изменения происходят исключительно по рыночным законам.
да, тоже бросилось в глаза, как палится командой glass и тупо отнекивается…
первое, что приходит в голову для решения: режим в котором формируется список из последних ключевых слов и фраз из услышанных и выбирается какой запрос сделать)
ровно в этом духе алгоритм сортировки на bogosort! while not isInOrder(deck):
shuffle(deck)
даже фразу последнюю менять не нужно: «Конечно, сейчас нет таких технологий, но с исследованными графена и квантовых компьютеров эта технология СОРТИРОВКИ станет новым стандартом СОРТИРОВКИ. „
вы правы, что сокращая 2 произвольных числа нет нужды оба полностью факторизировать, когда можно просто последовательно находить их Наибольшии общие делители) в том варианте который я рассматривал, где дробь ищется через обратное значение и переводится в целое умножением на 10 в степени N, факторизировать два числа нужды нет. И алгоритм евклида это частный способ факторизации)
правда ничего там не нужно факторизировать, чего -то я перемудрил (решая в общем случае, самое простое частное решение не поискал)… проверку делимости на 2 и на 5 можно сделать по последнему знаку)))
правда, как тут и тут уже отметили, возможно найти более компактное представление
поиск любого общего делителя это частный случай факторизации, разве нет?
впрочем, что тут обсуждать алгоритм, высосанный из фантазии шарлатана) (судя по всему его высказывания не признак больного ума, а признак «заведомо ложной информации»)
наверное можно обойтись последовательным перебором числителя (или знаменателя), а перебор знаменателя (числителя) не нужен
алгоритмическая сложность O(10^n) n — количество знаков после запятой ( = 2.4*число байт файла)
+
да это хорошая новость, что есть надежда, что можно найти получше значения чем факторизацией
правда плохая новость для алгоритма в этом примере, что для хранения двух чисел необходимы 9 + 11 бит (overhead на хранение точности, можно в рассчет не брать) при попытке закодировать 16 бит
Если поиск прямым перебором: то алгоритмическая сложность по-моему получается O(10^2n) — гыгы)
тому кто хоть для одного фильма найдет два таких числа (хоть и толку для архивации никакой — т.к. занимать они будут примерно в 1.5-2 раза больше места чем первоначальный фильм) можно претендовать на премию $150К от (Electronic Frontier Foundation) т.к. возможно что по дороге к применению этого «гениального» алгоритма к 2 гбайтному файлу придется разложить число на простые числа с парой десятков миллиардов цифр и возможно не получится отделаться известными простыми числами в 60 млн. знаков)
«100 million-digit prime number, could fetch a $150,000 prize from the Electronic Frontier Foundation, a San Francisco-based nonprofit.»
ключевое слово «эффективное сжатие»,
а тут чувак предлагает глупость (понять что это глупость а не алгоритм сжатия можно и на простом примере)
и если человечеству поставить цель снимать фильтмы, чтобы найти среди них такой, чтобы хоть 1 из них этим алгоритмом было бы можно сжать (хотябы не меньше своего объема) то возможно что до конца дней вселенной не найдется ни одного такого фильма))))
почему нельзя? обычная дедукция, несколько примеров могут помочь увидить закономерность — могут и не помочь конечно, но в данном случае мне немного помогло (впрочем, как и помогли Ваши сомнения, что ничего не надо делать — пока считал 2й пример для 10 байт ещё немного понял закономерности)
можно же понять как работает алгоритм… это лишь разложение на простые числа числителя и знаменателя,
числитель всегда оказывается числом 10 в степени N (т.к. десятичную дробь хочет чувак анализировать) это означает, что у него будет по N простых делителей 2 и 5) собственно только на них и может сократиться со знаменателем… вероятность, что в простых делителях знаменателя будет много чисел 2 и 5… можете сами посчитать сколько дожно быть этих простых делителей чтобы хотябы до первоночального представления данных добраться))хотя чего себя обанывать — ничего вы считать не будете)))
с моим алгоритом? боже упаси — я просто смеюсь над ним)))
да, да, уже когда строил тоже подумал, что нужно ещё служебную инфо хранить об интерпретации (но это тонкости) — даже оценка снизу получается полный швах) надежда, что у двух чисел (числителя и знаменателя) сопоставимых по размеру с первоначальным числом, будем много общих делителей (чтобы сильно сократилось) довольно наивная)
в теории чисел не силен и довольно смутно представляю картинку как факторизируются натуральные числа, но первый взгляд на распределение простых числе подсказывает, что надежды что у произвольного числа много делителей 2 и 5 не много (при переводе из десятичной дроби числитель всегда оказывается числом 10 в степени N это означаетс что у него будет по N простых делителей 2 и 5) собственно только на них и может сократиться…
посмотрел видео как гладить рубашку (генетическим алгоритмом примерно до этого и дошел) но узнал много новых слов (вру не знал, уже забыл половину — но услышал много новых слов «пуговичная планка» и т.п.)
гы-гы-гы)
возьмите не архиватор, а алгоритм архивации и хоть на одном байте эксперементируйте)
p.s. ровно так «в детстве» и заставляли делать на «теории информации»
хорошо, устроим более сложное испытание 10 байт:
1) 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x0A 0x09
2) десятичное представление: 1 2 3 4 5 6 7 8 10 9 (такой хреновый у меня в голове генератор)
3) 0.12345678109
1/0.12345678109 = 8.100001
4) 8100001 = 241*3361
ответ: два числа 1000000:8100001 ого наархивировали!
20 бит + 23 бита заархивировали 10 байт (80 бит). Только вот незадача, кодировали мы 10 4 битных чисел, а не 80 бит и упростили выкинув нолики. Архивация зашибись. Уверен, что автор придумал его (глупости просто придумывать с умными словами), а вот как реализовать не удосужился ( это же «невьебенно-большое число») и почему-то надеется, что будут идеально маленькие числа ))) — ну с кем не бывает
это напомниает собственный «гениальный» (как мне на секунду показалось) алгоритм оптимизации: «перебираем 100 переменных случайными значениями и ждем пока не выпадет оптимальной комбинации» — не находит? блин — выделяем больше ресурсов и ждем месяц (вдруг найдутся крутые оптимальные комбинации) — через месяц смотрим на лучшее, что нашлось — как был мусор так и остался)
«Алгоритм архивации таков: любой файл представляет собой HEX-последовательность символов, переводим этот HEX в DEC, получаем неебически-большое число, дописываем перед этим число 0, — получаем число в диапазоне от 0 до 1 с огромным числом знаков после запятой, а дальше всё просто — подбираем 2 таких целочисленных числа, частное которых даст нам искомое число в диапазоне от 0 до 1 с точностью совпадений до последнего знака.....»
спасибо, повесилили)
с нетерпением жду хотябы одного примера с результатами работы алгоритма для оч. частного случая (например для простенькой jpeg картинки)
нет, не могу ждать примера, так весело, что сам пытаюсь привести пример:
1) и так мы хотим «заархивировать файл длинною 2 байта „0xE8 0x9A“
2) десятичное представление 232 154 (»неебически-большое число")
3) 0.232154 ( дописываем перед этим число 0, — получаем число в диапазоне от 0 до 1 с огромным числом знаков после запятой)
4) подбираем 2 таких целочисленных числа, частное которых даст нам искомое число в диапазоне от 0 до 1 с точностью совпадений до последнего знака
1/0.232154 = 4.307486 = 4307486 / 1000000 = > упроситим (найдем все простые делители, холявлю пользуюсь функцией «factorize» в R из библиотеки «gmp»)
factorize(1000000) = 2 2 2 2 2 2 5 5 5 5 5 5
factorize(4307486) = 2 23 29 3229
(ура можно сократить 1 делитель = 2)
нашли два числа: 23*29*3229 = 2153743 (знаменатель)
500000 (числитель)
проверяем 500000/2153743 = 0.232154
ЗАШИБИСЬ ЗААРХИВИРОВАЛИ 2 байта «0xE8 0x9A» 2 числами 500000: 2153743
согласен, в таких вопросах речь идет о точности «разы порядков»)
т.е. разница между 8*17 и 8^18 не принципиальная)
(стоимость металоконструкции военного корабля около 10% от его конечной стоимости )
почему-то гугл, который в пользовательском соглашении говорит, что письма автоматически анализируется вызывает доверия больше, чем почта России, которая говорит «что письма не анализируются»)
Человек, который написал это, видимо, не до конца понимает, что такое рыночные отношения и капитализм)
посмотрите на особенности экономических отношений с общественными благами. Рыночные отношения это механизм координации в условиях ограниченных ресурсов)
От того, что издержки на тиражирование сильно упадут (как сегодня с цифровым контентом) рыночные отношения не пропадут, изменится структура рынков. Ценность будет создавать не тот кто физически воспроизводит товар, а тот кто лучше других понимает что нужно людям, какие у них потребности и за что они готовы платить (тратить свои ресурсы).
Кстати весь мир уже давно живет по этим законам, проблема производства (уже и без 3д принтеров) во многих отраслях вторична, относительно проблемы продажи. Ну будет человек тратить на физические товары 0-1% свое бюджета, посмотрите сколько занимают сейчас расходы, но исключительно нематериальные блага и услуги и станет ясно, что 3д принтеры это скорей логичное продолжение современных тенденций) Т.е. скорей это дальнейшая эволюция системы, а не революция)
Кстати, все эти изменения происходят исключительно по рыночным законам.
первое, что приходит в голову для решения: режим в котором формируется список из последних ключевых слов и фраз из услышанных и выбирается какой запрос сделать)
там много «важных интеллектуальных идей» на оч. простом (понятном) языке объясняется
while not isInOrder(deck): shuffle(deck)даже фразу последнюю менять не нужно: «Конечно, сейчас нет таких технологий, но с исследованными графена и квантовых компьютеров эта технология СОРТИРОВКИ станет новым стандартом СОРТИРОВКИ. „
правда ничего там не нужно факторизировать, чего -то я перемудрил (решая в общем случае, самое простое частное решение не поискал)… проверку делимости на 2 и на 5 можно сделать по последнему знаку)))
правда, как тут и тут уже отметили, возможно найти более компактное представление
впрочем, что тут обсуждать алгоритм, высосанный из фантазии шарлатана) (судя по всему его высказывания не признак больного ума, а признак «заведомо ложной информации»)
алгоритмическая сложность O(10^n) n — количество знаков после запятой ( = 2.4*число байт файла)
да это хорошая новость, что есть надежда, что можно найти получше значения чем факторизацией
правда плохая новость для алгоритма в этом примере, что для хранения двух чисел необходимы 9 + 11 бит (overhead на хранение точности, можно в рассчет не брать) при попытке закодировать 16 бит
Если поиск прямым перебором: то алгоритмическая сложность по-моему получается O(10^2n) — гыгы)
тому кто хоть для одного фильма найдет два таких числа (хоть и толку для архивации никакой — т.к. занимать они будут примерно в 1.5-2 раза больше места чем первоначальный фильм) можно претендовать на премию $150К от (Electronic Frontier Foundation) т.к. возможно что по дороге к применению этого «гениального» алгоритма к 2 гбайтному файлу придется разложить число на простые числа с парой десятков миллиардов цифр и возможно не получится отделаться известными простыми числами в 60 млн. знаков)
«100 million-digit prime number, could fetch a $150,000 prize from the Electronic Frontier Foundation, a San Francisco-based nonprofit.»
а тут чувак предлагает глупость (понять что это глупость а не алгоритм сжатия можно и на простом примере)
и если человечеству поставить цель снимать фильтмы, чтобы найти среди них такой, чтобы хоть 1 из них этим алгоритмом было бы можно сжать (хотябы не меньше своего объема) то возможно что до конца дней вселенной не найдется ни одного такого фильма))))
можно же понять как работает алгоритм… это лишь разложение на простые числа числителя и знаменателя,
числитель всегда оказывается числом 10 в степени N (т.к. десятичную дробь хочет чувак анализировать) это означает, что у него будет по N простых делителей 2 и 5) собственно только на них и может сократиться со знаменателем… вероятность, что в простых делителях знаменателя будет много чисел 2 и 5… можете сами посчитать сколько дожно быть этих простых делителей чтобы хотябы до первоночального представления данных добраться))хотя чего себя обанывать — ничего вы считать не будете)))
да, да, уже когда строил тоже подумал, что нужно ещё служебную инфо хранить об интерпретации (но это тонкости) — даже оценка снизу получается полный швах) надежда, что у двух чисел (числителя и знаменателя) сопоставимых по размеру с первоначальным числом, будем много общих делителей (чтобы сильно сократилось) довольно наивная)
в теории чисел не силен и довольно смутно представляю картинку как факторизируются натуральные числа, но первый взгляд на распределение простых числе подсказывает, что надежды что у произвольного числа много делителей 2 и 5 не много (при переводе из десятичной дроби числитель всегда оказывается числом 10 в степени N это означаетс что у него будет по N простых делителей 2 и 5) собственно только на них и может сократиться…
1/0.12345678109 = 8.10000059269
4) 810000059269= 71*181*63030119
ответ: два числа 100 000 000 000/810 000 059 269
2 числа (40 бит и 37 бит) заархивировали 10 байт (80 бит). правда кодировали мы 10 4 битных чисел, а не 80 бит и упростили выкинув нолики.
возьмите не архиватор, а алгоритм архивации и хоть на одном байте эксперементируйте)
p.s. ровно так «в детстве» и заставляли делать на «теории информации»
хорошо, устроим более сложное испытание 10 байт:
1) 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x0A 0x09
2) десятичное представление: 1 2 3 4 5 6 7 8 10 9 (такой хреновый у меня в голове генератор)
3) 0.12345678109
1/0.12345678109 = 8.100001
4) 8100001 = 241*3361
ответ: два числа 1000000:8100001 ого наархивировали!
20 бит + 23 бита заархивировали 10 байт (80 бит). Только вот незадача, кодировали мы 10 4 битных чисел, а не 80 бит и упростили выкинув нолики. Архивация зашибись. Уверен, что автор придумал его (глупости просто придумывать с умными словами), а вот как реализовать не удосужился ( это же «невьебенно-большое число») и почему-то надеется, что будут идеально маленькие числа ))) — ну с кем не бывает
это напомниает собственный «гениальный» (как мне на секунду показалось) алгоритм оптимизации: «перебираем 100 переменных случайными значениями и ждем пока не выпадет оптимальной комбинации» — не находит? блин — выделяем больше ресурсов и ждем месяц (вдруг найдутся крутые оптимальные комбинации) — через месяц смотрим на лучшее, что нашлось — как был мусор так и остался)
спасибо, повесилили)
с нетерпением жду хотябы одного примера с результатами работы алгоритма для оч. частного случая (например для простенькой jpeg картинки)
нет, не могу ждать примера, так весело, что сам пытаюсь привести пример:
1) и так мы хотим «заархивировать файл длинною 2 байта „0xE8 0x9A“
2) десятичное представление 232 154 (»неебически-большое число")
3) 0.232154 ( дописываем перед этим число 0, — получаем число в диапазоне от 0 до 1 с огромным числом знаков после запятой)
4) подбираем 2 таких целочисленных числа, частное которых даст нам искомое число в диапазоне от 0 до 1 с точностью совпадений до последнего знака
1/0.232154 = 4.307486 = 4307486 / 1000000 = > упроситим (найдем все простые делители, холявлю пользуюсь функцией «factorize» в R из библиотеки «gmp»)
factorize(1000000) = 2 2 2 2 2 2 5 5 5 5 5 5
factorize(4307486) = 2 23 29 3229
(ура можно сократить 1 делитель = 2)
нашли два числа: 23*29*3229 = 2153743 (знаменатель)
500000 (числитель)
проверяем 500000/2153743 = 0.232154
ЗАШИБИСЬ ЗААРХИВИРОВАЛИ 2 байта «0xE8 0x9A» 2 числами 500000: 2153743
продалжаю смеяться над алгоритмом (
— Ну, что вы милейший!
т.е. разница между 8*17 и 8^18 не принципиальная)
(стоимость металоконструкции военного корабля около 10% от его конечной стоимости )