И да, все это легко реализуется руками, но было бы чуть удобнее, если бы оно уже было "из коробки". Но раз нет - говорить не о чем.
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-х годов прошлого века, но я не сказал бы что они стали доступнее большему количеству людей, хотя количество людей которые ими пользуются или пытаются пользоваться безусловно сильно возросло.
я честно говоря тоже с трудом понял главный посыл этой заметки (вряд ли тянет на статью), то есть понял только когда прочитал ваши пояснения.
Интересно что это написал тот кто, насколько я понимаю, не только участвует в мероприятии под сарказмом, но, насколько я понимаю, еще и победил в нем на каком то направлении. Получается что-то вроде "пчелы против меда" на мой взгляд, выглядит (читается) очень странно.
А где написано что язык создан для производительности, или это только ваше пожелание?
Вроде как языки создают для общения, алгоритмические для общения с машиной, как мне это представляется. А вот о чем вы сможете договориться с машиной на таком языке (любом) это вопрос ваших способностей и таланта, в основном, как мне кажется.
Заметьте договориться надо с машиной, а не скомпилятором!
Вы же вот пишите:
Дэниел Лемир, может, и справился бы, но мы (как и авторы всех реализаций, когда я последний раз проверял) — не он
Зачем же вы себя так ограничиваете в том чего вы могли бы достичь? Хотя я честно говоря не знаю кто такой Дэниел Лемир, но теперь посмотрю конечно.
Эта претензия - не к самому языку C++, а лишь к его стандартной библиотеке, которая написана на нем же.
я бы даже дальше пошел в этом направлении:
если это претензия к производительности (скорости исполнения) сгенерированного кода, то это претензия не к языку и не к библиотеке, а к разработчикам конкретной версии компилятора и библиотеки. И, возможно, частично, к тем кто занимается поиском и пользуется разными трюками привязанными к особенностям работы определенной версии компилятора.
Писать код который заточен под особенности работы определенного компилятора мне кажется очень сомнительным направлением приложения усилий.
Все это знание особенностей работы разных компиляторов с точки зрения производительности, оно мимолетно, сегодня одно, завтра другое.
Ворочающий миллионами в день и потенциально могущий привести к очень неприятным судебным процессам код нельзя писать на асме.
Что можно сказать, в общем, разные у нас области применения, и подходы соответственно разные. Всегда интересно познакомиться с чужой проблематикой хотя бы издали.
Я понял что система у вас очень сложная и неодназначная и поэтому вдвойне интересная, спасибо. Глобальные проблемы мы все равно не решим в чате.
вы же вот мне ассемблер демонстрируете, значит вы все равно проверяете что вам компилятор генерирует, только вы каким то косвенным методом работаете, пытаетесь изобрести С++ код по которому компилятор сгенерирует самый лучший ассемблер, так еще и настройки компилятора вам надо контролировать-выписывать.
Раз вы в состоянии проверить что ассемблер хороший, что вам мешает написать этот ассемблер напрямую без капризного посредника в виде С++ компилятора? Нафига вам темплейты сдались? У меня есть только одно объяснение: рассказы про темплейты ценятся гораздо больше чем рассказы про ассемблер. Ассемблер почему то воспринимается как что-то из прошлого века, но только без него ничего не работает в конечном итоге.
вон вы про что! Ну тогда вам точно куски на ассемблере надо писать, а вы взялись темплейты с решениями на виртуальных функциях сравнивать. Не зря вы в начали написали что перешли на что-то другое от темплейтов. Виртуальные функции на этом уровне точно нет смысла применять что там сравнивать то.
10 - 20 даже 100 ассемблерных инструкций всегда проще понять и даже переписать если надо, чем выгребать все сайд эффекты с темплейтами помноженными на оптимизацию в компиляторе которая зависит от десятка настроек, и еще и меняется с версией компилятора. Дело даже не в скорости, темплейты на таком уровне это просто не надежное решение даже.
сообщения от биржи у вас через сокет приходят? три строчки вы не заметите на фоне кода который из сокета читает, мне кажется вы не совсем коректно описываете проблему или причину проблемы которая у вас видимо действительно присутствует, мне кажется.
или считать черных кошек в темной комнате, когда они там присутствуют наряду с черными собачками того же размера :). Интересно что труднее :) ?
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-х годов прошлого века, но я не сказал бы что они стали доступнее большему количеству людей, хотя количество людей которые ими пользуются или пытаются пользоваться безусловно сильно возросло.
Прогресс идет давно и как-то волнами.
На смену античному рассвету приходит Святая инквизиция,
на смену научным прорывам, период мировых войн...
В общем скрипач, то есть программист не нужен, нужно КЦ.
я честно говоря тоже с трудом понял главный посыл этой заметки (вряд ли тянет на статью), то есть понял только когда прочитал ваши пояснения.
Интересно что это написал тот кто, насколько я понимаю, не только участвует в мероприятии под сарказмом, но, насколько я понимаю, еще и победил в нем на каком то направлении. Получается что-то вроде "пчелы против меда" на мой взгляд, выглядит (читается) очень странно.
А где написано что язык создан для производительности, или это только ваше пожелание?
Вроде как языки создают для общения, алгоритмические для общения с машиной, как мне это представляется. А вот о чем вы сможете договориться с машиной на таком языке (любом) это вопрос ваших способностей и таланта, в основном, как мне кажется.
Заметьте договориться надо с машиной, а не скомпилятором!
Вы же вот пишите:
Зачем же вы себя так ограничиваете в том чего вы могли бы достичь? Хотя я честно говоря не знаю кто такой Дэниел Лемир, но теперь посмотрю конечно.
я бы даже дальше пошел в этом направлении:
если это претензия к производительности (скорости исполнения) сгенерированного кода, то это претензия не к языку и не к библиотеке, а к разработчикам конкретной версии компилятора и библиотеки. И, возможно, частично, к тем кто занимается поиском и пользуется разными трюками привязанными к особенностям работы определенной версии компилятора.
Писать код который заточен под особенности работы определенного компилятора мне кажется очень сомнительным направлением приложения усилий.
Все это знание особенностей работы разных компиляторов с точки зрения производительности, оно мимолетно, сегодня одно, завтра другое.
Что можно сказать, в общем, разные у нас области применения, и подходы соответственно разные. Всегда интересно познакомиться с чужой проблематикой хотя бы издали.
Я понял что система у вас очень сложная и неодназначная и поэтому вдвойне интересная, спасибо. Глобальные проблемы мы все равно не решим в чате.
вы же вот мне ассемблер демонстрируете, значит вы все равно проверяете что вам компилятор генерирует, только вы каким то косвенным методом работаете, пытаетесь изобрести С++ код по которому компилятор сгенерирует самый лучший ассемблер, так еще и настройки компилятора вам надо контролировать-выписывать.
Раз вы в состоянии проверить что ассемблер хороший, что вам мешает написать этот ассемблер напрямую без капризного посредника в виде С++ компилятора? Нафига вам темплейты сдались? У меня есть только одно объяснение: рассказы про темплейты ценятся гораздо больше чем рассказы про ассемблер. Ассемблер почему то воспринимается как что-то из прошлого века, но только без него ничего не работает в конечном итоге.
вон вы про что! Ну тогда вам точно куски на ассемблере надо писать, а вы взялись темплейты с решениями на виртуальных функциях сравнивать. Не зря вы в начали написали что перешли на что-то другое от темплейтов. Виртуальные функции на этом уровне точно нет смысла применять что там сравнивать то.
10 - 20 даже 100 ассемблерных инструкций всегда проще понять и даже переписать если надо, чем выгребать все сайд эффекты с темплейтами помноженными на оптимизацию в компиляторе которая зависит от десятка настроек, и еще и меняется с версией компилятора. Дело даже не в скорости, темплейты на таком уровне это просто не надежное решение даже.
сообщения от биржи у вас через сокет приходят? три строчки вы не заметите на фоне кода который из сокета читает, мне кажется вы не совсем коректно описываете проблему или причину проблемы которая у вас видимо действительно присутствует, мне кажется.