|
ru.algorithms
- RU.ALGORITHMS ----------------------------------------------------------------
From : Andrew Ezhguroff 2:5020/400 10 Oct 2002 03:51:51
To : Pavel P
Subject : Re: Как закодировать?
--------------------------------------------------------------------------------
From: "Andrew Ezhguroff" <eandr@com2com.ru>
Привет! "Pavel P" <vprin@indiainfo.com> сообщил(а):
>> А где ты до этого у меня слова о длине программы видел? Hо если так
PP> желаешь,
PP> Зачем писать больше если можно меньше и понятнее? (1)
Я не считаю, что лямбда-исчисление в ОБЩЕМ случае более понятно, чем
императивная грамматика. Эта нотация хороша для очевидно рекурсивных
алгоритмов - то же преобразование числа в строку, обработка списков и
деревьев, или, например, быстрая сортировка. Hо вот насколько она хороша для
пирамидальной сортировки, или сортировки слиянием?
>> то, насколько я помню, на Forth эта программа будет в несколько раз
>> короче твоего варианта. :-)
PP> Уверен? Чего то я там строк не припомню. Да и читабельность у него :(
Строки у него есть (хотя и очень ограниченные), да и стековая виртуальная
машина куда удобнее для преобразования справа налево. А уж для вывода на
экран в двоичном виде достаточно записать двойку в переменную BASE. Если
ничего не перепутал (давно на Forth не работал и под рукой его нет), то
вывод на экран:
: TOBIN BASE @ SWAP 2 BASE ! U. BASE ! ;
Если же основание системы счисления восстанавливать не надо, то вообще:
: TOBIN 2 BASE ! U. ;
Если надо не вывести, а вернуть строку, то (опять же - если ничего не
перепутал) без восстановления системы счисления будет что-то вроде:
: TOBIN 2 BASE ! 0 <# #S #> ;
С восстановлением системы счисления:
: TOBIN BASE @ >R 2 BASE ! 0 <# #S #> R> BASE ! ;
>> Заглянул сейчас на http://haskell.org - он имеет как компиляторы, так и
>> интерпретаторы. И ИМХО, я не думаю, что это чисто компилируемый язык
PP> (скорее
>> всего без элементов интерпретации обойтись невозможно).
PP> Есть чисто. ghc например.
Предположим... Hо обеспечивает-ли он скорость, соизмеримую со скоростью Си?
Цитата, на которую я наткнулся, когда разыскивал информацию о Haskell:
=========Beginning of the citation==============
Примеры энергичных языков: Objective CaML, Standard ML (SML). Ленивые языки:
Haskell, Miranda. Языки указаны в порядке распространенности. За информацией
по ленивым языкам мы отсылаем читателя на сайт языка Haskell:
http://www.haskell.org/. В научных исследованиях и теоретических работах
предпочитают использовать языки с ленивой семантикой, практические
разработки ведутся, главным образом, на энергичных языках. Это связано с
более высокой эффективностью получаемого кода и значительно большей
скоростью работы компилятора.
=========The end of the citation================
>> Судя по всему, динамический массив. Т.е. та же самая работа с кучей и
PP> прочие
>> тормоза (включая, вероятно, и автаматическую сборку мусора?). Только в
>> STL это все открыто, а у тебя остается "за кадром".
PP> Во-во там все открыто, громоздко и тормозно, ибо надстройка на языком
PP> :) А зачем мне открытая сборка мусора? Еще об этом голова не болела :)
Если нет желания вдаваться в детали, можно спокойно использовать STL и не
думать о ее устройстве. Только вот в C/C++ сборки мусора вообще нет. :-) И,
соответственно, непредсказуемых тормозов, вызываемых этой самой сборкой
мусора, тоже нет.
PP> gcc - делает вид что мусор убирает.
Т.к. в C/C++ сборки мусора вообще нет, то и "делать вид" не имеет смысла.
PP>>> Это ты не сможешь доказать :) Сначала напиши итерационный вариант
PP>>> преобразования, а не печати строки :)
>> Итерационный вариант без STL:
>> char* toBin(int val){
>> static char Buf[CHAR_BIT*sizeof(int)+1];
>> char *Tmp = Buf+(sizeof(Buf)-1);
>> do{
>> *--Tmp = '0'+(val&1);
>> val=(val>>1)&INT_MAX;
>> }while(val);
>> return Tmp;
>> }
PP> Hу все - хватит меня ся-ми пугать с трехэтажнами объявлениями
PP> типов и контролью за памятью.
Ага... Пугать можешь только ты - выдавая текст на неназванном (и, ИМХО,
неизвестном большинству подписчиков эхи) языке. :-)
PP> Ты вообще можешь гарантировать что любой из твоих примеров со static
PP> char - thread safe? Боюсь нет :)
В смысле? Я могу гарантировать, что обе ф-ции из предыдущего письма
правильно работают на машинах с представлением чисел в двоичном
дополнительном коде и при использовании компилятора, соответствующего
стандарту.
PP> 1) где у тебя терминирущий '\0' в строке? Выдастся мусор после
PP> результата
В полном соответствии со стандартами C/C++, он заносится еще на этапе
компиляции: все глобальные и статические переменные, не имеющие явных
инициализаторов и (для C++) конструкторов, инициализируются нулями. Я
заполняю статический буфер справа налево, начиная с ПРЕДПОСЛЕДHЕГО элемента.
Так что последний элемент Buf - ВСЕГДА ноль.
PP> 2) выдаются лишнии нули в начале, те '001100' вместо '1100'
Ошибаешься - никаких лишних нулей не выдается.
PP> Так что без STL тебе уже не так просто избаситься от ведущих '0'
Похоже, что ты невнимательно смотрел мой код - никаких ведущих нулей там нет
(ф-ции проверялись на gcc 3.2).
>> А зачем ему это надо? Си - это очень удобный рабочий инструмент.
PP> Гм .. не заметил :) Миф это
Это не миф, а мой личный опыт.
>> Если понадобится предельная краткость записи, то я возьму APL, или
PP> Forth...
>> Если прозрачность описания алгоритма - что-нибудь Алголо-подобное (в том
>> числе и Паскаль). Hо если мне надо написать реальную программу, то в
>> большинстве случаев это будет C/C++.
PP> То есть вещи, которые в себе это все сочетают одновременно, тебя не
PP> устраивают? :)
Я не вижу смысла в объединении трех совершенно несвязанных задач.
Краткость - это только для ленивых.
Прозрачность - это скорее для статей и учебников. В реальном
программировании "прозрачность" в значительной степени обеспечивается
комментариями (что автоматически снимает требование "краткости").
Я уже упоминал выше пирамидальную сортировку и сортировку слиянием.
Hасколько кратко и прозрачно их можно записать на Haskell? Hасколько кратко
и прозрачно можно закодировать "движок" генетического алгоритма?
С уважением, Андрей.
--
Отправлено через сервер Форумы@mail.ru - http://talk.mail.ru
--- ifmail v.2.15dev5
* Origin: Talk.Mail.Ru (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
