Комментарии 76
Суббота, вечер, наверно поэтому читал не Футамура, а Футурама
Ччерт… Я тоже прочитал «Футурама».
И я.
Это наглядное подтверждение тезиса о том, что при частичном изменении положения букв в слове, мы все равно можем ео прочесть, автоматически подбирая наиболее похожее слово из известных.
Я кстати обнаружил подвох только когда прочел английское написание этой фамилии в ссылке. Видимо потому, что я недостаточно знаю инлиш :)
Я кстати обнаружил подвох только когда прочел английское написание этой фамилии в ссылке. Видимо потому, что я недостаточно знаю инлиш :)
Либо это доказывает то, что человек чаще видит все так, как ему хочется, а не как все есть на самом деле.
П.С. тоже прочитал Футурама ^^
П.С. тоже прочитал Футурама ^^
Что такое Футурама?
Учите матчасть, уважаемый, вы на Хабре :)
Гугль я умею, да. Просто не во всех частях мира это часть обязательной культуры.
Это просто шутка, не принимайте на свой счёт.
Футурама — матчасть? omg…
imho = футурама — матчасть? lol: omg
ооода без тернарного выражения никуда)
Это наглядное подтверждение того, что вы читаете слишком много глупостей. Тот текст с «исследованием» о перестановке букв — фейк. Если переставить в нем буквы действительно случайным образом, то не сработает.
Первая и последняя буквы должны быть на своих местах, тогда фишка работает.
Тдгоа фкшиа ртбеоаат, ага.
Тогда фишка работает, ага.
drbugy длео грвиоот.
drbugy длео грвиоот.
Ну-ка, переведите мне что тут написано, я даже контекст дам.
Итак, тестирование… Кетсвачо мироалтаев наииккх ннеикраай не ввзеаыыт. Метал по виду крепкий и качественный.
Итак, тестирование… Кетсвачо мироалтаев наииккх ннеикраай не ввзеаыыт. Метал по виду крепкий и качественный.
Качество материалов никаких нареканий не вызывает. Но читать сложно.
На самом деле согласен, прочитать можно, но действительно на порядок сложнее, чем тот текст про исследование.
Качество материалов никаких нареканий не вызывает. ~ с 3 раза.
сложность зависит от длины между позицией где должна быть буква и там где она написана.
перескоки букв на одну-две позиции очень легко читаются. а в вашем примере дальность «перескока» в основном 3-5 позиций, это сложный пример.
перескоки букв на одну-две позиции очень легко читаются. а в вашем примере дальность «перескока» в основном 3-5 позиций, это сложный пример.
Я где то написал про случайный порядок перестановки? Ясное дело, что он не может быть случайным. У слова должен остаться узнаваемый оптический образ. Тот фейк, про который вы упоминаете — вовсе не фейк, а результат чьей то проделанной работы по нахождению таких образов. Я не вчитывался в какие то исследования на эту тему, но мне кажется, что там есть несколько параметров, расположение букв (крайние должны остаться на месте. следующие с концов желательно тоже), группы букв, которые можно разрушать а какие нельзя, типы самих переставляемых букв.
В этом смысле «Футамура» и «Футурама», имхо — идеальная пара, на глаз практически неразличимая.
Да и вообще теории териями, а практика без всяких глупостей доказывает этот тезис. У меня есть знакомый, он часто опечатывается в словах именно по типу неправильного порядка нажатия клавиш. Когда я читаю его письма ~90% слов читаются на ходу
В этом смысле «Футамура» и «Футурама», имхо — идеальная пара, на глаз практически неразличимая.
Да и вообще теории териями, а практика без всяких глупостей доказывает этот тезис. У меня есть знакомый, он часто опечатывается в словах именно по типу неправильного порядка нажатия клавиш. Когда я читаю его письма ~90% слов читаются на ходу
я заметил это, только после Вашего комментария о.О
Придётся делать свою проекцию Футурамы. С блэкджеком и шлюхами!
Если бы не ваш комментарий, я бы так и думал, что профессора зовут Футурама :))
Ой, реально )
Только ради этого коммента и открыл пост… ))))
Три проекции Футурамы…
Я не одинок…
Я не одинок…
А!!! Демон. Там было написано Футурама, пока я твой комент не прочел. Верни слово на место :)
Профессор Футурама
И я… надо больше отдыхать =)
Ой, я только после этого каммента заметил )
Хорошая статья, достаточно интересно, особенно помесь асма с PHP.
P.S. Ну и фамилия… Что-то она мне напомнила…
P.S. Ну и фамилия… Что-то она мне напомнила…
Полный крышеснос.
Прощай спокойный сон )
Прощай спокойный сон )
мне например лисп иногда подсказывает что какая-то «ветка» формы не будет достигнута никогда и показывает предупреждение :-Р
В IDEA тоже есть такая штука для Java.
Visual Studo тоже иногда такое показывает — unreachable code
Не понял почему этот пост в ненормальном программировании…
Разве суперкомпиляция — это ненормально? =)
А вообще, очень похожа на кусок из книги Душкина про Хаскель.
Правда он это вероятно тоже откуда-то спёр (как и целые главы их 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.
современные ФЯ умеют только частные случаи инверсии делать, для сопоставления с образцом:
1. константа
2. конструктор списка (head:tail), конструктор алгебраических типов (структуры, варианты)
3. некоторые умеют (x + 1) матчить (хз, зачем)
1. константа
2. конструктор списка (head:tail), конструктор алгебраических типов (структуры, варианты)
3. некоторые умеют (x + 1) матчить (хз, зачем)
Статья интересна, но что за брэйнфак использован в примерах? В шесть утра такое воспринимать сложновато…
Это Haskell. Тоже полный крышеснос.
скажите, а есть более осмысленные примеры применения этой техники, которые бы показали чем она сильнее тех способов анализа исполнения программ и оптимизаций, которые уже применяются в компиляторах?
Я думаю это просто обобщение техник, применяемых в компилляторах с красивыми названиями.
окей, для 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'а есть другие преимущества и его оптимизацией занимаются не столько времени, сколько занимаются оптимизациями императивных языков… Но тут мы ступаем на весьма зыбкую почву.
«скорость» языка это слишком мутное понятие, чтобы им оперировать
согласен, имеет смысл говорить о скорости реализации языка.
есть у меня определённые сомнения в том, что на десктопе так уж много задач, которые прямо «взлетят» от распараллеливания…
более-того ну возьмем мы автоматическое распараллеливание какой-нибудь десктопной программки на Haskell, в которой списки ([a]) автоматически превратились в параллельные массивы ([:a:]) и даже очень много функций принимающих списки автоматически распаралилились и стали принимать параллельные массивы… Где гарантия, что всё это станет действительно быстрее работать? А не начнётся пыхтение, сопение и переключение контекстов и постоянные проблемы с кэшем и синхронизацией?
Нет, я, конечно, не отрицаю, что на Haskell можно достаточно легко писать руками параллельные программы в стиле «share nothing». Только вот такие программы и на Си писать легко. Проблемы начинаются, когда возникает необходимость сделать «share something».
Я считаю на этом поле the next big thing это транзакционная память. Будет ли от неё счастье, мне пока не ясно до конца, но надежды есть…
более-того ну возьмем мы автоматическое распараллеливание какой-нибудь десктопной программки на Haskell, в которой списки ([a]) автоматически превратились в параллельные массивы ([:a:]) и даже очень много функций принимающих списки автоматически распаралилились и стали принимать параллельные массивы… Где гарантия, что всё это станет действительно быстрее работать? А не начнётся пыхтение, сопение и переключение контекстов и постоянные проблемы с кэшем и синхронизацией?
Нет, я, конечно, не отрицаю, что на Haskell можно достаточно легко писать руками параллельные программы в стиле «share nothing». Только вот такие программы и на Си писать легко. Проблемы начинаются, когда возникает необходимость сделать «share something».
Я считаю на этом поле the next big thing это транзакционная память. Будет ли от неё счастье, мне пока не ясно до конца, но надежды есть…
т.е. я вообще не считаю, что с императивными языками стоит возиться
ну в самом деле, не будете же вы делать оптимизацию ассемблерного кода, когда эти оптимизации проще делать на уровне, скажем, C++
ну в самом деле, не будете же вы делать оптимизацию ассемблерного кода, когда эти оптимизации проще делать на уровне, скажем, C++
т.е. я вообще не считаю, что с императивными языками стоит возиться
не понял почему.
ну в самом деле, не будете же вы делать оптимизацию ассемблерного кода, когда эти оптимизации проще делать на уровне, скажем, C++
опять не понял, что значит на уровне C++? большинство известных мне оптимизаций* делаются на уровне весьма себе низкоуровневого императивного IR. на выскоуровневом структурном IR делается незначительное число оптимизаций.
* — я говорю об императивщине.
> большинство известных мне оптимизаций* делаются на уровне весьма себе низкоуровневого императивного IR.
в статье как раз рассказывается про оптимизации на высоком уровне (частичные вычисления)
>> не понял почему.
потому что анализировать функциональный код проще
в статье как раз рассказывается про оптимизации на высоком уровне (частичные вычисления)
>> не понял почему.
потому что анализировать функциональный код проще
в статье как раз рассказывается про оптимизации на высоком уровне (частичные вычисления)
в статье функциональщина, я говорил про С++
потому что анализировать функциональный код проще
не думаю что уж сильно проще, где-то проще, а где-то сложнее… вот над fusion в GHC сколько бьются, никак сделать нормально не могут =)
и вообще вас разве привлекают только простые задачи? меня наоборот =)
спасибо, интересно
Вы в статье пишите код для вычисления площади квадрата, а говорите про вычисление объёма куба. Мысли разбегаются? :) Поправьте.
сначала был пример сложнее, но редукций оказалось слишком много, сократил )
Интересно, кажется именно об этом читал недавно вышедшей «Функциональном программировании на яхыке Хаскелл». Честно говоря, заметка значительно лучше объясняет эти вопросы. :)
Замечательная статья! Спасибо!
Очень интересно, реально ли воспользоваться идеей для написания компиляторов. Есть некая загвоздка — всё было бы прекрасно, если бы транслярор был написан на ассемблере, но сейчас трансляторы пишут на высокоуровневых языках. А это означает, что specialize(interpreter, code) вернёт код на том языке, на котором написан interpreter, а не на asm'е, к сожалению.
Очень интересно, реально ли воспользоваться идеей для написания компиляторов. Есть некая загвоздка — всё было бы прекрасно, если бы транслярор был написан на ассемблере, но сейчас трансляторы пишут на высокоуровневых языках. А это означает, что specialize(interpreter, code) вернёт код на том языке, на котором написан interpreter, а не на asm'е, к сожалению.
О-о-о! Долго думал что в этой идее не так и, наконец, понял!
Очевидно, нельзя написать такую specialize, которая смогла бы специализировать код на любом языке. Нужно некое внутреннее представление, которая specialize могла бы обрабатывать и функция перевода кода в это представление — это раз.
Далее. Какой код, как вы думаете, получится после применения specialize к этому внутреннему представлению? Правильно! Получится снова промежуточный код. А значит, нам нужно преобразовать его к исходному формату. То есть нам нужна ещё и функция перевода промежуточного кода в старый код.
Так вот! По сути компилятором (вернее, генератором кода), оказывается вторая переданная функция, а вовсе не specialize.
Таким образом, мы ничего нового не изобрели, а эта «магическая функция» specialize остаётся не более чем тем, чем она являлась первоначально — вычислителем константных выражений.
Очевидно, нельзя написать такую specialize, которая смогла бы специализировать код на любом языке. Нужно некое внутреннее представление, которая specialize могла бы обрабатывать и функция перевода кода в это представление — это раз.
Далее. Какой код, как вы думаете, получится после применения specialize к этому внутреннему представлению? Правильно! Получится снова промежуточный код. А значит, нам нужно преобразовать его к исходному формату. То есть нам нужна ещё и функция перевода промежуточного кода в старый код.
Так вот! По сути компилятором (вернее, генератором кода), оказывается вторая переданная функция, а вовсе не specialize.
Таким образом, мы ничего нового не изобрели, а эта «магическая функция» specialize остаётся не более чем тем, чем она являлась первоначально — вычислителем константных выражений.
>> Так вот! По сути компилятором (вернее, генератором кода), оказывается вторая переданная функция, а вовсе не specialize
разумеется
разумеется
ээээ я один до сих пор пытаюсь это осмыслить? оО
мне кажется в функции возведения в степень «1 → x» необязательно…
это для иллюстративных целей, чтобы было меньше редукций при вычислении
ти раза перечитал. пытался понять причем тут Футурама
очень интересный материал, но подача его, простите, весьма сумбурная.
Футамуре бы добавить нулевую проекцию: программа есть специализация возможностей языка процессом разработки.
И ещё «минус первую» проекцию: процесс разработки есть специализация возможностей разработчика конкретной задачей.
Отыскал свои высказывания шестилетней давности на эти темы:
www.jroller.com/deep/entry/cyber_telepathy_of_generative_programming
И ещё «минус первую» проекцию: процесс разработки есть специализация возможностей разработчика конкретной задачей.
Отыскал свои высказывания шестилетней давности на эти темы:
www.jroller.com/deep/entry/cyber_telepathy_of_generative_programming
А мне вот интересно что бы такое применить для борьбы с лесом зависимостей.
На примере 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 и не только