Здравствуйте, WolfHound, Вы писали:
WH>Вот пример посложнее.
Спасибо. Как я понимаю, здесь главная фича в наличии операции "+" над типами и ее ассоциативности (3+4=4+3). Но опять же мы здесь опираемся в первую очередь на два изначальных источника — size1 и size2. ИМХО, в реальном мире таких случаев не очень много. В реальном мире у нас будут не порожденные из одного источника массивы, длину которых компилятор сможет проверить, а произвольные, и от той же проверки наподобие "if size1 = size2" мы никуда не денемся. Конечно, мы ее можем сделать на самом верху, а потом вниз передавать это знание, но это (по-моему) как раз то, что было jazzer'ом продемонстрировано в его примере на С++.
Здравствуйте, AlexRK, Вы писали:
ARK>Спасибо. Как я понимаю, здесь главная фича в наличии операции "+" над типами и ее ассоциативности (3+4=4+3).
Главная фича здесь — в индукции над натуральными числами.
ARK>В реальном мире у нас будут не порожденные из одного источника массивы, длину которых компилятор сможет проверить, а произвольные, и от той же проверки наподобие "if size1 = size2" мы никуда не денемся.
В некоторых языках можно и так.
В таких языках контекст типизации у каждого следующего выражения уникальный и зависит от предыстории.
При описании зависимой теории типов так и говорится:
Контекст: Контекст -> Тип -> Контекст.
Эдакой функциональное отображение.
Т.е. из текущего контекста и некоего типа (или его параметра) получаем следующий контекст и т.д.
ARK>Конечно, мы ее можем сделать на самом верху, а потом вниз передавать это знание, но это (по-моему) как раз то, что было jazzer'ом продемонстрировано в его примере на С++.
Пример jazzer-а работает над конечным кол-вом инстанцированных в compile-time типов.
Т.е., если ко-во неких значений-параметров типов (и их валидных комбинаций) конечно, то это вполне себе альтернатива ЗТ.
Здравствуйте, vdimas, Вы писали:
F>>Интересно какие парсеры используются в icc и msvc. V>Я же сказал, сегодня практически ВСЕ коммерческие компиляторы С, С++, шейдерные диалекты С, встраиваемые диалекты С и С++ — все они пользуют EDG С/C++ front end.
Шейдерные диалекты пожалуйста спусти в унитаз. Там размеры ультракрошечные и никомуненужечные почти
И пальцы этой откровенной херней которая пишеться за неделю в лоб — гнать не надо. EDG же пишет что MS вроде как их юзают в IDE но никак ни в компиляторе. Насчет icc — ещё более пространственные намёки.
Я хер не знаю что такое EDG, И знать не хочу как он устроен, если эти дибилы его сделали на GLR и ты там работаешь — вы сами себе доктор. Если эти дибилы его просто сделали на GLR — то опять дибилы. Пойми, что в современных процах исключительно все data-dependent algorithms — сосут адски по скорости потому что предсказание ветвлений будет обламываться часто. Хотите скорости... изучайте матчасть проца. Т.е. развопачивайте. Что вручную и делают. В конкретных (т.е. целый язык — ситуациях).
Если ты инсайдер EDG и вы используете GLR — тогда давайте результаты. Как ясно из FAQ EDG — оно с трудом годиться для IDE. Мэйнстрим нахер о таком не знает потому что icc и мэйнстрим — это вообще вещи несвязные. Им всё очень очень хочется, но не получается.А то что умеет icc — или умеют и другие — или оно нахер не нужно. Они лучше бы clang развивали а не своей херней якобы на основе EDG страдали.
В общем или обрисуй прямо выкладками или давай примем то, как оно есть — в C++ мэйнстриме пока, что побеждают рукописники RD/LL. Никаких альтернатив тут нет. Причину я уже выше озвучил почему табличники в наиве сосут. Неужели это не было ясно с самого начала?
Тем более одно дело если у нас шарп илиЯва. А C++ с его forced forward declarations — там RD/LL просто делает это.
Вот распрасить тот же шарп — посложнее. Немерле — ещё сложнее. А вот плюсы — в том то и дело что за счёт forward declarations — тривиально.
Где вы там собралисб поменять GLR?!... Исходники главно ж под рукой и gcc и clang. Я перед прршлыми ответами — внимательно поизучал clang на неучтенный случай. Ну хватит. 1.5мб с++ — это много. Но подъемно. Более того — кол реально простой. На то он и рукописник.
Тут раньше фронт msvc исчезнет как таковой. А ты рассуждаешь как реально работаншь в своём EDG.
Ток без обид. Объяснись нормально и народ потянеться. Но херню не говори — GLR не может быстрее работать. У него худший что лучший случаи если по честному делать — дороги однаково. Классический просто порождает херову ненужную тучу (ага, а всё равно не бесплатную) вариантов. Статьи наглядно показывают соотношения вариантов и единственного правильного пути. 1/30К по сути. Гуляйте и пользуясь местной терминологией — принудительно отстранить от программирования и отдать на лечение. Вот и всё.
WH, в отличие от тебя хоть как-то пытается аргументировать. Ты же аппплируешь к вещам никому неизвестным. Тот же EDG. Аппелировать к чёрному ящику — это неспортивно. Во-вторых — в коммерческих продуктах как ты говоришь "ВСЕХ" оно точно не используется. Мда. Шейдерные языки. Посмеши нас ещё раз пожалуйста. Шейдерные языки или мегабайты парсинга.
Ты то в целом прав. Как и WH в целом прав. Но завираться — точно не надо. Я легко читаю и приемлю твои свободные определения некотоых вещей. Но странно — от других ты резко требуешь классику. С чего бы. Короче — надоели.
Вот VD2 vs WH — это круто. Тож спорят ниочём. Но хотя б пластинка была новая.
Я эт к чему. Не потому что умный. Наоборот. Хочу новых страстей почитать.
Здравствуйте, WolfHound, Вы писали:
V>>Необходимо было "прочесть" из входа некий вектор и вернуть его. V>>Ты никуда его не возвращаешь, ты оперируешь им исключительно в том же блоке кода, в котором прочел что-то из входа — я вижу чтение из входа прямо в теле main. Для решения задачи все операции чтения должны быть внутри некой ф-ии, которая вызывается из main, внутри себя читает вектор и возвращает его вызывающему коду. Иначе слил. WH>1)Это тебе голоса в голове напели.
Т.е. ты слил?
WH>2)Так ты повторишь этот код на хаскеле или таки опять расписался в том, что трепло?
Ты обещал, но так и не показал.
Но с других требуешь показать даже то, что они не обещали, аж слюна с монитора брызжет. ))
А ты забавный.
V>>Как сформулируешь очередную "задачку, с которой справятся только ЗТ", так приходи. WH>Так я уже сформулировал. То, что ты не в состоянии написать код это подтверждает.
Пока что я вижу, что ты не в состоянии написать код, который вернет вектор из некоей ф-ии, внутри которой сам вектор будет прочитан динамически. Мне требовалось именно это и ты это прекрасно понял.
Потому что твоя постановка вопроса вот тут:
Попробуй вернуть этот вектор в функцию main таким образом, чтобы тип сохранился.
— дилетанская. Ну или сугубо для выкручивания, типа как уж на сковороде, бо уже не знаешь, что бы такого придумать. ))
В реальной жизни трюка с вызовом полиморфного колбэка (стиль CPS) — достаточно, особенно если этот трюк поддерживается синтаксисом языка: аппликациями или монадами. Остальное — это лирика и верчение ужей на сковородах.
WH>>>2)Ты даже упрощённый вариант показать не можешь. Ибо трепло. V>>Ибо прикольно быть модером и хамить, верно? WH>Ну так код то будет или как всегда трепло?
Моё "код в студию" равносилен утверждению, что подобное невозможно.
И, судя по тому, что ты НЕ в состоянии показать обещанное — я опять прав, а ты опять слил.
V>>По этой теме уже всё с тобой ясно — ты не в состоянии показать только что тобой же обещанное. WH>Ясно что ты не можешь написать десяток строк кода.
Да нечего там писать.
Обещанное тобой не имеет решения.
По крайней мере на Idris.
В общем, ты опять показал своё плохое понимание зависимых типов.
V>>Он как раз регулярно тут хамит окружающим. V>>Намного-намного реже тебя, но, таки, регулярно. WH>Окружающим это тебе?
Я тут участвую далеко не во всех темах, больше читаю и то, менее 10%.
У меня довольно-таки узкий круг тем, по которым я регулярно отписываюсь.
Это ж ты у нас везде поспел, как же. ))
Помнишь свою фишку про "capability"?
Ты ведь так и НЕ понял того трюка, что самое смешное. ))
Там прикол в том, что и сами авторы тоже не поняли суть собственного трюка. Такие же дилетанты, фиг ле.
И да. Почему я это утверждаю относительно тебя? — потому что увидел непонимание тобой мема "сорт типов".
Т.е. я вижу у тебя невладение терминологией — в каких именно случаях некоторые авторы используют именно этот мем.
ОК, всё понятно.
Показанная тобой некая "иерархия" — дилетанство полнейшее.
Из-за этого дилетанства ты НЕ понял суть трюка с capability, как и его авторы, собсно.
Вы все забавны. ))
Этот трюк легко выражается через создание семейств "несовместимых" типов-контейнеров, хранящих внутри себя "совместимые" типы по-значению.
Вот и всё кино.
Остальное — синтаксический сахар, не более.
В данном случае они назвали этот синтаксический сахар capability и поэтому вылетели с красной карточкой за границы теории типов (за любую из теорий типов), поэтому, следующую игру пропускают. ))
Ну и твои попытки объяснить другим суть трюка — это демонстрация полнейшей каши в голове, потому что неумение связать двух слов.
Понял бы ты трюк тех авторов, ты бы:
— выставил самих авторов на посмешище;
— легко объяснил бы этот трюк окружающим.
Ты не смог ни первого, ни второго.
Твои объяснения были сумбурными, непоследовательными и нелогичными.
Мне пришлось читать про ту хрень самостоятельно и долго над авторами и тобой ржать. ))
V>>Я такой подход хорошо знаю — нахвататься по верхам и тешить своё ЧСВ за счет окружающих. WH>Это про тебя.
Ага, это я, значит, не мог 8 лет сообразить, что мне говорят? ))
Это я, значит, не отличаю compile time от runtime?
Или это был некто WolfHound? ))
Кончай ломать комедию. Ты откровенно тормозил огромное кол-во лет. Чудовищное кол-во лет по меркам IT.
V>>Стоило только чуть ноготком подцепить и выяснилось, что он сам в этой теории изрядно плавает. WH>Да ты её вообще не знаешь. WH>Путаешь рода типов и классы типов. Да ещё сорта типов придумал.
Я как раз не путаю, я как раз говорю — где у нас терминология конкретного языка программирования, а где общая теория типов (какой-то из теорий, бо их больше одной).
А вот ты путаешь терминологию отовсюду.
В общей теории типов есть только одна иерархия: терм, тип, мн-во типов.
Это всё.
Остальное — конструкторы типов и ф-ий разной замысловатости: П-функции (полиморфные), П-типы (зависимые), E-типы (зависимые от литералов) и т.д.
А ты там херню писать изволил.
Потому что рода и классы типов — это терминология сугубо Хаскеля.
И тебе многократно это говорилось, но ты спишь, пока в форум пишешь, вестимо.
Невнимателен, не собран.
Далее.
Под "сортами" типов многие авторы подразумевают НЕСОВМЕСТИМЫЕ м/у собой типы и прямо об этом говорят.
Примеры сортов типов я тебе приводил.
Кароч, у тебя дикая каша в голове из обрывков информации.
V>>Как и ты, который НЕ понимает, что есть "сорта типов". ))) WH>Только в твоей голове. В теории типов их нет.
Ага, всё-таки почитал кое-что?
Молодец!
Вот в другой раз сначала читай, потом возражай.
V>>Я ведь именно тебе (единственному из этих 3.5 человек) МНОГОКРАТНО говорил, что конкретно у тебя проблема в том, что ты зачастую и не хочешь знать. Лично мне со стороны даже где-то обидно за незнакомого мне человека — вроде голова твоя соображать умеет (что приятная редкость, прямо скажем), а вроде часто по верхам, кусочно гладко, не систематично и вообще... Жаль, просто жаль... Потому что у других, кто тут регулярно психует, скажем прямо, проблемы совсем другого плана, я бы даже сказал — местами совершенно непреодолимого плана. )) WH>Проблемы непреодолимого плана тут только у тебя. WH>Настолько упёртого невежду я ещё не видел.
Т.е. это я 8 лет упирался по элементарным вопросам? ))
V>>Вы ж разогнали всех более-менее интересных собеседников с этого сайта в разные годы. WH>Это таких же безграмотных, как и ты?
В этом споре в безграмотных ходишь ты и еще долго будешь.
Тут проблема в том, что ты НЕ понимаешь специфику IT, а она такова, что всё знать невозможно и это нормально.
Например, твои знания IT узки до невозможности.
По предыдущим обсуждениям с тобой я сделал вывод, что или ты так и не окончил ВУЗ (вылетел с 3-го курса), или безбожно прогуливал (начиная с 3-го курса).
Потому что умудряешься плавать по самой базе.
И тем нелепее выглядело, когда ты и тебе подобные попускали ценных в своих областях спецов лишь потому, что они не ориентировались хорошо в той же узенькой области, что и вы. Лавров хорошо и кратко о таких заскоках высказался.
V>>- на шаблонах это всё заняло бы примерно столько же времени, сколько потребовалось бы лишь для того, чтобы закодировать предметную область для кодогенерации (и это еще БЕЗ самой генерации). WH>И очень хорошо зная возможности шаблонов я выбрал внешнюю кодогенерация, ибо знал что шаблоны на этой задаче сдохнут.
На приведенной формуле они не сдохнут.
WH>Ты конечно можешь легко опровергнуть мои слова показав решение на шаблонах.
Показать решение должен был ТЫ, коль утверждал, что получил решение ЛУЧШЕ.
Потому что вопрос стоял так — лучше чем "что"? ))
Сравнение где?
В общем, вменяемого ответа не было, детсад.
Оставалось глумиться.
Решений может быть мильон, сходу накидал, даже не компиллировал, но это пофик, общая идея понятна:
typedef float f;
struct Color8Bit_Traits
{
typedef uint8 C;
static C roundC(f value) {
return round(value)
}
};
struct Alpha8Bit_Traits
{
typedef uint8 A;
static A fromF(f value) {
return floor(value * 255.5f);
}
static f toF(A value) {
return value / 255f;
}
};
struct RGBA8_Traits_Base : Color8Bit_Traits, Alpha8Bit_Traits {
typedef uint32 pixel;
static C getR(pixel value) { return value & 0xFF; }
static C getG(pixel value) { return (value >> 8) & 0xFF; }
static C getB(pixel value) { return (value >> 16)& 0xFF; }
static A getA(pixel value) { return value >> 24; }
static f getAF(pixel value){ return toF(getA(value)); }
static pixel make(C r, C g, C b, A a) {
return makeUInt32(r, g, b, a);
}
static C mixC(C u1, f a1, C u2, f a2) {
roundC(u1*a1 + u2*a2);
}
};
template<typename Traits>
struct RGBA_Traits : Traits {
static pixel blend(pixel p1, pixel p2, f mix) {
f a1 = getAF(p1) * mix;
f a2 = getAF(p2) * (1 - mix);
C r = mixC(getR(p1), a1, getR(p2), a2);
C g = mixC(getG(p1), a1, getG(p2), a2);
C b = mixC(getB(p1), a1, getB(p2), a2);
C a = mixC(getA(p1), a1, getA(p2), a2);
return make(r, g, b, a);
}
};
typedef RGBA_Traits<RGBA8_Traits_Base> RGBA8_Traits;
// и т.д.
// ...
Итого, алгоритм для ВСЕГО rgba-семейства содержится в некоем RGBA_Traits.
Аналогично надо описать алгоритмы для hsl, cmyk и т.д.
По-сути, получаются ортогональные координаты:
— способы кодирования цвета;
— битовая упаковка.
Сложности тут надуманные.
Я НЕ верю, что ты бы не решил эту задачу.
WH>Но как мы уже выяснили код ты писать не умеешь.
Голоса в голове...
V>>И зря ты стал пытаться уводить разговор в тонкости сугубо технической области — в этой забавной ситуации она была вовсе не при чем. WH>Очень даже причём. Вы же пытались гнать бред про то что там всё можно обобщить. Я показал почему нельзя обобщить.
Нихрена ты не показал.
Нужно было или дать сравнение двух подходов или ничего не утверждать, а тихо слиться.
Потому что иначе твоё решение выглядит НЕОБОСНОВАННЫМ.
WH>>>И суперпупермегабыстрый GLR я до сих пор жду. Ни LR(0) или что там тебе ещё голоса в голове напоют, а полноценный GLR. V>>Я никому не обещал никакой код, с чего ты взял-то? WH>С того что ты утверждаешь то что противоречит всем работам по GLR.
Брехня опять.
Я раз 10 повторил сценарии/условия, где GLR себя хорошо показал.
Вместо разбора сценариев и озадачиванием — а ПОЧЕМУ так происходит с этим алгоритмом на этих сценариях, ты потребовал некий код.
Т.е., думать ты отказался сходу.
ОК.
Но ты опять этим забавен.
WH>А значит тебе нужно либо доказать свои слова кодом
Пока что всё тобой озвученное лишь означает, что мне надо проделать некую немалую работу по выдиранию алгоритма из боевого проекта, и всё только для того, чтобы заинтересовать с вероятностью 0.3% некоего анонима под ником WolfHound.
При том, что этот WolfHound вникнуть в простейшую предметную область GLR не в состоянии (или не в желании), отсюда такая низкая заведомая вероятность. Итого, херней мается человек и другим моск выносит.
V>>Но если весь и-нет завален материалами и исходниками про тот же LR(0) — то какие проблемы-то? V>>Твой "полноценный GLR" — это распараллеленный LR(0). WH>Так и по GLR полно материалов. И все они без исключения говорят, что GLR тормозит.
Для любых алгоритмов в области разбора по формальным грамматикам обязательно упоминается, где они хороши, а где не очень.
Т.е. пытаться что-то там обсуждать в отрыве от вида грамматик и характера входных данных — это махровое дилетанство.
Здравствуйте, fddima, Вы писали:
F>Шейдерные диалекты пожалуйста спусти в унитаз. Там размеры ультракрошечные и никомуненужечные почти
Тем не менее, юзают.
Это же почти С.
F>EDG же пишет что MS вроде как их юзают в IDE но никак ни в компиляторе. Насчет icc — ещё более пространственные намёки.
NDA — оно такое, угу. ))
EDG is a front-end used by Intel and Comeau.
F> Я хер не знаю что такое EDG, И знать не хочу как он устроен, если эти дибилы его сделали на GLR и ты там работаешь — вы сами себе доктор. Если эти дибилы его просто сделали на GLR — то опять дибилы. Пойми, что в современных процах исключительно все data-dependent algorithms — сосут адски по скорости потому что предсказание ветвлений будет обламываться часто. Хотите скорости... изучайте матчасть проца. Т.е. развопачивайте. Что вручную и делают. В конкретных (т.е. целый язык — ситуациях).
Ммм... Ну вот поэтому не всегда однозначно, какой код лучше для парсинга — на условных ветвлениях или на таблице переходов.
Потому что в первом случае предсказатель может ошибиться и сбросить конвейер, а в другом случае таблица переходов может быть достаточно велика и сбрасывать кеш проца при ходьбе по ней.
Вопрос (не уверен, что правльно понял): алгоритм работы лексера — это "data-dependent algorithms"?
Ну вот базовый LR(0), из которого сделали GLR, он работает примерно по алгоритму лексера.
F>Мэйнстрим нахер о таком не знает потому что icc и мэйнстрим — это вообще вещи несвязные.
Под линухами популярно, когда требуется генерить хорошо оптимизированный код.
Потому что GCC не умеет нихрена.
F> В общем или обрисуй прямо выкладками или давай примем то, как оно есть — в C++ мэйнстриме пока, что побеждают рукописники RD/LL. Никаких альтернатив тут нет. Причину я уже выше озвучил почему табличники в наиве сосут. Неужели это не было ясно с самого начала?
Табличные парсеры работают БЕЗ условных ветвлений.
Это безусловное косвенное извлечение данных.
Современные процы умеют делать такое извлечение еще на этапе предвыборки, т.е. такие вещи занимают ровно 0 тактов процессора (если данные уже в кеше).
F>Тем более одно дело если у нас шарп илиЯва. А C++ с его forced forward declarations — там RD/LL просто делает это.
Порой LL — наихудшее решение.
F>Вот распрасить тот же шарп — посложнее.
Разве?
Грамматика более однозначная.
F>А вот плюсы — в том то и дело что за счёт forward declarations — тривиально.
Не тривиально. Рядом я приводил неоднозначности.
Сложность разбора состоит не только в размере грамматики, но и в степени её однозначности.
F>Классический просто порождает херову ненужную тучу (ага, а всё равно не бесплатную) вариантов.
Ну вот при разборе арифметических выражений, взаимных вызовов ф-ий, операторов языка — не порождает никаких вариантов.
Потому что однозначность.
F>Статьи наглядно показывают соотношения вариантов и единственного правильного пути. 1/30К по сути.
В какой грамматике и в каких данных?
В случае 1/30к у LL-парсера будет 30к откатов.
F>WH, в отличие от тебя хоть как-то пытается аргументировать.
Нет, не пытается.
Он пытается попускать окружающих или сыпет "аргументами" уровня букваря и обрывками прочитанного из Сети, даже мало относящегося к конкретному спору. Офтоп от него — дело обычное. Часто меняет тему, часто пытается перекрутить исходный спор.
ИМХО, это НЕ аргументы, это шумовой фон с целью раскидать внимание собеседника.
И я не уверен, что он это делает специально.
Просто не видит свою линию защиты со стороны.
F>Ты же аппплируешь к вещам никому неизвестным. Тот же EDG. Аппелировать к чёрному ящику — это неспортивно. Во-вторых — в коммерческих продуктах как ты говоришь "ВСЕХ" оно точно не используется.
Оно точно используется почти во всех.
F>Мда. Шейдерные языки. Посмеши нас ещё раз пожалуйста. Шейдерные языки или мегабайты парсинга.
Показанная мною неоднозначность С++ характерна и для С.
Как раз-таки шаблонные навороты С++ НИКАКОЙ неоднозначности не добавляют.
А мы же о неоднозначностях говорим, верно?
F>Я легко читаю и приемлю твои свободные определения некотоых вещей. Но странно — от других ты резко требуешь классику. С чего бы.
Потому я никогда никого не "ловлю", я просто делюсь инфой и могу напомнить некие вводные положения по некоей теме перед тем, как собираюсь что-то озвучить из той области. Считаю этот подход единственно адекватным. Здесь никто никому и ничем не обязан. Мы можем только делиться некоей инфой. Кому захочется больше — тот будет копать больше. Если что-то будет непонятно — можно спросить.
И это, ес-но, противоположный подход тому, что некоторые пытаются кого-то там "поймать на незнании" и больше никакой цели не имеют. ))
Мало того, что сами по себе такием манеры г-но... Тут ведь еще изволь сам тогда соответствовать, верно?
Да вот не изволят нифига в 100% случаев. )))
Потому что это вообще наивность, вот такая "ловля" при работающем интернете у оппоненета.
Ну даже если твой оппонент не владел чем-то оффтопным на некий момент, и?
Назавтра почитал и уже владеет.
Т.е., сам по себе такой подход, помимо того, что это снобистские г-но манеры, так это еще откровенный идиотизм получается (по описанным причинам).
F>Вот VD2 vs WH — это круто. Тож спорят ниочём. Но хотя б пластинка была новая.
WH теоретик, но лентяй.
VD2 практик и администратор, способен вести "долгоиграющие" проекты, но уже устал от теоретика-лентяя.
Вот и всё, что там происходит.
F>Я эт к чему. Не потому что умный. Наоборот. Хочу новых страстей почитать.
Здравствуйте, VladD2, Вы писали:
V>>LR-разбор в состоянии подсказать множество верных ожидаемых символов. В реальности там выбор из 1-2-х вариантов максимум, потому что в С++ неоднозначность происходит в выборе м/у идентификатором типа или переменой, вот и вся неоднозначность, которой "болеет" С++. VD>ЛР падает на свертках. И эти почти наверняка не места реальных ошибок. В тоже время ЛЛ падет на входе в правило и это почти наверняка реальное место ошибки.
Свертки в LR происходят только по входному символу.
Например, пришел входной символ (предположим, у нас scannerless), предположим, символ 'a', подали этот терминал "наверх", наверху выяснили, что допустимого шифта нет (продвижения по последовательности нетерминалов/терминалов в правиле), есть только шифт по открывающей фигурной скобке или по точке с запятой. Так и говорим: "ожидалось '{' или ';'".
VD>Ты почитай какими извращениями занимаются те кто восстановление для GLR-ов пишут. Это жесть!
Пока что ваши извращения вокруг восстановления кажутся более серьёзными.
И да, это демагогия, бо "восстановление" — это редкая задача, вот как раз для интиллисенса.
А компилятор ЯП может тупо отрапортовать об ошибке в этом файле и отвалиться.
VD>Какие типы в ЛР-парсере?
Простые. Свертка идёт снизу, мы можем доопределить "просто идентификатор" до "идентификатора типа" или "идентификатора терма".
VD>Пипец ты жжешь! Вот в ЛЛ можно тупо таблицу имен протащить и действительно во время парсинга резолвнуть имя узнав является ли оно типом (если речь о С++). А как это сделать в ЛР, который обломался на свертке некого правила?
Облом происходит всегда на шифте, а не на свертке.
Просто да, ввиду того, что работа парсера событийная, облом на шифте сверху происходит по свертке снизу.
И вообще, сосредоточься, а то уже неинтересно. ))
Там ничего сложного, я не понимаю причин твоего психа.
Представь себе, что у тебя парснг происходит не по схеме pull, а по схеме push.
Помнишь, чем sax-парсинг XML отличается от DOM-парсинга?
Вот так же и в восходящем парсинге.
Представь, что это не ты вызываешь лексер, а лексер тебя вызывает, когда у него готова очередная лексема для её обработки (передает лексему наверх).
В этом смысле LR-разбор вызывает сам себя, когда у него готов очередной нетерминал.
V>>Если id3 — это значение (переменная/константа/перечисление), то id2 — это идентификатор переменной, а всё выражение означает объявление переменной типа id1 и вызов соотв. конструктора этого типа. А если id3 — это имя типа, то всё выражение означает объявление сигнатуры некоей ф-ии id2. VD>Какая чушь?! Никто не типизирует выражения С++ во время парсинга. Только лукапят имена по таблице имен.
Лукап имён в С++ происходит по непростому алгоритму, описанному в стандарте.
VD>И тип выражения определяется по тому является ли id1 типом. Хотя здесь выражение и так объявление переменной.
Объявляется или переменная или ф-ия.
VD>Вот в случае id1* id2(id3) действительно было бы не ясно.
И тут точно так же надо знать, какой идентификатор является идентификатором типа, а какой нет.
V>>С другой стороны, подобную неоднозначность НЕ обязательно сваливать на парсер и её не сваливают — для такой конструкции заводится отдельный "недоопределённый" нетерминал и его ресолвят до однозначного через таблицу идентификаторов ручками. Т.е. на скорости работы именно парсера по алгоритму *LR это не сказывается (если убрать ресолвинг). Это конкретные заморочки конкретно С++, которые верны для ЛЮБОГО алгоритма парсинга. VD>Причем тут скорость?
Здравствуйте, VladD2, Вы писали:
VD>Вот возьми ту же VS. Ей недавно исполнилось 20 лет. Первые её версии были целиком на С++. В версии VS.NET от 2002 года там появились первые куски написанные на C#. По началу их было не много. Но время шло и на сегодня уже большая часть VS написана на C#. VD>Зачем MS переводит VS на C#, если это так плохо, а С++ — это так круто? Почему они переписали на C# компилятор того же C#? Почему даже проектную модель для С++ (в Студии) переписали на GC-языках? VD>Почему все новые IDE или плагины пишутся на GC-языках?
Потому что IDE — это утилитный продукт. Вспомогательный, а не целевой.
И потому что человек кликает мышкой или набирает текст всего 2-3 раза в секунду, а то и реже.
Поэтому, мощностей современных компов вполне хватает справляться с таким низким трафиком событий.
VD>1. Потому что разрабатывать на GC-язках проще.
Да.
VD>2. Потому что скорости предоставляемой GC-языками хватает для решаемых задач.
Да.
Ограничением из прошлого был в основном объем памяти, где 1-2 гига еще 12 лет назад — это нормально, а сейчас нормально 8-16 гиг.
Как только памяти стало хватать, так управляемые приложения окончательно захватили утилитную нишу.
V>>Т.е., когда лексер-парсер работают в паре, то лексический анализатор занимает львиную долю тиков процессора из затрат на парсинг (формирование AST — это, считай, "отдельная" нагрузка). Т.е. синтаксический анализ занимает меньшую долю тиков в совместной работе. VD>Само наличие лексера сокращает число этих самых тактов на порядки. Парсеру приходится работать не с миллионами символов, а с тысячами или даже сотнями. Число неоднозначностей падает с тысяч, до единиц или даже нуля.
Верно. Я же говорил — трафик у парсера сильно меньше, чем у лексера.
Я писал, что подключение парсера к лексеру на моих данных давало лишь 5%-10% проседания производительности, т.е. парсер+лексер работают примерно так же, как один лексер.
VD>Слушай читать твои фантазии у меня никакого желания нет.
Читать мало, надо понимать.
Итого, лексер производит сдвиг (в терминах LR) по цепочке символов, потом сворачивает (в терминах LR) эту цепочку терминалов в один нетерминал и подаёт "наверх" в виде кода нетерминала. Так трафик-то нетерминалов получается меньше?
А теперь на более высоком уровне опять происходит сдвиг по накопленной цепочке нетерминалов и опять сворачивание цепочки нетерминало в один нетерминал — и опять получается трафик в разы меньший для еще более вышестоящего уровня, верно?
Итого, чем глубже вложенность выражения (скажем, при парсинге некоего ЯП), тем меньше трафик нетерминалов самого высокого уровня? Т.е., получается, что от глубины вложенности выражений скорость LR-парсинга практически не зависит, верно?
А вот для парсера с откатами в случае недостаточности просмотра на 1, глубокая вложенность выражений может стать больным местом. Не зря расширения Пакрата и ALL используют мемоизацию и прочие трюки.
VD>Но сам лексер работает просто на порядки быстрее.
ЗА СЧЕТ ЧЕГО?
VD>"Отлексить" с помощью качественного компилированного кода основанного на ДКА даже десятимегабайтный файл — это денницы миллисекунд. А вот парсинг того же самого — это совсем другой расклад.
Ну скорми LR(0)-парсеру грамматику от лексера (почему бы и нет?) и проверь.
Ну будет у тебя стек разбора с фиксированной глубиной 1, и?
Алгоритм же тот же...
V>>Потому что трафик символов разный, ес-но. VD>Ты говоришь полную чушь! Трафик ничто по сравнению с вычислительными затратами.
Лексер тоже выполняет сдвиг и свертку, напомню.
Сделай эти операции такими же дешевыми, как в лексере.
Просто я часто видел, как хранят стек разбора LR-парсера в виде linked list. Но, если ты для лексера будешь представлять входные терминалы как linked list, то вычислительные затраты лексера тоже станут ого. ))
VD>А главное, что GLR (ну, если это реально GLR, а не что нибудь) являются безлексерными и разбирают отдельные символы далекими от эффективности алгоритмами.
Вот это чушь как она есть.
Самой граматике глубоко до фени как она получена, т.е. является ли исходной или же является результатом декомпозиции грамматик, когда регулярную часть выделили в отдельный парсер, который назвали лексером.
А что мешает, кстате, произвести подобную декомпозицию более одного раза?
V>>Только на неоднозначностях. VD>Хрен там. У них и константа во много раз выше. Не может быть обобщенный алгоритм столь же эффективным, как специализированный.
Может на единственной ветке разбора.
VD>Вот ДКА ты хрен когда догонишь. Хот ты лопни.
LR(0) и LR(1) — это и есть ДКА, принцип работы которых близок к ДКА лексера.
А GLR парсит по НКА, вот и вся разница. Т.е. от каждой ячейки по данному символу может быть более одного перехода.
Но пока двигаемся по детерминированной цепочке — получается эквивалент ДКА.
VD>Плюс ты похоже не понимаешь принципов работы GLR-ов. Они сворачивают продункции в обратную сторону
LR-разбор сворачивает цепочки в такую же сторону, в какую их сворачивает лексер.
Да, надо хранить текущую цепочку свернутых нетерминалов, т.е. "отображать" входную цепочку на "свернутую" точно так же, как лексер отображает цепочку терминалов на цепочку нетерминалов после их "сворачивания". Просто в случае лексера у нас всего один уровень такого отображения, а в случае LR-разбора кол-во уровней "сворачивания" зависит от уровня вложенности конкретного выражения во входных данных.
ЧТД.
V>>Обрати внимание, что по если по каждой свертке у нас будет конечный (выходной) нетерминал, то получаем в точности автоматный лексер. VD>Языком в основном. На практике код там будет долек от того, что можно сгенерировать для ДКА.
Ты совершенно не в курсе про технику восходящего разбора. ))
VD>Блин, клинический детский сад! Открой для себя понятие константы. Тогда узнаешь, что линейное != быстрое. Если ты на разбор символа в потоке тратишь секунду, то твой алгоритм линейный, но он никому не нужный, так как даже на 100 символов ты потратишь неприемлемо много времени. Вот именно это и происходит со всеми G.
VD>И еще задумайся на фиг нужен GLR, если грамматика полностью детерминирована?
Грамматика и так обычно в конце концов детерминированная (по крайней мере так всегда для ЯП).
Просто не всегда парсится алгоритмами навроде LR(1).
Ну и бывают задачи недетерминированного парсинга, когда каждому из вариантов присваивают вес и получивший больший вес из всех вариантов выигрывает.
VD>Не хочу. Мне время дорого. Приведи тесты GLR vs лексер и за одно дай ссылки те самые С++-парсеры, которые используют GLR для разбора С++.
Угу, как там у прапорщика, "трясти надо"?
Ты же потратил время на Эрли, хотя он хуже в разы, чем GLR?
Ты же потратил на Пакрат, хотя алгоритм сложней и константа у него больше, чем GLR?
Если ты занимаешься этой темой, то это твоя обязанность — разбираться в предмете.
Хотя бы разобраться с алгоритмом восходящего разбора как такового.
VD>Вот мы используем модифицированный Эрли для качественного восстановления после ошибок.
Эрли заведомо хуже GLR и на всех углах это написано.
Ты убил своё время.
VD>При этом числ неоднозначностей растет просто лавинообразно.
Не "лавинообразно", а зависит от длины цепочки.
У GLR в общем случае такой зависимости НЕТ.
И это — ключевое для цепочек в мегабайты длинной, когда неоднозначность цепочки ресолвится в самом её конце.
VD>Но по другому нельзя, так как только обобщенный алгоритм может найти все пути.
Тогда тем более.
Блин, а чего вы мне голову морочите, если у вас вообще Эрли??? ))
Уже надо были сидеть тише воды и не отсвечивать.
Небось взяли вот ту реализацию, которую разбирали когда-то на RSDN.
Кстате, я брал именно твой порт Эрли на .Net и с пол-тыка ускорил его втрое.
И всё-равно оно тормозит безбожно...
V>>Поэтому, я не просто говорил про GLR, я говорил о сценариях, где он очень хорошо себя показывает. VD>Нет таких сценариев на практике.
У нас разные практики.
VD>GLR используется исключительно в научных целях. Я просто ржал читая научные статьи где на полном серьезе говорилось об восстановлении после ошибок за 10 секунд. Успехов всем кто готов ждать отклика редактора по 10 секунд.
Плохо ты читал.
Там где GLR восстановится за 10 секунд, там Эрли восстановится за 10 минут.
VD>1. ПЕГ — это формат грамматики. Алгоритм парсинга ПЕГ-а называется Пакрат.
Алгоримов парсинга ПЕГ более одного.
Почти все с откатами.
VD>2. Пакрат работает без откатов на любой грамматике описываемой ПЕГ-ом.
Пакрат — это крайний случай мемоизации.
В этом смысле и GLR-эдакая "мемоизация".
И что самое ужасное — что мемоизация в Пакрате строится всегда, но может не понадобиться. ))
V>>Однако, где нисходящему алгоритму надо будет регулярно откатываться на много мегабайт назад, GRL рвет его как тузик грелку. VD>Пипец ты берд несешь!
Я говорю аксиомы.
VD>Весь смысл Пакрата в том, что он безоткатный, т.е. гарантирует линейное время.
Как Эрли?
VD>Вот константа у него опять же достаточно высокая. Но все же ниже чем у GRL.
Стоимость мемоизации тем больше, чем её больше.
VD>Хуже с восстановлением. Но и с ним в большинстве случаев все не плохо работает.
Потому что Эрли.
Потому что обобщенный алгоритм ест фсё.
VD>>>А он о константе, которая у GLR будет сушественно выше чем у ДКА. V>>Я уже говорил, суть алгоритма LR(0) — это, грубо, лексер вызывает лексер и так рекурсивно. VD>Пипец! Эта песня хороша, начинай сначала. Не я на тебя время тратить не буду.
А ты не на меня трать, а на себя.
Помнится, ты дофига потратил времени на Пакрат?
Еще помнится, что когда вам советовали Ахо и Ульмана, вы посылали точно так же нах и даже еще более эмоционально (моложе были, понятно), хотя это именно они придумали ПЕГ (TDPL изначально) как способ избежать неоднозначности описания грамматик.
A more formal approach to backtracking is represented by Aho and Ullman’s TDPL language (recently repopularised as Parsing Expression Grammars and their associated memoized Packrat parsers).
... but, of course, PEG’s are not context-free grammars, and as Aho and Ullman said:
“it can be quite difficult to determine what language is defined by a TDPL program.”
The current interest in PEG’s is another manifestation of users’ need for parsers which are human readable.
Ы-Ы-Ы много раз...
Как грится на форумах компиляторописателей:
Здравствуйте, vdimas, Вы писали:
WH>>2)Так ты повторишь этот код на хаскеле или таки опять расписался в том, что трепло? V>Ты обещал, но так и не показал.
Я показал ровно то что обещал. Твоя очередь демонстрировать ЗТ в хаскеле.
V>Это ж ты у нас везде поспел, как же. )) V>Помнишь свою фишку про "capability"? V>Ты ведь так и НЕ понял того трюка, что самое смешное. ))
Я-то понял. А вот ты нет.
V>И да. Почему я это утверждаю относительно тебя? — потому что увидел непонимание тобой мема "сорт типов". V>Т.е. я вижу у тебя невладение терминологией — в каких именно случаях некоторые авторы используют именно этот мем. V>ОК, всё понятно. V>Показанная тобой некая "иерархия" — дилетанство полнейшее. V>Из-за этого дилетанства ты НЕ понял суть трюка с capability, как и его авторы, собсно. V>Вы все забавны. ))
Это говорит человек, который с пеной у рта утверждал, что в С есть зависимые типы.
Почему ты так утверждал? По тому что так было написано в книжке.
Почему там так было написано? По тому что переводчик перевёл название языка Xi как Си.
И ты продолжал упираться пока я тебя мордой в оригинал не ткнул.
Но что самое смешное из-за полного непонимания сути у тебя даже подозрения не возникло что там что-то не то написано.
V>>>Я такой подход хорошо знаю — нахвататься по верхам и тешить своё ЧСВ за счет окружающих. WH>>Это про тебя. V>Ага, это я, значит, не мог 8 лет сообразить, что мне говорят? ))
Ты до сих пор не можешь.
WH>>И очень хорошо зная возможности шаблонов я выбрал внешнюю кодогенерация, ибо знал что шаблоны на этой задаче сдохнут. V>На приведенной формуле они не сдохнут.
Они сдохнут на Флойде-Уолшере.
WH>>Ты конечно можешь легко опровергнуть мои слова показав решение на шаблонах. V>Показать решение должен был ТЫ, коль утверждал, что получил решение ЛУЧШЕ.
Не лучше, а единственное которое работает.
Конечно можно было ещё и руками написать и изначально я это и делал. Но после того как число цветовых пространств стало большим это стало совершенно невозможно поддерживать.
V>Решений может быть мильон, сходу накидал, даже не компиллировал, но это пофик, общая идея понятна:
Понятно, что ты даже не попытался или не смог понять в чём там проблема.
Это даже не упоминая о том, что твоё решение работает только для частного случая и будет тормозить что звиздец.
V>Итого, алгоритм для ВСЕГО rgba-семейства содержится в некоем RGBA_Traits.
RGBA бывают разные. Например, в случае с sRGBA нельзя делать бленд. Получится либо чушь, либо дичайшие тормоза (на несколько порядков в случае с масштабированием изображений).
Быстрый и правильный бленд возможен только в линейном RGBA с предумноженными на альфу цветовыми каналами.
Поэтому прежде чем масштабировать изображение с альфой его нужно сконвертировать именно в этот формат.
И именно задачу конвертации изображения в этот и некоторые другие форматы я и решал.
V>Сложности тут надуманные. V>Я НЕ верю, что ты бы не решил эту задачу.
Так я и решил. Но тебе опять голоса в голове что-то напели, и ты начал упираться.
V>Брехня опять. V>Я раз 10 повторил сценарии/условия, где GLR себя хорошо показал. V>Вместо разбора сценариев и озадачиванием — а ПОЧЕМУ так происходит с этим алгоритмом на этих сценариях, ты потребовал некий код. V>Т.е., думать ты отказался сходу. V>ОК. V>Но ты опять этим забавен.
Вот если D. Mon что-то скажет я пойду это проверять. А если ты, то буду требовать доказательств с тебя.
Ибо тебя слишком много раз ловили на бреде. И не только я.
V>При том, что этот WolfHound вникнуть в простейшую предметную область GLR не в состоянии (или не в желании), отсюда такая низкая заведомая вероятность. Итого, херней мается человек и другим моск выносит.
Человек написал лучший в мире генератор парсеров для компиляторов языков программирования и их ИДЕ.
Если человек увидит алгоритм, который позволит сделать этот генератор парсеров ещё лучше он его возьмёт.
Но человек не будет тратить своё время на проверку слов конченного трепла.
V>Для любых алгоритмов в области разбора по формальным грамматикам обязательно упоминается, где они хороши, а где не очень. V>Т.е. пытаться что-то там обсуждать в отрыве от вида грамматик и характера входных данных — это махровое дилетанство.
Контекст моей работы всегда был грамматики языков программирования и код на языках программирования. И тебе это прекрасно известно.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>>>2)Так ты повторишь этот код на хаскеле или таки опять расписался в том, что трепло? V>>Ты обещал, но так и не показал. WH>Я показал ровно то что обещал.
Ты действительно не понимаешь, чего я от тебя жду?
Ну вот отбросив всякое тролленье и обмен "любезностями", ы?
На очень сложны грамматиках скорость порядка 80 мб/час.
Извините. Мне нужно на 2-3 порядка быстрее.
V>А вот для парсера с откатами в случае недостаточности просмотра на 1, глубокая вложенность выражений может стать больным местом. Не зря расширения Пакрата и ALL используют мемоизацию и прочие трюки.
И этот человек утверждает, что что-то понимает.
У пакрата мемоизация не расширение, а его суть.
VD>>Но по другому нельзя, так как только обобщенный алгоритм может найти все пути. V>Тогда тем более. V>Блин, а чего вы мне голову морочите, если у вас вообще Эрли??? ))
Эрли только до неоднозначностей и для восстановления.
Те обычно он вообще не отсвечивает.
Да и когда запускается старается переключится на основной где может.
V>Уже надо были сидеть тише воды и не отсвечивать. V>Небось взяли вот ту реализацию, которую разбирали когда-то на RSDN.
Не угадал. Реализация там своя.
Причем там не классический Эрли который понимает только BNF, а модернизированный который понимает EBNF (или точнее вообще любой автомат в правой части правила) без трансформации его в BNF. Плюс в отличии от классического Эрли не имеет проблем с nullable правилами. Классическому при наличии nullable правил приходиться итерироваться до фиксированной точки.
И это если забыть про мелочи типа оценки качества восстановления прямо во время разбора. Ибо способов восстановиться после ошибки много и нужно взять не какой попало, а лучший.
V>Кстате, я брал именно твой порт Эрли на .Net и с пол-тыка ускорил его втрое. V>И всё-равно оно тормозит безбожно...
А зачем ты его взял. Чё GLR не написал? Он же круче.
V>Плохо ты читал. V>Там где GLR восстановится за 10 секунд, там Эрли восстановится за 10 минут.
Так ты покажи мне ГЛР парсер который восстанавливается также хорошо, как парсер нитры.
Код на C#:
Здравствуйте, vdimas, Вы писали:
V>Ты действительно не понимаешь, чего я от тебя жду? V>Ну вот отбросив всякое тролленье и обмен "любезностями", ы?
Я понимаю, что ты не можешь доказать наличии ЗТ в хаскеле и пытаешься съехать с темы.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
V>>И да. Почему я это утверждаю относительно тебя? — потому что увидел непонимание тобой мема "сорт типов". V>>Т.е. я вижу у тебя невладение терминологией — в каких именно случаях некоторые авторы используют именно этот мем. V>>ОК, всё понятно. V>>Показанная тобой некая "иерархия" — дилетанство полнейшее. V>>Из-за этого дилетанства ты НЕ понял суть трюка с capability, как и его авторы, собсно. WH>Это говорит человек, который с пеной у рта утверждал, что в С есть зависимые типы.
1. Перевод стрелок — демагогия.
2. Я утверждал, что в С++ на стадии compile-time можно повторить трюки Пеано, примерно как показали в Хаскель. Т.е. имелся ввиду "язык программирования на шаблонах" и об этом было сказано в самый первый раз.
Ты пролабал этот важный момент, а теперь отмазываешься.
WH>Почему ты так утверждал? По тому что так было написано в книжке.
Я лишь предположил, что там могло иметься ввиду, причем, именно в форме предположения своё высказывание и построил.
Но тебя прорвало...
Ты забавен, не отрицай очевидного.
WH>Почему там так было написано? По тому что переводчик перевёл название языка Xi как Си. WH>И ты продолжал упираться пока я тебя мордой в оригинал не ткнул.
3. Демагогия опять.
— пофик как оно там в оригинале.
От этого мои наблюдения за возможностями "языка шаблонов" не меняются ни на йоту.
WH>Но что самое смешное из-за полного непонимания сути у тебя даже подозрения не возникло что там что-то не то написано.
Это твои голоса в голове.
Тебе понадобилось целых 3 приёма демагогии, чтобы "допилить" живого оппонента до удобного тебе невесть что.
Попробуй найти то самое первое обсуждение и ты увидишь — я повторил про язык шаблонов и compile-time трижды.
Три раза мне было вполне достаточно, чтобы убедиться в твоей то ли глупости, то ли невнимательности, ХЗ.
Ты тут спишь, похоже.
V>>Ага, это я, значит, не мог 8 лет сообразить, что мне говорят? )) WH>Ты до сих пор не можешь.
Не могу ЧТО?
Ну вот давай, сформулируй, что именно я не могу понять из твоих слов?
Пока что так выходило, что любые твои слова я прекрасно понимаю, но остаюсь при своём, потому что не прав как раз ты.
Вот, с формулой альфабленда разобрались? — это было херня.
С аксиомами Пеано разобрались? — я рад, что ты спустя 8 лет узнал что-то новое.
Еще?
WH>>>И очень хорошо зная возможности шаблонов я выбрал внешнюю кодогенерация, ибо знал что шаблоны на этой задаче сдохнут. V>>На приведенной формуле они не сдохнут. WH>Они сдохнут на Флойде-Уолшере.
4. Демагогия опять. Ты еще несколько дней назад обвинял в непонимании формулы собсно бленда с альфой.
Теперь уже Флойд-Уолшер.
Вот этот бесконечный перевод стрелок — в этом весь ты.
Посмотрел я и на Флойд-Уолшер, оукееййй.
Это ты его использовал для перевода м/у ц.пространствами?
Там же 4 вершины от силы, ПОКАЖИ мне, почему и где на шаблонах этот алгоритм сдохнет?
Ты же сам верно сказал: шаблоны — это уже и есть кодогенерация.
WH>>>Ты конечно можешь легко опровергнуть мои слова показав решение на шаблонах. V>>Показать решение должен был ТЫ, коль утверждал, что получил решение ЛУЧШЕ. WH>Не лучше, а единственное которое работает.
Брехня.
Если бы у тебя было другое решение, ты бы его показал и была бы возможность сравнить.
А так ты был и остаёшься голословным.
WH>Конечно можно было ещё и руками написать и изначально я это и делал. Но после того как число цветовых пространств стало большим это стало совершенно невозможно поддерживать.
Ты же сказал, что переводишь в одно цветовое пространство и потом обратно?
Т.е. тебе всего-то требовалось описать мн-во пар преобразований.
V>>Решений может быть мильон, сходу накидал, даже не компиллировал, но это пофик, общая идея понятна: WH>Понятно, что ты даже не попытался или не смог понять в чём там проблема.
Ты все эти годы говорил про какую-то формулу альфа-бленда, которую прям вот никто не мог понять!
WH>Это даже не упоминая о том, что твоё решение работает только для частного случая и будет тормозить что звиздец.
Оно все компилит c использованием векторных регистров.
В моём коде идёт операция умножения 4-х float на одно и то же число тоже float.
Это работает быстро что звиздец даже на первом SSE. ))
Тебе в любом случае от этой операции при масштабировании не убежать.
Ну только разве что ты заменишь операции с floаt на операции с фиксированной точкой, но при наличии SSE это уже НЕ работает.
Я все эти вещи плотно гонял в звуковой области и получил, что лишние приседания вокруг эмуляции фиксированной точки съедают весь профит и мешают компилятору нормально оптимизировать код.
V>>Итого, алгоритм для ВСЕГО rgba-семейства содержится в некоем RGBA_Traits. WH>RGBA бывают разные. Например, в случае с sRGBA нельзя делать бленд.
В случае с sRGBA сначала надо убрать сжатие на гамме, а потом это сжатие вернуть.
Итого — отличия только в getX и make(r, g, b, a).
WH>Быстрый и правильный бленд возможен только в линейном RGBA с предумноженными на альфу цветовыми каналами.
Предумножение можно делать как угодно, например "пачками" — так выгодней с т.з. кеша.
Как из показанного моего кода сделать такое предумножение поймёт даже студент.
Кароч, на тех е шаблонах можно вертеть логикой как угодно.
Ты ведь РЕАЛЬНО носишься с полной херней. Тривиальщиной. Сам не видишь разве?
И столько пены...
Низачот.
WH>Поэтому прежде чем масштабировать изображение с альфой его нужно сконвертировать именно в этот формат.
Дык, тем более.
Формула бленда будет только для одного формата.
WH>И именно задачу конвертации изображения в этот и некоторые другие форматы я и решал.
Ты решал задачу поиграться в интересное тебе.
Был на этом пойман за руку, отсюда вся твоя пена.
V>>Я НЕ верю, что ты бы не решил эту задачу. WH>Так я и решил. Но тебе опять голоса в голове что-то напели, и ты начал упираться.
Не показал решение для сравнения.
Решил, что голословным и высмеиваемым быть лучше.
ОК.
V>>Брехня опять. V>>Я раз 10 повторил сценарии/условия, где GLR себя хорошо показал. V>>Вместо разбора сценариев и озадачиванием — а ПОЧЕМУ так происходит с этим алгоритмом на этих сценариях, ты потребовал некий код. V>>Т.е., думать ты отказался сходу. V>>ОК. V>>Но ты опять этим забавен. WH>Вот если D. Mon что-то скажет я пойду это проверять. А если ты, то буду требовать доказательств с тебя. WH>Ибо тебя слишком много раз ловили на бреде. И не только я.
Покажи, сможешь?
Пока что меня поймал на ошибке тот человек, который обычно не входит в вашу шайку имени 3.5-й человек. Хотя, местами пытается...
Причем, что самое забавное, что в самом начале 2000-х я писал для контроллера код, который работает по USB с набирающими на тот момент популярность новыми USB HD.
Я формировал и парсил поток USB ручками, углублялся в тонкости протокола.
Т.е. в этом углубление и кроется причина кое-каких ошибок в моих суждениях. ))
Больше я не помню ошибок, чтобы кто-то мне их показал.
Я помню несогласных и даже возмущающихся, но все они сливаются, как ты со своими ЗТ, Capablity, Альфа-блендом — вообще всем. ))
Я ж подожду еще лет 8-10 (или сколько тем там потребуется на освоение очередной тривильщины? ), когда ты освоишь приколы LR-парсинга. И так же поулыбаюсь над тобой. ))
Понятно, что ты будешь опять вертеться как уж на сковороде, как в этой подветке, но что поделаешь? Се ля ви...
Вертись на здоровье.
WH>Человек написал лучший в мире генератор парсеров для компиляторов языков программирования и их ИДЕ.
Возможно. Но генератор, да еще под ИДЕ — это целый комплекс характеристик.
Вполне возможно, что в комплексе их самый лучший.
Точно так же как по отдельным моментам — возможно что и нет.
WH>Если человек увидит алгоритм, который позволит сделать этот генератор парсеров ещё лучше он его возьмёт.
Если бы да кабы.
Алгоритм. Проще. Пакрата.
Не насторожило?
Ты же в этой области работаешь...
Должен был хотя бы за воскресный вечер в виде саморазвития, как бэ...
Да чего тут говорить...
Любой выбор должен быть осознанным.
А ты сейчас как слепой котёнок тычешься.
Вот Влад проговорился рядом, что вы для восстановления используете другой обобщенный алгоритм — Эрли.
И не стыдно? ))
А столько пафоса...
Опять низачот.
V>>Для любых алгоритмов в области разбора по формальным грамматикам обязательно упоминается, где они хороши, а где не очень. V>>Т.е. пытаться что-то там обсуждать в отрыве от вида грамматик и характера входных данных — это махровое дилетанство. WH>Контекст моей работы всегда был грамматики языков программирования и код на языках программирования. И тебе это прекрасно известно.
Языки программирования сейчас тоже сильно разные бывают, как и ожидаемые размеры исходников.
Здравствуйте, WolfHound, Вы писали:
V>>Ты действительно не понимаешь, чего я от тебя жду? V>>Ну вот отбросив всякое тролленье и обмен "любезностями", ы? WH>Я понимаю, что ты не можешь доказать наличии ЗТ в хаскеле и пытаешься съехать с темы.
Здравствуйте, WolfHound, Вы писали:
V>>При том, что этот WolfHound вникнуть в простейшую предметную область GLR не в состоянии (или не в желании), отсюда такая низкая заведомая вероятность. Итого, херней мается человек и другим моск выносит. WH>Человек написал лучший в мире генератор парсеров для компиляторов языков программирования и их ИДЕ. WH>Если человек увидит алгоритм, который позволит сделать этот генератор парсеров ещё лучше он его возьмёт. WH>Но человек не будет тратить своё время на проверку слов конченного трепла.
Здравствуйте, vdimas, Вы писали:
V>Пока что меня поймал на ошибке тот человек, который обычно не входит в вашу шайку имени 3.5-й человек. Хотя, местами пытается... V>Причем, что самое забавное, что в самом начале 2000-х я писал для контроллера код, который работает по USB с набирающими на тот момент популярность новыми USB HD. V>Я формировал и парсил поток USB ручками, углублялся в тонкости протокола. V>Т.е. в этом углубление и кроется причина кое-каких ошибок в моих суждениях. ))
Раз уж вспомнилось, то, пользуясь случаем, хочу в какой-то степени извиниться за свой тон в той дискуссии. ) Что-то я в тот момент был какой-то злой, а когда мне встретился в общение оппонент с уверенным видом заявляющий очевидную ерунду, то я как-то совсем вышел за рамки... Не думаю, что моё поведение тогда было полностью правильным, даже не смотря на техническую правоту.)
P.S. Всё, всё, исчерпал все свои лимиты оффтопика, причём сразу в одной темке. )))
Здравствуйте, WolfHound, Вы писали:
WH>Извините. Мне нужно на 2-3 порядка быстрее.
У тебя грамматики на 2-3 порядка проще.
Там же рядом коммент:
Замеры делали в самом начале разработки. 5.тыс «рыбных» комментариев(1 комментарий ~ 400 символов) с 20 простыми цепочками обработались за ~10сек
"В самом начале" я тоже для Эрли замеры делал, когда выбирал технологию обобщенного парсинга.
Это был кошмар.
V>>А вот для парсера с откатами в случае недостаточности просмотра на 1, глубокая вложенность выражений может стать больным местом. Не зря расширения Пакрата и ALL используют мемоизацию и прочие трюки. WH>И этот человек утверждает, что что-то понимает. WH>У пакрата мемоизация не расширение, а его суть.
У алгоритма Пакрата есть расширения (для левой рекурсии).
Ну и в этом же сообщении, прямо на которое ты отвечаешь, написано:
Пакрат — это крайний случай мемоизации.
Тщательнее надо демагогию разводить.
V>>Блин, а чего вы мне голову морочите, если у вас вообще Эрли??? )) WH>Эрли только до неоднозначностей и для восстановления.
Т.е. для нормального процесса набития текста, где 90% времени текст невалиден?
WH>И это если забыть про мелочи типа оценки качества восстановления прямо во время разбора. Ибо способов восстановиться после ошибки много и нужно взять не какой попало, а лучший.
Чтобы взять лучший, надо иметь выбор. У тебя выбора не было.
V>>Кстате, я брал именно твой порт Эрли на .Net и с пол-тыка ускорил его втрое. V>>И всё-равно оно тормозит безбожно... WH>А зачем ты его взял.
Сравнить, ес-но.
Мне нужен был выбор.
WH>Чё GLR не написал? Он же круче.
Написал, выбрал.
WH>Так ты покажи мне ГЛР парсер который восстанавливается также хорошо, как парсер нитры.
У тебя прямо в таблице LR-разбора ДКА/НКА содержатся допустимые нетерминалы.
Например, нетерминал скобки.
State {
Trans transitions_;
...
};
State currentState = ...;
Trans::Symbol sym = currentState.transitions_.first().key();
Для нетерминалов-фиксированных цепочек терминалов можно брать прямо их содержимое.
Можно брать не обязательно 1-й элемент, а несколько первых для формирования подсказки об ошибке.
Сами правила в исходнике разместить по желаемому порядку и строить ДКА/НКА с сохранением порядка правил в переходах.
Я прямо так и выдавал ошибку: "конец потока, хотя ожидается сегмент такой-то",
или "неожиданный сегмент такой-то в позиции такой-то, ожидаемые сегменты: =список 1..3 элемента=".
Здравствуйте, vdimas, Вы писали:
V>Там же рядом коммент: V>
V>Замеры делали в самом начале разработки. 5.тыс «рыбных» комментариев(1 комментарий ~ 400 символов) с 20 простыми цепочками обработались за ~10сек
(5000*400)/10=200'000
Всё ещё нужно поднять скорость на порядок.
V>"В самом начале" я тоже для Эрли замеры делал, когда выбирал технологию обобщенного парсинга. V>Это был кошмар.
Кошмар это твой ГЛР. Причём во всех работах пишут, что он кошмар.
V>У алгоритма Пакрата есть расширения (для левой рекурсии).
Причём тут вообще левая рекурсия?
V>>>Блин, а чего вы мне голову морочите, если у вас вообще Эрли??? )) WH>>Эрли только до неоднозначностей и для восстановления. V>Т.е. для нормального процесса набития текста, где 90% времени текст невалиден?
Но и в этом случае 99% кода в файле валидно. И валидный код разбирается основным парсером даже если в файле есть ошибки.
WH>>И это если забыть про мелочи типа оценки качества восстановления прямо во время разбора. Ибо способов восстановиться после ошибки много и нужно взять не какой попало, а лучший. V>Чтобы взять лучший, надо иметь выбор. У тебя выбора не было. Конечно... я ничего не понимаю в восстановлении после ошибок. Вот только мой генератор парсеров восстанавливается лучше всех...
WH>>Так ты покажи мне ГЛР парсер который восстанавливается также хорошо, как парсер нитры. V>У тебя прямо в таблице LR-разбора ДКА/НКА содержатся допустимые нетерминалы.
Ты давай не языком болтай, а код покажи. Можно чужой.
Засунем в него этот пример и посмотрим, что будет.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>>>Так ты покажи мне ГЛР парсер который восстанавливается также хорошо, как парсер нитры. V>>У тебя прямо в таблице LR-разбора ДКА/НКА содержатся допустимые нетерминалы. WH>Ты давай не языком болтай, а код покажи. Можно чужой.
Так ты меня сориентируй по времени, сколько вы потратили на разработку функциональности восстановления?
Я тебе показал, что все необходимые данные в таблице переходов есть, дело за кодом, который их интерпретирует.
WH>Засунем в него этот пример и посмотрим, что будет.
Ну, уже на выходных начал по-немногу пилить способ абстрактного описания грамматики хотя бы для Шарпа, бо в моих проектах грамматика нифига не абстрактна, а привязана к прикладному описанию. Это тоже вполне себе задачка.
Опять же — лексер полноценный пилить или просто "токенайзер"? ))
В полноценном лексере надо сжимать таблицу переходов по вертикали тоже, т.е. отображать входные символы на их минимизированную кодировку.
В общем, "вынь да положь" из уст тех, кто 100% рабочего времени занимается парсерами и должен как бы представлять весь комплекс задач для минимального примера — это уже странно. Если там всё так просто, чего же вы столько лет на это потратили и продолжаете тратить?
Здравствуйте, vdimas, Вы писали:
V>Я тебе показал, что все необходимые данные в таблице переходов есть, дело за кодом, который их интерпретирует.
Ну раз это малое то за пару дней справишься?
V>В общем, "вынь да положь" из уст тех, кто 100% рабочего времени занимается парсерами и должен как бы представлять весь комплекс задач для минимального примера — это уже странно. Если там всё так просто, чего же вы столько лет на это потратили и продолжаете тратить?
Это ты тут говоришь, что там всё просто.
Если там всё так просто, то должен же быть ГЛР парсер который парсит быстрее и восстанавливается лучше, чем нитра.
Тем более что нитру на низком уровне я ещё не оптимизировал. Да и алгоритм восстановления там можно сделать лучше.
Или опять от тебя кроме трёпа ничего не будет?
И это при том что я пока даже не требую, чтобы парсер поддерживал изменение грамматики во время разбора (это КЗ). А это одно из главных функциональных требований к парсеру нитры.
Плюс есть планы и понимание как добавить ещё некоторые КЗ возможности без заметного снижения производительности.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
</offtopic>
