можно даже ввести численную метрику оценки эффективности кода с точки зрения читаемости этого кода! Вы в вашей книжке что-то про это видели? Можете доказать математически что копи-паст в общем случае хуже чем параметризованный код? При этом существуют исключения из этого правила при определенных условиях.
Я к тому что есть в программировании элементарные вещи, про которые прочитать оказывается негде.
Если сосредоточиться на изучении только теории древних греков, вы никогда не дойдете до теории относительности.
Древние греки придумали не самую плохую теорию, наверно даже передовую для своего времени, но только для своего времени.
Не позволяйте одной книжке ограничить ваш кругозор древней теорией!
Очень зря. В любом учебнике по КА Вы найдёте теорему, что для любого КА существует эквивалентное ему регулярное выражение
в вашем учебнике определен критерий эффективности алгоритма?
Вы можете сравнить эффективность алгоритмов разного типа на конкретной аппаратной платформе? Можете получить числинную абсолютную метрику для сравнения?
Я думаю что нет, и тогда этот учебник на практике бесполезен. То что запрограммировать можно что угодно, мне не надо доказывать я и так это знаю как очевидную аксиому.
Я как раз про это вам и напоминал, про то что это теория из прошлого века, для людей которые все еще сомневаются в возможностях программирования.
Уже давно пора заниматься оценкой эффективности разных способов построения алгоритмов, вместо того чтобы снова и снова доказывать что можно запрограммировать что угодно.
Для повышения производительности, целесообразно построить по моему КА эквивалентное ему регулярное выражение.
Я что-то очень сомневаюсь что КА поможет вам (или кому-либо) найти правильное регулярное выражение, потому что, насколько я помню и понимаю, это очень разные подходы, вы либо думаете в терминах КА либо в терминах регулярных выражений, фактически это разные пространства решений, но одно на другое можно натянуть конечно, но такой симбиоз будет очень не эффективным решением насколько я знаю.
Я с регулярными выражениями работал 20 лет назад еще на языке Perl, после нескольких недель практики у меня был восторг от того, что я могу написать любую обработку строк на них запросто, я поэтому это и запомнил, восторг не забывается. Мой вам совет, забудьте хоть на время про КА и попрактикуйтесь в регулярных выражениях, возможно через какое-то время вы увидите мир новыми глазами.
Эту задачу мне оказалось проще описать конечным автоматом, чем регулярным выражением
есть некоторая разница между
"мне оказалось проще описать "
и
"мое решение (определенным способом) оказалось проще" - тут вопрос а насколько эффективным было решение тем способом от которого вы отказались, может вы что-то там неправильно поняли и поэтому нашли не самое оптимальное решение из возможных? С чем вы сравнивали? -мы же не знаем.
Ни того ни другого мы, к сожалению, проверить не сможем в этом случае, я полагаю. Поэтому остается только порадоваться вашим успехам, задача решена - это главное!
И да, все это легко реализуется руками, но было бы чуть удобнее, если бы оно уже было "из коробки". Но раз нет - говорить не о чем.
XML парсер существует (даже с С++ интерфейсом) и успешно (хотя не всегда конечно) используется уже более 20 лет, и интерфейс к нему существует столько же. Вы считаете что за 20 лет никто бы не догадался сделать что-то лучше, если оно действительно лучше?
Потом что значит "чуть удобнее"? Так можно дойти до того, что было бы даже намного удобнее если бы всю работу уже кто-то сделал за вас, только возникает тогда вопрос, а вы то зачем тогда нужны как технический специалист, коробки переставлять? Никогда не понимал такого отношения!
Есть возможность такие вещи автоматически распознавать (т.е. не reader.Name == "Идентификатор", но reader.Name == "ТипДокумента.Идентификатор")
тогда вам не ридер нужен, а язык запросов, например XPath (XML Path Language)
Ридер просто загружает XML из файла в память, есть два основных способа, загрузить и отдать пользователю полностью дерево XML объектов (узлов, элементов, ... как хотите называйте)
или отдавать XML объекты по мере чтения.
Поскольку поиск все равно должен читать XML, сначала, а потом еще проверить условие запроса, и вернуть пользователю только то что соответствует вашему запросу, поиск также в основе своей использует два этих метода чтения.
Через XPath можно запросить, то есть найти, все узлы которые имеют Идентификатор как дочерний узел, можно найти все узлы путь к которым заканчивается на "ТипДокумента.Идентификатор"
Вам только нужно решить что вы хотите видеть в ответ на ваш запрос. Проблема в том что там всегда есть очень много вариантов построения запросов к XML, поэтому правильное их построение это особое исскусство, которое подвластно очень не многим.
В общем задача состоит в том чтобы найти уникальную метрику последовательности элементов десятичного (или в общем случае N-арного) множества:
а1, а2,...а9
или
A1, A2,...An
метрику которая однозначно преобразуется в метрику последовательности:
а1, а2,...а9 + х
где х - это вычисленный елемент новой последовательности позиция которого определяется исходной метрикой, то есть нужна еще одна функция параметрами которой будут метрика последовательности и позиция добавленного элемента:
F(М(а1, а2,...а9), П) => элемент десятичного множества для позиции П
должна также отображаться в элемент десятичного множества. Поэтому отображения на самом деле нужно два(!), а не одно:
отображение последовательности десятичных элементов в метрику последовательности которая тоже должна быть десятичным елементом;
и отображение двух десятичных элементов в десятичный элемент новой последовательности
В общем это обычный случай ошибки с формулировкой математической задачи! Искать надо два достаточно простых отображения, а вы пытались искать одно сложное.
Можно, кстати, легко доказать что вашего сложного отображения 10^9 в 10^10 не существует:
Если бы оно существовало, то существовало бы и отображение 10^10 в 10^11, но 10-чный элемент не может кодировать 11-ричную позицию!
Тяжело искать черную кошку в темной комнате, когда ее там нет.
Так у частоты процессора есть известный предел, который определяется размером атома и скоростью света. 4ГГц это примерно половина этого предела (кажется), дальше частоту повышать очень дорого. Гораздо дешевле добавить 3 или 7 или 15 ядер, но при наличии больше одного ядра оверклокинг может быть только штатный то есть очень хорошо просчитанный (я догадываюсь). На мой взгляд +15 ядер это гораздо круче чем повышение частоты в 2 раза, вы только представьте себе как эти ядра доступ к памяти шарят, например.
Удивительно как быстро улетучиваются базовые знания из ИТ сообщества.
между множествами 10^9(записанные Незнайкой разряды)*10(номер пропущенного) и 10^10 (десятизначное число, которое видит Шпунтик)
потому что нужно отображение одной десятичной цифры в десятиразрядное число!
потому что 9 заданных разрядов ни на что фактически не влияют, так как могут быть произвольными и должны однозначно отобразиться тоже в одну десятичную цифру!
На самом деле кодируется одна десятичная цифра! И кодируется она с помощью другой единственной десятичной цифры! Единственный способ кодирования одной десятичной цифры с помощью другой десятичной цифры это операция сложения по модулю
Сколько есть вариантов отобразить 10^9 в одну десятичную цифру? А бесконечное количество!
Можно сразу сложить по модулю, можно к каждому разряду прибавить 5 по модулю и после этого все сложить по модулю, можно 5 раз прибавить 7 по модулю к каждому и потом сложить по модулю...
операция сложения по модулю линейная ее бесконечно можно повторять чтобы все равно получить однозначное отображение всего входного множества на выходное множество.
9 десятичных цифр одназначно отображаются в позицию (то есть в заданную десятичную цифру номера этой позиции) единственным способом суммированием всех 9 + номер позиции по модулю! Потому что при декодировании этого номера из 10 цифр мы не знаем исходный порядок в котором эти цифры формировали код. Единственная операция (она же способ отображения) которая позволяет игнорировать этот порядок, то есть результат которой не зависит от этого порядка это операция суммирования по модулю.
Множество тут одно из 10-ти элементов только с этим множеством надо рассматривать операции-отображения.
Gpt ничего не придумывает, он просто берет базу знаний, написанную людьми , и предугадывает наиболее вероятный ответ
только не предугадывает, а вычисляет, наверно. Ведь вот это:
вычисляет наиболее вероятный
действительно, фактически равно одному слову "предугадывает ", что характерно, так сказать :).
Поэтому, наверно, должно быть или
"вычисляет наиболее вероятный ответ"
или просто
"предугадывает ответ"
Как известно математики обычно дают абсолютно точный ответ, и абсолютно бесполезный, вот я вас как математик и поправляю, чтобы соответствовать званию математика :).
И рабочих стало намного больше, чем было ремесленников. Причину мы знаем, снижение себестоимости, больший спрос и все такое.
Я бы так однозначно не утверждал, что мы знаем причину или даже просто можем ее так легко сформулировать.
Вы вот вспомните как люди построили множество пирамид в пустыне, был тогда спрос на пирамиды? -Конечно был! А что с производительностью? А производительность была не важна, важна была осуществимость идеи! То есть бывает так что производительность не надо упоминать, и мы с вами про какое направление человеческой деятельности говорим, не совсем понятно, и непонятно, соответственно, актуальность упоминания производительности.
А вот Алан Тьюринг не был фараоном, но смог организовать людей сделать машину которая умеет делать расчеты. Я к чему, важна не производительность, а правильное целеполагание, правильное понимание результата и того каким способом достичь этого результата. Я боюсь что у ИИ целепологание резко отличается от человеческого, если оно вообще есть.
С ИИ мне кажется мы скорее подходим пока под первый вариант. От ремесленников к рабочим из крестьян
я думаю крестьяне не оценили бы вашего позитива, вот что говорят крестьяне в лице Григория из Тихого Дона, примерно, по этому вопросу:
- ошибаешься ты, Аксинья, ошибаешься! Гутаришь, а послухать нечего. Ну, куда я
пойду от хозяйства? Опять же, на службу мне на энтот год. Не годится
дело... От земли я никуда не тронусь. Тут степь, дыхнуть есть чем, а там?
Прошлую зиму ездил я с батей на станцию, так было-к пропал. Паровозы
ревут, дух там чижелый от горелого угля. Как народ живет - не знаю, может,
они привыкли к этому самому угару... - Григорий сплевывает и еще раз
Совершенствование средств производства зачастую приводило к росту числа тех, кто их использует.
Мне кажется пример с конвеером в контексте кто кого использует очень не однозначный :). Непонятно это милионы используют конвеер или это владельцы конвеера испльзуют миллионы посредством конвеера.
Кстати конвеер сам по себе тоже очень интересное изобретение, не знаю можно ли сравнивать с ГПТ, но у меня аналогия явно напрашивается.
То есть средства разработки сильно упростятся и станут доступны большему количеству людей.
Как вы считаете физика сильно упростилась после того как была сформулирована теория относительности?
А после открытия транзистора и замены им ламповой техники, насколько упростилась эта техника? А транзисторы ведь проще чем лампы... или нет? Или проще только в каком то смысле?
Не надо ничего придумывать, надо просто вспомнить как что происходило-развивалось раньше.
Кстати лично для меня средства разработки ОЧЕНЬ сильно упростились с начала 90-х годов прошлого века, но я не сказал бы что они стали доступнее большему количеству людей, хотя количество людей которые ими пользуются или пытаются пользоваться безусловно сильно возросло.
я честно говоря тоже с трудом понял главный посыл этой заметки (вряд ли тянет на статью), то есть понял только когда прочитал ваши пояснения.
Интересно что это написал тот кто, насколько я понимаю, не только участвует в мероприятии под сарказмом, но, насколько я понимаю, еще и победил в нем на каком то направлении. Получается что-то вроде "пчелы против меда" на мой взгляд, выглядит (читается) очень странно.
А где написано что язык создан для производительности, или это только ваше пожелание?
Вроде как языки создают для общения, алгоритмические для общения с машиной, как мне это представляется. А вот о чем вы сможете договориться с машиной на таком языке (любом) это вопрос ваших способностей и таланта, в основном, как мне кажется.
Заметьте договориться надо с машиной, а не скомпилятором!
Вы же вот пишите:
Дэниел Лемир, может, и справился бы, но мы (как и авторы всех реализаций, когда я последний раз проверял) — не он
Зачем же вы себя так ограничиваете в том чего вы могли бы достичь? Хотя я честно говоря не знаю кто такой Дэниел Лемир, но теперь посмотрю конечно.
можно даже ввести численную метрику оценки эффективности кода с точки зрения читаемости этого кода! Вы в вашей книжке что-то про это видели? Можете доказать математически что копи-паст в общем случае хуже чем параметризованный код? При этом существуют исключения из этого правила при определенных условиях.
Я к тому что есть в программировании элементарные вещи, про которые прочитать оказывается негде.
Если сосредоточиться на изучении только теории древних греков, вы никогда не дойдете до теории относительности.
Древние греки придумали не самую плохую теорию, наверно даже передовую для своего времени, но только для своего времени.
Не позволяйте одной книжке ограничить ваш кругозор древней теорией!
в вашем учебнике определен критерий эффективности алгоритма?
Вы можете сравнить эффективность алгоритмов разного типа на конкретной аппаратной платформе? Можете получить числинную абсолютную метрику для сравнения?
Я думаю что нет, и тогда этот учебник на практике бесполезен. То что запрограммировать можно что угодно, мне не надо доказывать я и так это знаю как очевидную аксиому.
Я как раз про это вам и напоминал, про то что это теория из прошлого века, для людей которые все еще сомневаются в возможностях программирования.
Уже давно пора заниматься оценкой эффективности разных способов построения алгоритмов, вместо того чтобы снова и снова доказывать что можно запрограммировать что угодно.
Я что-то очень сомневаюсь что КА поможет вам (или кому-либо) найти правильное регулярное выражение, потому что, насколько я помню и понимаю, это очень разные подходы, вы либо думаете в терминах КА либо в терминах регулярных выражений, фактически это разные пространства решений, но одно на другое можно натянуть конечно, но такой симбиоз будет очень не эффективным решением насколько я знаю.
Я с регулярными выражениями работал 20 лет назад еще на языке Perl, после нескольких недель практики у меня был восторг от того, что я могу написать любую обработку строк на них запросто, я поэтому это и запомнил, восторг не забывается. Мой вам совет, забудьте хоть на время про КА и попрактикуйтесь в регулярных выражениях, возможно через какое-то время вы увидите мир новыми глазами.
действительно классика: классика маразма!
есть некоторая разница между
"мне оказалось проще описать "
и
"мое решение (определенным способом) оказалось проще" - тут вопрос а насколько эффективным было решение тем способом от которого вы отказались, может вы что-то там неправильно поняли и поэтому нашли не самое оптимальное решение из возможных? С чем вы сравнивали? -мы же не знаем.
Ни того ни другого мы, к сожалению, проверить не сможем в этом случае, я полагаю. Поэтому остается только порадоваться вашим успехам, задача решена - это главное!
или считать черных кошек в темной комнате, когда они там присутствуют наряду с черными собачками того же размера :). Интересно что труднее :) ?
XML парсер существует (даже с С++ интерфейсом) и успешно (хотя не всегда конечно) используется уже более 20 лет, и интерфейс к нему существует столько же. Вы считаете что за 20 лет никто бы не догадался сделать что-то лучше, если оно действительно лучше?
Потом что значит "чуть удобнее"? Так можно дойти до того, что было бы даже намного удобнее если бы всю работу уже кто-то сделал за вас, только возникает тогда вопрос, а вы то зачем тогда нужны как технический специалист, коробки переставлять? Никогда не понимал такого отношения!
тогда вам не ридер нужен, а язык запросов, например XPath (XML Path Language)
Ридер просто загружает XML из файла в память, есть два основных способа, загрузить и отдать пользователю полностью дерево XML объектов (узлов, элементов, ... как хотите называйте)
или отдавать XML объекты по мере чтения.
Поскольку поиск все равно должен читать XML, сначала, а потом еще проверить условие запроса, и вернуть пользователю только то что соответствует вашему запросу, поиск также в основе своей использует два этих метода чтения.
Через XPath можно запросить, то есть найти, все узлы которые имеют
Идентификаторкак дочерний узел, можно найти все узлы путь к которым заканчивается на "ТипДокумента.Идентификатор"Вам только нужно решить что вы хотите видеть в ответ на ваш запрос. Проблема в том что там всегда есть очень много вариантов построения запросов к XML, поэтому правильное их построение это особое исскусство, которое подвластно очень не многим.
В общем задача состоит в том чтобы найти уникальную метрику последовательности элементов десятичного (или в общем случае N-арного) множества:
а1, а2,...а9
или
A1, A2,...An
метрику которая однозначно преобразуется в метрику последовательности:
а1, а2,...а9 + х
где х - это вычисленный елемент новой последовательности позиция которого определяется исходной метрикой, то есть нужна еще одна функция параметрами которой будут метрика последовательности и позиция добавленного элемента:
F(М(а1, а2,...а9), П) => элемент десятичного множества для позиции П
должна также отображаться в элемент десятичного множества. Поэтому отображения на самом деле нужно два(!), а не одно:
отображение последовательности десятичных элементов в метрику последовательности которая тоже должна быть десятичным елементом;
и отображение двух десятичных элементов в десятичный элемент новой последовательности
В общем это обычный случай ошибки с формулировкой математической задачи! Искать надо два достаточно простых отображения, а вы пытались искать одно сложное.
Можно, кстати, легко доказать что вашего сложного отображения 10^9 в 10^10 не существует:
Если бы оно существовало, то существовало бы и отображение 10^10 в 10^11, но 10-чный элемент не может кодировать 11-ричную позицию!
Тяжело искать черную кошку в темной комнате, когда ее там нет.
Так у частоты процессора есть известный предел, который определяется размером атома и скоростью света. 4ГГц это примерно половина этого предела (кажется), дальше частоту повышать очень дорого. Гораздо дешевле добавить 3 или 7 или 15 ядер, но при наличии больше одного ядра оверклокинг может быть только штатный то есть очень хорошо просчитанный (я догадываюсь). На мой взгляд +15 ядер это гораздо круче чем повышение частоты в 2 раза, вы только представьте себе как эти ядра доступ к памяти шарят, например.
Удивительно как быстро улетучиваются базовые знания из ИТ сообщества.
интересно, какой консистенции выделения производит динамическая память в нашем коде.
Надо быть очень осторожным используя великий и могучий язык, могущество иногда боком выходит.
Непонятно при чем тут отображение
потому что нужно отображение одной десятичной цифры в десятиразрядное число!
потому что 9 заданных разрядов ни на что фактически не влияют, так как могут быть произвольными и должны однозначно отобразиться тоже в одну десятичную цифру!
На самом деле кодируется одна десятичная цифра! И кодируется она с помощью другой единственной десятичной цифры! Единственный способ кодирования одной десятичной цифры с помощью другой десятичной цифры это операция сложения по модулю
Сколько есть вариантов отобразить 10^9 в одну десятичную цифру? А бесконечное количество!
Можно сразу сложить по модулю, можно к каждому разряду прибавить 5 по модулю и после этого все сложить по модулю, можно 5 раз прибавить 7 по модулю к каждому и потом сложить по модулю...
операция сложения по модулю линейная ее бесконечно можно повторять чтобы все равно получить однозначное отображение всего входного множества на выходное множество.
9 десятичных цифр одназначно отображаются в позицию (то есть в заданную десятичную цифру номера этой позиции) единственным способом суммированием всех 9 + номер позиции по модулю! Потому что при декодировании этого номера из 10 цифр мы не знаем исходный порядок в котором эти цифры формировали код. Единственная операция (она же способ отображения) которая позволяет игнорировать этот порядок, то есть результат которой не зависит от этого порядка это операция суммирования по модулю.
Множество тут одно из 10-ти элементов только с этим множеством надо рассматривать операции-отображения.
Со 4-го класса C/C++, алгебра Буля, целочисленная арифметика, вычисления целочисленной арифметики на логических элементах.
только не предугадывает, а вычисляет, наверно. Ведь вот это:
действительно, фактически равно одному слову "предугадывает ", что характерно, так сказать :).
Поэтому, наверно, должно быть или
"вычисляет наиболее вероятный ответ"
или просто
"предугадывает ответ"
Как известно математики обычно дают абсолютно точный ответ, и абсолютно бесполезный, вот я вас как математик и поправляю, чтобы соответствовать званию математика :).
Я бы так однозначно не утверждал, что мы знаем причину или даже просто можем ее так легко сформулировать.
Вы вот вспомните как люди построили множество пирамид в пустыне, был тогда спрос на пирамиды? -Конечно был! А что с производительностью? А производительность была не важна, важна была осуществимость идеи! То есть бывает так что производительность не надо упоминать, и мы с вами про какое направление человеческой деятельности говорим, не совсем понятно, и непонятно, соответственно, актуальность упоминания производительности.
А вот Алан Тьюринг не был фараоном, но смог организовать людей сделать машину которая умеет делать расчеты. Я к чему, важна не производительность, а правильное целеполагание, правильное понимание результата и того каким способом достичь этого результата. Я боюсь что у ИИ целепологание резко отличается от человеческого, если оно вообще есть.
я думаю крестьяне не оценили бы вашего позитива, вот что говорят крестьяне в лице Григория из Тихого Дона, примерно, по этому вопросу:
Мне кажется пример с конвеером в контексте кто кого использует очень не однозначный :). Непонятно это милионы используют конвеер или это владельцы конвеера испльзуют миллионы посредством конвеера.
Кстати конвеер сам по себе тоже очень интересное изобретение, не знаю можно ли сравнивать с ГПТ, но у меня аналогия явно напрашивается.
Как вы считаете физика сильно упростилась после того как была сформулирована теория относительности?
А после открытия транзистора и замены им ламповой техники, насколько упростилась эта техника? А транзисторы ведь проще чем лампы... или нет? Или проще только в каком то смысле?
Не надо ничего придумывать, надо просто вспомнить как что происходило-развивалось раньше.
Кстати лично для меня средства разработки ОЧЕНЬ сильно упростились с начала 90-х годов прошлого века, но я не сказал бы что они стали доступнее большему количеству людей, хотя количество людей которые ими пользуются или пытаются пользоваться безусловно сильно возросло.
Прогресс идет давно и как-то волнами.
На смену античному рассвету приходит Святая инквизиция,
на смену научным прорывам, период мировых войн...
В общем скрипач, то есть программист не нужен, нужно КЦ.
я честно говоря тоже с трудом понял главный посыл этой заметки (вряд ли тянет на статью), то есть понял только когда прочитал ваши пояснения.
Интересно что это написал тот кто, насколько я понимаю, не только участвует в мероприятии под сарказмом, но, насколько я понимаю, еще и победил в нем на каком то направлении. Получается что-то вроде "пчелы против меда" на мой взгляд, выглядит (читается) очень странно.
А где написано что язык создан для производительности, или это только ваше пожелание?
Вроде как языки создают для общения, алгоритмические для общения с машиной, как мне это представляется. А вот о чем вы сможете договориться с машиной на таком языке (любом) это вопрос ваших способностей и таланта, в основном, как мне кажется.
Заметьте договориться надо с машиной, а не скомпилятором!
Вы же вот пишите:
Зачем же вы себя так ограничиваете в том чего вы могли бы достичь? Хотя я честно говоря не знаю кто такой Дэниел Лемир, но теперь посмотрю конечно.