Комментарии 76
Суббота, вечер, наверно поэтому читал не Футамура, а Футурама
Ччерт… Я тоже прочитал «Футурама».
И я.
Это наглядное подтверждение тезиса о том, что при частичном изменении положения букв в слове, мы все равно можем ео прочесть, автоматически подбирая наиболее похожее слово из известных.
Я кстати обнаружил подвох только когда прочел английское написание этой фамилии в ссылке. Видимо потому, что я недостаточно знаю инлиш :)
Я кстати обнаружил подвох только когда прочел английское написание этой фамилии в ссылке. Видимо потому, что я недостаточно знаю инлиш :)
Либо это доказывает то, что человек чаще видит все так, как ему хочется, а не как все есть на самом деле.
П.С. тоже прочитал Футурама ^^
П.С. тоже прочитал Футурама ^^
Что такое Футурама?
Учите матчасть, уважаемый, вы на Хабре :)
Это наглядное подтверждение того, что вы читаете слишком много глупостей. Тот текст с «исследованием» о перестановке букв — фейк. Если переставить в нем буквы действительно случайным образом, то не сработает.
Первая и последняя буквы должны быть на своих местах, тогда фишка работает.
Тдгоа фкшиа ртбеоаат, ага.
Ну-ка, переведите мне что тут написано, я даже контекст дам.
Итак, тестирование… Кетсвачо мироалтаев наииккх ннеикраай не ввзеаыыт. Метал по виду крепкий и качественный.
Итак, тестирование… Кетсвачо мироалтаев наииккх ннеикраай не ввзеаыыт. Метал по виду крепкий и качественный.
Качество материалов никаких нареканий не вызывает. Но читать сложно.
Качество материалов никаких нареканий не вызывает. ~ с 3 раза.
сложность зависит от длины между позицией где должна быть буква и там где она написана.
перескоки букв на одну-две позиции очень легко читаются. а в вашем примере дальность «перескока» в основном 3-5 позиций, это сложный пример.
перескоки букв на одну-две позиции очень легко читаются. а в вашем примере дальность «перескока» в основном 3-5 позиций, это сложный пример.
Я где то написал про случайный порядок перестановки? Ясное дело, что он не может быть случайным. У слова должен остаться узнаваемый оптический образ. Тот фейк, про который вы упоминаете — вовсе не фейк, а результат чьей то проделанной работы по нахождению таких образов. Я не вчитывался в какие то исследования на эту тему, но мне кажется, что там есть несколько параметров, расположение букв (крайние должны остаться на месте. следующие с концов желательно тоже), группы букв, которые можно разрушать а какие нельзя, типы самих переставляемых букв.
В этом смысле «Футамура» и «Футурама», имхо — идеальная пара, на глаз практически неразличимая.
Да и вообще теории териями, а практика без всяких глупостей доказывает этот тезис. У меня есть знакомый, он часто опечатывается в словах именно по типу неправильного порядка нажатия клавиш. Когда я читаю его письма ~90% слов читаются на ходу
В этом смысле «Футамура» и «Футурама», имхо — идеальная пара, на глаз практически неразличимая.
Да и вообще теории териями, а практика без всяких глупостей доказывает этот тезис. У меня есть знакомый, он часто опечатывается в словах именно по типу неправильного порядка нажатия клавиш. Когда я читаю его письма ~90% слов читаются на ходу
я заметил это, только после Вашего комментария о.О
Придётся делать свою проекцию Футурамы. С блэкджеком и шлюхами!
Если бы не ваш комментарий, я бы так и думал, что профессора зовут Футурама :))
Ой, реально )
Только ради этого коммента и открыл пост… ))))
Три проекции Футурамы…
Я не одинок…
Я не одинок…
А!!! Демон. Там было написано Футурама, пока я твой комент не прочел. Верни слово на место :)
Профессор Футурама
И я… надо больше отдыхать =)
Ой, я только после этого каммента заметил )
Хорошая статья, достаточно интересно, особенно помесь асма с PHP.
P.S. Ну и фамилия… Что-то она мне напомнила…
P.S. Ну и фамилия… Что-то она мне напомнила…
Полный крышеснос.
Прощай спокойный сон )
Прощай спокойный сон )
НЛО прилетело и опубликовало эту надпись здесь
мне например лисп иногда подсказывает что какая-то «ветка» формы не будет достигнута никогда и показывает предупреждение :-Р
Не понял почему этот пост в ненормальном программировании…
Разве суперкомпиляция — это ненормально? =)
А вообще, очень похожа на кусок из книги Душкина про Хаскель.
Правда он это вероятно тоже откуда-то спёр (как и целые главы их YAHT) =)
Разве суперкомпиляция — это ненормально? =)
А вообще, очень похожа на кусок из книги Душкина про Хаскель.
Правда он это вероятно тоже откуда-то спёр (как и целые главы их YAHT) =)
Спасибо, интересно, правда не сказать чтоб не знакомо.
Как раз сегодня писал о Прологе и вскользь касался Рефала.
Не совсем понял логику 4 пункта, а именно связь между суперкомпиляцией, инвертированием и pattern matching ). В прологе, многие предикаты и так уже инвертированы, например,
И коль уж зашла речь, функцию всех подстрок длины 2 можно реализовать так:
пример работы:
Как раз сегодня писал о Прологе и вскользь касался Рефала.
Не совсем понял логику 4 пункта, а именно связь между суперкомпиляцией, инвертированием и pattern matching ). В прологе, многие предикаты и так уже инвертированы, например,
7 ?- concat(a,bc,D).
D = abc
8 ?- concat(A,B,abc).
A = '',
B = abc;
A = a,
B = bc;
A = ab,
B = c;
A = abc,
B = ''
9 ?- concat(a,bc,abc).
Yes
И коль уж зашла речь, функцию всех подстрок длины 2 можно реализовать так:
% S - все подстроки Str
substr(S, Str) :-
concat(_, S1, Str),
concat(S, _, S1).
% S2 - все подстроки длины 2
substr2(S2, Str) :-
substr(S2, Str),
atom_length(S2, 2).
* This source code was highlighted with Source Code Highlighter.пример работы:
10 ?- substr2(S2,abbc).
S2 = ab;
S2 = bb;
S2 = bc;
No
связь между инверсией и сопоставлением с образцом такая:
образец — это функция, вычисление
вот мы хотим сопоставить что-то с образцом; это «что-то» — результат вычисления, выход функции
также мы можем указать какие-то известные входы функции в образце
нам нужно вычислить недостающие (неизвестные) входы этой функции, чтобы выполнить «pattern match»
а для этого нужно прогнать вычисление от выхода к входам, наоборот, т.е. получить инвертированный алгоритм
пример:
sum a b = a + b
case 5 of
(sum x 3) → print x
выведет 2
а про связь между инвертированием и компиляцией можно у того же Турчина почитать:
portal.acm.org/citation.cfm?doid=96877.96953
We proved by construction an application considered theoretically by Turchin [7] that self-application of metacomputation will allow the automatic construction of inverse algorithms, in particular the algorithm of binary subtraction from the algorithm of binary addition.
образец — это функция, вычисление
вот мы хотим сопоставить что-то с образцом; это «что-то» — результат вычисления, выход функции
также мы можем указать какие-то известные входы функции в образце
нам нужно вычислить недостающие (неизвестные) входы этой функции, чтобы выполнить «pattern match»
а для этого нужно прогнать вычисление от выхода к входам, наоборот, т.е. получить инвертированный алгоритм
пример:
sum a b = a + b
case 5 of
(sum x 3) → print x
выведет 2
а про связь между инвертированием и компиляцией можно у того же Турчина почитать:
portal.acm.org/citation.cfm?doid=96877.96953
We proved by construction an application considered theoretically by Turchin [7] that self-application of metacomputation will allow the automatic construction of inverse algorithms, in particular the algorithm of binary subtraction from the algorithm of binary addition.
Статья интересна, но что за брэйнфак использован в примерах? В шесть утра такое воспринимать сложновато…
скажите, а есть более осмысленные примеры применения этой техники, которые бы показали чем она сильнее тех способов анализа исполнения программ и оптимизаций, которые уже применяются в компиляторах?
Я думаю это просто обобщение техник, применяемых в компилляторах с красивыми названиями.
окей, для Haskell понятно, а как с императивными быть?
// в статье кстати красивый график есть, к которому заглавие «А Си быстрее и без суперкомпиляции» подходит =)
// в статье кстати красивый график есть, к которому заглавие «А Си быстрее и без суперкомпиляции» подходит =)
не знаю, как с императивными быть — в этом и бич императивных языков, из-за функционально нечистой семантики к ним тяжело применять методы math reasoning
в статье есть ссылка на попытку сделать суперкомпилятор для Java, но что-то у них не пошло
а C не быстрее, C — более explicit, так же, как assembler vs. C
задача в том, чтобы сделать функциональный код как минимум не медленнее вручную написанного
в статье есть ссылка на попытку сделать суперкомпилятор для Java, но что-то у них не пошло
а C не быстрее, C — более explicit, так же, как assembler vs. C
задача в том, чтобы сделать функциональный код как минимум не медленнее вручную написанного
а C не быстрее, C — более explicit, так же, как assembler vs. CM
Ну не надо противопоставлять теплое мягкому. explicit это одно свойство языка, а скорость — это совершенно другое.
Графики явно показывают, что С быстрее… Конечно, можно возразить, что у Haskell'а есть другие преимущества и его оптимизацией занимаются не столько времени, сколько занимаются оптимизациями императивных языков… Но тут мы ступаем на весьма зыбкую почву.
«скорость» языка это слишком мутное понятие, чтобы им оперировать
Ну вот года через три будет стоять у всех по 10 ядер на машине. Все сишные программы придётся распараллеливать вручную. Геморрой.
С функциональными значительно всё проще, вплоть до автоматического распараллеливания. Посмотрим, вдруг и окажется так, что хаскель быстрее си будет.
С функциональными значительно всё проще, вплоть до автоматического распараллеливания. Посмотрим, вдруг и окажется так, что хаскель быстрее си будет.
есть у меня определённые сомнения в том, что на десктопе так уж много задач, которые прямо «взлетят» от распараллеливания…
более-того ну возьмем мы автоматическое распараллеливание какой-нибудь десктопной программки на Haskell, в которой списки ([a]) автоматически превратились в параллельные массивы ([:a:]) и даже очень много функций принимающих списки автоматически распаралилились и стали принимать параллельные массивы… Где гарантия, что всё это станет действительно быстрее работать? А не начнётся пыхтение, сопение и переключение контекстов и постоянные проблемы с кэшем и синхронизацией?
Нет, я, конечно, не отрицаю, что на Haskell можно достаточно легко писать руками параллельные программы в стиле «share nothing». Только вот такие программы и на Си писать легко. Проблемы начинаются, когда возникает необходимость сделать «share something».
Я считаю на этом поле the next big thing это транзакционная память. Будет ли от неё счастье, мне пока не ясно до конца, но надежды есть…
более-того ну возьмем мы автоматическое распараллеливание какой-нибудь десктопной программки на Haskell, в которой списки ([a]) автоматически превратились в параллельные массивы ([:a:]) и даже очень много функций принимающих списки автоматически распаралилились и стали принимать параллельные массивы… Где гарантия, что всё это станет действительно быстрее работать? А не начнётся пыхтение, сопение и переключение контекстов и постоянные проблемы с кэшем и синхронизацией?
Нет, я, конечно, не отрицаю, что на Haskell можно достаточно легко писать руками параллельные программы в стиле «share nothing». Только вот такие программы и на Си писать легко. Проблемы начинаются, когда возникает необходимость сделать «share something».
Я считаю на этом поле the next big thing это транзакционная память. Будет ли от неё счастье, мне пока не ясно до конца, но надежды есть…
> есть у меня определённые сомнения в том, что на десктопе так уж много задач, которые
> прямо «взлетят» от распараллеливания…
Я тоже не думаю, что взлетят. Скорее, появится поле для реализации более сложных функций. Помните время, когда проверка правильности текста выполнялась отдельно от его ввода? А потом в Office 2000 (если не в 97) текст стал проверяться «на лету». Машины дорасли. Но тогда всё это делалось на одном процессоре, а тут, пожалуйста — ещё несколько таких же процессоров под боком.
Из того, что у всех на виду, ожидаю серьёзных прорывов в компьютерных играх. Там производительность всегда актуальна.
Вот с точки зрения прикладного разработчика не всё однозначно. Но вот, скажем, такая частая операция, как построение отчётов, параллелится влёт.
> Где гарантия, что всё это станет действительно быстрее работать? А не начнётся
> пыхтение, сопение и переключение контекстов и постоянные проблемы с кэшем и
> синхронизацией?
Вот тут не могу сказать. Насколько я представляю ситуацию сейчас, требуется определённый опыт параллельного программирования, чтобы избегать «опасных» способов распараллеливания. То есть, по сути, надо заставлять себя учиться новым способам думания. Но освоение функциональных языков в том числе предполагает изучение правильных способов думания.
> Только вот такие программы и на Си писать легко. Проблемы начинаются, когда
> возникает необходимость сделать «share something».
Я бы не сказал, что легко. Можно, но слишком многословно, и слишком нетрадиционно. Был у меня опыт написания библиотеки нечёткой логики на Си++, воспоминания весёлые. :) Закончилось тем, что когда я этот код пытался показывать другим программистам, они его не понимали, потому что воспринимали императивно. :)
Да, так вот, по поводу разделения ресурсов. Вы, конечно, правы. Но тут без конкретики уже очень сложно обсуждать. Вы приведёте мне проблему, которая не параллелится, я буду приводить проблему, которая хорошо параллелится, и так мы можем впасть в вечный цикл. :)
> прямо «взлетят» от распараллеливания…
Я тоже не думаю, что взлетят. Скорее, появится поле для реализации более сложных функций. Помните время, когда проверка правильности текста выполнялась отдельно от его ввода? А потом в Office 2000 (если не в 97) текст стал проверяться «на лету». Машины дорасли. Но тогда всё это делалось на одном процессоре, а тут, пожалуйста — ещё несколько таких же процессоров под боком.
Из того, что у всех на виду, ожидаю серьёзных прорывов в компьютерных играх. Там производительность всегда актуальна.
Вот с точки зрения прикладного разработчика не всё однозначно. Но вот, скажем, такая частая операция, как построение отчётов, параллелится влёт.
> Где гарантия, что всё это станет действительно быстрее работать? А не начнётся
> пыхтение, сопение и переключение контекстов и постоянные проблемы с кэшем и
> синхронизацией?
Вот тут не могу сказать. Насколько я представляю ситуацию сейчас, требуется определённый опыт параллельного программирования, чтобы избегать «опасных» способов распараллеливания. То есть, по сути, надо заставлять себя учиться новым способам думания. Но освоение функциональных языков в том числе предполагает изучение правильных способов думания.
> Только вот такие программы и на Си писать легко. Проблемы начинаются, когда
> возникает необходимость сделать «share something».
Я бы не сказал, что легко. Можно, но слишком многословно, и слишком нетрадиционно. Был у меня опыт написания библиотеки нечёткой логики на Си++, воспоминания весёлые. :) Закончилось тем, что когда я этот код пытался показывать другим программистам, они его не понимали, потому что воспринимали императивно. :)
Да, так вот, по поводу разделения ресурсов. Вы, конечно, правы. Но тут без конкретики уже очень сложно обсуждать. Вы приведёте мне проблему, которая не параллелится, я буду приводить проблему, которая хорошо параллелится, и так мы можем впасть в вечный цикл. :)
т.е. я вообще не считаю, что с императивными языками стоит возиться
ну в самом деле, не будете же вы делать оптимизацию ассемблерного кода, когда эти оптимизации проще делать на уровне, скажем, C++
ну в самом деле, не будете же вы делать оптимизацию ассемблерного кода, когда эти оптимизации проще делать на уровне, скажем, C++
т.е. я вообще не считаю, что с императивными языками стоит возиться
не понял почему.
ну в самом деле, не будете же вы делать оптимизацию ассемблерного кода, когда эти оптимизации проще делать на уровне, скажем, C++
опять не понял, что значит на уровне C++? большинство известных мне оптимизаций* делаются на уровне весьма себе низкоуровневого императивного IR. на выскоуровневом структурном IR делается незначительное число оптимизаций.
* — я говорю об императивщине.
> большинство известных мне оптимизаций* делаются на уровне весьма себе низкоуровневого императивного IR.
в статье как раз рассказывается про оптимизации на высоком уровне (частичные вычисления)
>> не понял почему.
потому что анализировать функциональный код проще
в статье как раз рассказывается про оптимизации на высоком уровне (частичные вычисления)
>> не понял почему.
потому что анализировать функциональный код проще
в статье как раз рассказывается про оптимизации на высоком уровне (частичные вычисления)
в статье функциональщина, я говорил про С++
потому что анализировать функциональный код проще
не думаю что уж сильно проще, где-то проще, а где-то сложнее… вот над fusion в GHC сколько бьются, никак сделать нормально не могут =)
и вообще вас разве привлекают только простые задачи? меня наоборот =)
спасибо, интересно
Вы в статье пишите код для вычисления площади квадрата, а говорите про вычисление объёма куба. Мысли разбегаются? :) Поправьте.
Интересно, кажется именно об этом читал недавно вышедшей «Функциональном программировании на яхыке Хаскелл». Честно говоря, заметка значительно лучше объясняет эти вопросы. :)
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
ээээ я один до сих пор пытаюсь это осмыслить? оО
мне кажется в функции возведения в степень «1 → x» необязательно…
ти раза перечитал. пытался понять причем тут Футурама
очень интересный материал, но подача его, простите, весьма сумбурная.
НЛО прилетело и опубликовало эту надпись здесь
А мне вот интересно что бы такое применить для борьбы с лесом зависимостей.
На примере unix — некая программа может быть скомпилирована с поддержкой библиотек A, B, C. А может обойтись и без них. Например, с поддержкой JPG, PNG, X11 или без части из них. Это отразится на ее функциональности, но про это мы можем знать заранее. Далее — есть дистрибутивы ОС. Они поставляются с предкомпилированными программами. При инсталляции есть варианты выбора вида инсталляции — с X11 и без оного. Вопрос в том как отрубить у готовых бинарников лишние зависимости? Т.е как вести разработку программ и их оформление чтобы это отрубание происходило без их пере компиляции? Вроде эта задача может иметь решение в отличии от оптимизации любого кода? :)
Если обобщать — как оптимизировать программу зная не фиксированные параметры, а перечни или диапазоны параметров. Или же от обратного — зная те диапазоны параметров, которые заведомо не будут поданы на вход программе.
Или же еще по другому — отсекать диапазоны входных значений на уровне их ввода, а не на уровне использования. При этом оставляя ту же программу — без пере компиляции способную включить требуемую функциональность. Пример — как только появляется библитотека Mysql включить поддержку ее не пересобирая с соответствующей libmysqlclient, но при этом не валиться в core, если пользователь укажет на входе ключик -connect-mysql.
Сейчас по большей части в C это решается через условную компиляцию и #ifdef.
Может есть уже готовые решения?
ps. в давние времена был забавный глюк в некоей IDE — если в программе на C не встречалось ни одного дробного числа в явном виде, то в printf переставало обрабатываться %f — вывод чисел с плавающей запятой. :)
На примере unix — некая программа может быть скомпилирована с поддержкой библиотек A, B, C. А может обойтись и без них. Например, с поддержкой JPG, PNG, X11 или без части из них. Это отразится на ее функциональности, но про это мы можем знать заранее. Далее — есть дистрибутивы ОС. Они поставляются с предкомпилированными программами. При инсталляции есть варианты выбора вида инсталляции — с X11 и без оного. Вопрос в том как отрубить у готовых бинарников лишние зависимости? Т.е как вести разработку программ и их оформление чтобы это отрубание происходило без их пере компиляции? Вроде эта задача может иметь решение в отличии от оптимизации любого кода? :)
Если обобщать — как оптимизировать программу зная не фиксированные параметры, а перечни или диапазоны параметров. Или же от обратного — зная те диапазоны параметров, которые заведомо не будут поданы на вход программе.
Или же еще по другому — отсекать диапазоны входных значений на уровне их ввода, а не на уровне использования. При этом оставляя ту же программу — без пере компиляции способную включить требуемую функциональность. Пример — как только появляется библитотека Mysql включить поддержку ее не пересобирая с соответствующей libmysqlclient, но при этом не валиться в core, если пользователь укажет на входе ключик -connect-mysql.
Сейчас по большей части в C это решается через условную компиляцию и #ifdef.
Может есть уже готовые решения?
ps. в давние времена был забавный глюк в некоей IDE — если в программе на C не встречалось ни одного дробного числа в явном виде, то в printf переставало обрабатываться %f — вывод чисел с плавающей запятой. :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Three Futamura Projections и не только