как математик по образованию, я вам верю (хоть доказательства и не видел пока), что теоремы существования должно для доказательства хватить. Но согласитесь, это не тот способ, которым можно уверенно убеждать юристов и привлечь много сторонников-программистов (в некотором роде исходящих из принципа «считает — значит существует»). В общем, было бы здорово иметь технологию явного вычисления либо новых дизъюнктивных чисел (с условием из камента выше), либо бОлее вычислительно эффективного восстановления позиции последовательности в одном из известных дизъюнктивных. Зачем? Затем, что при желании тогда можно развернуть массовую кампанию по сведению официальных музыкальных/видео-треков к известным числам, с известными последствиями.
А что вычислительно проще? Когда я читал про pifs, у меня сложилось впечатление, что «показать, что данная запись находится в данном числе» вычислительно трудоемко. А построить новое число для заданной последовательности вроде бы попроще будет. Но возникает проблема с однозначной красивой идентификацией этого нового числа (например по дополнительным свойствам, неочевидным образом связанным с исходной последовательностью).
Ага. Если я правильно понял, по заданной последовательности чисел (в заданной системе счисления) можно построить дизъюнктивное число. А есть ли какой-то «хороший» способ это число обозначить так, чтобы этот способ не сводился к формуле
\sum_{0}^{\infty}\frac{n}{10^{n^2}}
и исходной заданной последовательности? Ну, вот число \pi все знают, его «обозначили». Может, какие-то хорошие свойства таких дизъюнктивных чисел можно автоматически выводить?
Зачем: если ответ на вопрос из предыдущего абзаца «да», то открывается прекрасная возможность троллинга патентовладельцев. Берем официальную аудио-запись в цифровой форме, определяем ее дизъюнктивное число, предъявляем претензию на отмену патента на основании «нет новизны».
Соглашусь. Например в решении от Maxeler (например вот) есть специальные шины (MaxRing) для соединения нескольких плат. Утверждают, что производительность такой шины прилично выше производительности PCIe.
Штука простая: точность численного приближения в методах, использующих граничные условия, зависят от качества приближения непрерывной границы дискретной сеткой. Ошибка приближения границы потом распространяется вглубь объема, как бы хороша ни была сетка внутри объема. Криволинейные приближения границы — относительно простой и дешевый способ резко повысить точность расчета без измельчения сетки.
Теперь, если программа моделирования не позволяет такую кривую границу задать/показать, то информация уже потерялась; и когда вы модель границы скормите разбивателю сетки, будет уже поздно. Поэтому хочется, чтоб новый программный продукт был потенциально готов справляться с такой задачей, особенно если гордо рекламируется как аж Российский и с претензией на универсальность (не «3D-ядро САПР пакета», а «3D-ядро»).
1) мы с вами похоже на разных языках разговариваем. Сетка по определению должна покрывать всю область. Возможно, на границе быть более мелкой, чем внутри, но это уже от задачи зависит. В такой ситуации описание сетки иерархией элементов разных размерностей — хорошо поставленная задача. И есть ряд продуктов для сеточного моделирования, которые область представляют именно так, как я описал.
2) со списком а)-ё) согласен (это я говорю чтоб не было недоразумений), только хотел бы дополнить: не обязательно ограничиваться сеточными методами, можно и какие-нибудь задачи на механику решать. На вопрос «с какой стати» ответ: вы мне, конечно, ничего не должны. Что характерно я от вас ничего и не требую. Исходно я задавался вопросом: «такую-то задачу решает?» На что мне был сформулирован ответ «а с какой стати должен?» Ну, не решает и ладно — ваше же дело, но можно же ж и вежливее.
Теперь, почему продукту из пункта д) было бы неплохо решить задачу из пункта ё). А потому, что это задачи связанные и разделение их на разные продукты априори выглядит как создание дополнительной бюрократической работы, наподобие переноса распечатанного документа в соседнюю комнату, чтоб там его вручную опять стали набивать. При этом: я осознаю масштаб задач и сложность/неавтоматизируемость подгонки сеток под вычислительную задачу и точность входных/выходных данных. Но все же было бы здорово не разносить эти связанные задачи в качественно разные программные среды. Ну, или по крайней мере не писать несколько различных графических движков для каждого из звеньев конструкторской разработки, под предлогом того, что каждый этап требует ПО разных классов. Чтоб не приходилось сетку, составленную одной программой конвертировать в принципиально другой формат, чтоб другая программа там что-то посчитала. Чтобы workflow разработки (в смысле — конструкторской работы) сложного продукта можно было контролировать в одной программной среде — для улучшения т.н. data provenance.
Например, я себе это вижу так: занимаемся CAD-моделированием, хотим проверить скажем, прочность стыковки вон тех трех деталей. Выгружаем эти три конкретных детали (информацию об их границах и данные о материалах) в отдельный подпроект, там занимаемся построением сеточной/whatever модели, расчетом, результат тут же визуализируем и как-то сохраняем мета-информацию «годится/не годится, прочность составляет 5 попугаев, etc» о связке этих трех деталей — в общем проекте.
На разных этапах участвовать могут разные люди, но иметь общую документацию в одном месте, с прямой привязкой к общей картинке — a priori кажется здравой идеей. Но я, конечно, не специалист по CAD-моделированию, возможно это утопия. Графический движок при этом — один. С какими угодно там подключаемыми модулями, если так удобно. Но он один. И вычислительные пакеты тоже подключаемые извне.
Неструктурированную 3d сетку можно задавать как коллекцию многогранников, а вместо указания их смежности описать как они получены из общих вершин, ребер и двумерных граней — прекрасно сетка таким образом задается. Погуглите «mesh graph', станет яснее. Зачем такое может быть надо — например для т.н. discontinuous Galerkin схем, там граница между элементами нужна в явном виде. Что такое теория тонких оболочек — не имею ни малейшего понятия.
Что визуализацией не занимаются, сказали не скажу, не явно и не объясняя почему. Собственно я не спорю, я пытаюсь задавать вопросы, но пока ответы выглядят как заклинания для посвященных, вы вот тоже какую-то теорию тонких оболочек упоминаете. И еще, по поводу моей мотивации к беседе — см. мой камент ниже о несовпадение подачи новости задаче, которую фактически собираются решать.
Видимо, я тоже недостаточно ясно выражаюсь. Мат. методы (галеркин, уравнение навье-стокса) тут вот к чему: когда вы спроектировали деталь, казалось бы естественно тут же запустить процесс проверки конструкции и материалов на прочность и тому подобное. Поэтому я и упоминаю мат. методы. Далее, положим вы запустили моделирование процесса деформации для определенного куска конструкции. Надо же увидеть результат? Значит, нужно решить задачу визуализации результата счета в объеме — том же самом объеме, который вы незадолго до того проектировали. Геометрия одна и та же, разве что детализация (на уровне сетки) может отличаться.
Сетка не имеет отношения к базису в методе галеркина. Не знаю, к чему вы рассуждаете о связи этих двух.
Причина удивления в следующем: заявляется «мы пишем универсальное 3D-ядро», но аргументируете что какая-то функциональность невозможна под предлогом «мы используем это ядро в такой-то программе». Значит, «3D-ядро» не универсально? В общем, хотелось бы исходно четких объяснений, что пишут и какую задачу решают.
Например, для конечно-элементного анализа. Но может и для других методов, способных работать с неструктурированными сетками с кривыми границами. Нет, меня интересует не построение сетки, хотя и это интересно. В первую очередь меня интересует возможность визуализации готовых сеток, идеально — вместе с посчитанными данными.
Повторюсь, вы (и особенно Снытников, если вы и он — не одно лицо) используете какую-то «герметичную» терминологию из узкой среды. «Геометрическое ядро трёхмерного моделирования», в общем случае, не отсылает только к CAD, как бы специалистам по CAD этого ни хотелось. Термин «моделирование» можно понять не только как «построение промышленной модели», но и как «моделирование физических процессов». Причем мне искренне не ясно, что принципиально ограничивает в решении этих двух задач сразу, по крайней мере в построении и визуализации трехметрых моделей. При этом я не предлагаю вам писать код для расчета этих моделей (метод Галеркина, Навье-Стокс etc), это пусть подключаемые модули делают. Но задача визуализации-то одна!
Ага, на мой вопрос о криволинейных границах ответили, но легче от этого ответа не стало.
Поддержка трехмерных сеток (meshes) в новом движке подразумевает геометрические элементы с кривыми границами (полиномы высоких порядков)?
Представление трехмерной модели в ядре основано на B-Rep (граничном представлении), где геометрическими элементами являются канонические объекты или NURBS. Полиномы высоких порядков — это один из частных случаев NURBS.
Однако когда речь идет о трехмерных сетках с криволинейными границами, то, скорее всего, имеются в виду задачи CAE. В этом случае построение выполняется по B-Rep модели специальными модулями и выходит за рамки функциональности геометрического ядра. Если в будущем будет потребность включить такие модули непосредственно в ядро, это можно будет сделать.
Авторы пользуются терминологией, принятой в какой-то очень уж узкой среде. Вы бы говорили проще, вычислительная геометрия — она для всех. Кто такие геометрические элементы граничного представления? Подразумеваются двумерные грани? Или одномерные? Или вообще, границы двумерных граней? Кто такие канонические объекты? Выпуклые многогранники? И в любом случае, смешивается геометрическое место точек и аналитический способ его задать рациональной функцией (я правильно понял идею NURBS?).
Если пользоваться англоязычной терминологией, то гораздо понятнее и общеупотребительнее термин mesh graph: «у куба 6 квадратных граней, каждая из которых состоит из 4 отрезков, а у отрезка — по две граничных точки», то есть построение графа «геометрический объект размерности n состоит из этих геометрических объектов размерности n-1».
Я подразумевал задачи не CAD-моделирования, а т.н. high order (h/p) finite element methods. То есть моделирование физических процессов сетками, внутри каждого элемента которой приближение ищут в виде полинома высокого порядка, как правило это полиномы Лежандра, Лагранжа, Якоби. Причем важно уметь поддерживать полиномы нужного вида. Связь моделирования и расчетных методов же очевидна, какой смысл решать только одну из этих задач.
Ответ
В этом случае построение выполняется по B-Rep модели специальными модулями и выходит за рамки функциональности геометрического ядра. Если в будущем будет потребность включить такие модули непосредственно в ядро, это можно будет сделать.
честно говоря ничего не объясняет: есть ли возможность визуализации трехмерной сетки со, скажем, призмой с искривленным основанием?
Один вопрос: поддержка трехмерных сеток (meshes) в новом движке подразумевает геометрические элементы с кривыми границами (полиномы высоких порядков)? Если нет, то — хм.
Хм. Тут я с вами согласен, посмотреть как человек размышляет лучше всего. Но есть нюансы, ради которых я в беседу и ввязался. Начать с того, что желания собеседователя не всегда можно угадать заранее, а от этого зависит оптимальная стратегия подачи. Nothing personal, just business. Если исходить из посыла топикстартера, то проверять следует не «как думал», а наоборот «секундомер закончил отсчитывать, решения нет? Следующий!» Перед таким собеседователем разлиться соловьем о том, как ты выбираешь метод решения исходя из первых проверок условия — кажется это гарантированный способ завалить беседу.
В качестве наглядного примера советую сходить по вот такой ссылке codility.com/demo/take-sample-test/epsilon2011/ и попробовать пройти тест за жестко указанное время. Говоря попросту: у меня на днях не получилось. При том, что о вычислительной геометрии я в курсе, но она не в активном багаже. Вот такая же петрушка и произойдет на собеседовании, когда к вам придет программист с готовностью на скорость щелкать задачи олимпиадного программирования, а вы ему подсовываете задачу, требующую размеренного размышления в совершенно другой стилистике. Или наоборот. Просто надо понимать, что бывают качественно различные стили мышления и странно проверять умение играть на музыкальных инструментах при приеме на работу на стройку.
Но еще раз, если у вас идет разработка научного софта, все что я тут говорю не релеватно и вопросы с projecteuler хорошие.
Честно говоря я не понимаю, почему вы формулируете возражение, при том что излагаете то же самое, что я говорил. Я об этом:
Так же несреьезно как думать что к каждой задаче надо сходу решение находить.
Верно, именно это я имел ввиду под переключением контекста.
Мне кажется, вы смешиваете качественно различные горизонты времени. Если нужно решить задачу за полчаса, то проверяется сухой остаток, то что вы можете сделать даже будучи разбуженным в 3 ночи. Если нужно решить задачу за полдня, то есть время пойти пить чай/кофе и мнэ, вытащить когда-то актуальный инструментарий с нужной полки подсознания в актуальную память. После чего вы вполне сможете решить эту задачу за полчаса, но без процесса переключения у вас это не получится. По крайней мере, у меня так. Если вы держите все чего когда-либо касались с 3хлетнего возраста в актуальной памяти — я вам и завидую, и нет одновременно.
Почему-то вы не хотите признать простой вещи: на собеседовании вам времени на переключение контекста не дадут.
Вот этого
И в конце концов на собеседоваиях в основном хотят увидеть как вы решаете задачи, а не решение, ход ваших мыслей и рассуждений.
я вообще не понял. Как можно «увидеть как вы решаете задачи», если не наблюдать «решение, ход ваших мыслей и рассуждений»?
Ну вот возьмем такую задачку с первой же страницы: projecteuler.net/problem=46
Я бы не сказал, что это школьная математика. Вернее так: по Арнольду, такое и в 6 классе решать можно. Можно, если у тебя преподаватель — Арнольд, и школа типа ФМШ. Но мы же вроде как не социальным снобизмом заниматься хотим, а конкретные навыки проверить.
Возьмем меня, выпускника математического факультета одного сибирского вуза, с опытом работы постдоком последние 4 года. У меня голова забита задачами другой тематики и чтоб голову переключить на задачу нумер 46 по ссылке, нужно сосредоточенно потратить сколько-то времени. Я вот сейчас условие прочитал и понял что мгновенно даже идеи решения не приходит. Значит, нужно отложить в сторону на «подумать». В обстановке собеседования же времени на переключение контекста — нет.
Так это же задачи по математике, а не программированию. Что неплохо, но про другое. Разве что вы выбираете сотрудника в проект, где математики как раз много.
Зачем: если ответ на вопрос из предыдущего абзаца «да», то открывается прекрасная возможность троллинга патентовладельцев. Берем официальную аудио-запись в цифровой форме, определяем ее дизъюнктивное число, предъявляем претензию на отмену патента на основании «нет новизны».
Теперь, если программа моделирования не позволяет такую кривую границу задать/показать, то информация уже потерялась; и когда вы модель границы скормите разбивателю сетки, будет уже поздно. Поэтому хочется, чтоб новый программный продукт был потенциально готов справляться с такой задачей, особенно если гордо рекламируется как аж Российский и с претензией на универсальность (не «3D-ядро САПР пакета», а «3D-ядро»).
2) со списком а)-ё) согласен (это я говорю чтоб не было недоразумений), только хотел бы дополнить: не обязательно ограничиваться сеточными методами, можно и какие-нибудь задачи на механику решать. На вопрос «с какой стати» ответ: вы мне, конечно, ничего не должны. Что характерно я от вас ничего и не требую. Исходно я задавался вопросом: «такую-то задачу решает?» На что мне был сформулирован ответ «а с какой стати должен?» Ну, не решает и ладно — ваше же дело, но можно же ж и вежливее.
Теперь, почему продукту из пункта д) было бы неплохо решить задачу из пункта ё). А потому, что это задачи связанные и разделение их на разные продукты априори выглядит как создание дополнительной бюрократической работы, наподобие переноса распечатанного документа в соседнюю комнату, чтоб там его вручную опять стали набивать. При этом: я осознаю масштаб задач и сложность/неавтоматизируемость подгонки сеток под вычислительную задачу и точность входных/выходных данных. Но все же было бы здорово не разносить эти связанные задачи в качественно разные программные среды. Ну, или по крайней мере не писать несколько различных графических движков для каждого из звеньев конструкторской разработки, под предлогом того, что каждый этап требует ПО разных классов. Чтоб не приходилось сетку, составленную одной программой конвертировать в принципиально другой формат, чтоб другая программа там что-то посчитала. Чтобы workflow разработки (в смысле — конструкторской работы) сложного продукта можно было контролировать в одной программной среде — для улучшения т.н. data provenance.
Например, я себе это вижу так: занимаемся CAD-моделированием, хотим проверить скажем, прочность стыковки вон тех трех деталей. Выгружаем эти три конкретных детали (информацию об их границах и данные о материалах) в отдельный подпроект, там занимаемся построением сеточной/whatever модели, расчетом, результат тут же визуализируем и как-то сохраняем мета-информацию «годится/не годится, прочность составляет 5 попугаев, etc» о связке этих трех деталей — в общем проекте.
На разных этапах участвовать могут разные люди, но иметь общую документацию в одном месте, с прямой привязкой к общей картинке — a priori кажется здравой идеей. Но я, конечно, не специалист по CAD-моделированию, возможно это утопия. Графический движок при этом — один. С какими угодно там подключаемыми модулями, если так удобно. Но он один. И вычислительные пакеты тоже подключаемые извне.
Что визуализацией не занимаются, сказали не скажу, не явно и не объясняя почему. Собственно я не спорю, я пытаюсь задавать вопросы, но пока ответы выглядят как заклинания для посвященных, вы вот тоже какую-то теорию тонких оболочек упоминаете. И еще, по поводу моей мотивации к беседе — см. мой камент ниже о несовпадение подачи новости задаче, которую фактически собираются решать.
Видимо, я тоже недостаточно ясно выражаюсь. Мат. методы (галеркин, уравнение навье-стокса) тут вот к чему: когда вы спроектировали деталь, казалось бы естественно тут же запустить процесс проверки конструкции и материалов на прочность и тому подобное. Поэтому я и упоминаю мат. методы. Далее, положим вы запустили моделирование процесса деформации для определенного куска конструкции. Надо же увидеть результат? Значит, нужно решить задачу визуализации результата счета в объеме — том же самом объеме, который вы незадолго до того проектировали. Геометрия одна и та же, разве что детализация (на уровне сетки) может отличаться.
Сетка не имеет отношения к базису в методе галеркина. Не знаю, к чему вы рассуждаете о связи этих двух.
Повторюсь, вы (и особенно Снытников, если вы и он — не одно лицо) используете какую-то «герметичную» терминологию из узкой среды. «Геометрическое ядро трёхмерного моделирования», в общем случае, не отсылает только к CAD, как бы специалистам по CAD этого ни хотелось. Термин «моделирование» можно понять не только как «построение промышленной модели», но и как «моделирование физических процессов». Причем мне искренне не ясно, что принципиально ограничивает в решении этих двух задач сразу, по крайней мере в построении и визуализации трехметрых моделей. При этом я не предлагаю вам писать код для расчета этих моделей (метод Галеркина, Навье-Стокс etc), это пусть подключаемые модули делают. Но задача визуализации-то одна!
Авторы пользуются терминологией, принятой в какой-то очень уж узкой среде. Вы бы говорили проще, вычислительная геометрия — она для всех. Кто такие геометрические элементы граничного представления? Подразумеваются двумерные грани? Или одномерные? Или вообще, границы двумерных граней? Кто такие канонические объекты? Выпуклые многогранники? И в любом случае, смешивается геометрическое место точек и аналитический способ его задать рациональной функцией (я правильно понял идею NURBS?).
Если пользоваться англоязычной терминологией, то гораздо понятнее и общеупотребительнее термин mesh graph: «у куба 6 квадратных граней, каждая из которых состоит из 4 отрезков, а у отрезка — по две граничных точки», то есть построение графа «геометрический объект размерности n состоит из этих геометрических объектов размерности n-1».
Я подразумевал задачи не CAD-моделирования, а т.н. high order (h/p) finite element methods. То есть моделирование физических процессов сетками, внутри каждого элемента которой приближение ищут в виде полинома высокого порядка, как правило это полиномы Лежандра, Лагранжа, Якоби. Причем важно уметь поддерживать полиномы нужного вида. Связь моделирования и расчетных методов же очевидна, какой смысл решать только одну из этих задач.
Ответ честно говоря ничего не объясняет: есть ли возможность визуализации трехмерной сетки со, скажем, призмой с искривленным основанием?
В качестве наглядного примера советую сходить по вот такой ссылке codility.com/demo/take-sample-test/epsilon2011/ и попробовать пройти тест за жестко указанное время. Говоря попросту: у меня на днях не получилось. При том, что о вычислительной геометрии я в курсе, но она не в активном багаже. Вот такая же петрушка и произойдет на собеседовании, когда к вам придет программист с готовностью на скорость щелкать задачи олимпиадного программирования, а вы ему подсовываете задачу, требующую размеренного размышления в совершенно другой стилистике. Или наоборот. Просто надо понимать, что бывают качественно различные стили мышления и странно проверять умение играть на музыкальных инструментах при приеме на работу на стройку.
Но еще раз, если у вас идет разработка научного софта, все что я тут говорю не релеватно и вопросы с projecteuler хорошие.
Верно, именно это я имел ввиду под переключением контекста.
Мне кажется, вы смешиваете качественно различные горизонты времени. Если нужно решить задачу за полчаса, то проверяется сухой остаток, то что вы можете сделать даже будучи разбуженным в 3 ночи. Если нужно решить задачу за полдня, то есть время пойти пить чай/кофе и мнэ, вытащить когда-то актуальный инструментарий с нужной полки подсознания в актуальную память. После чего вы вполне сможете решить эту задачу за полчаса, но без процесса переключения у вас это не получится. По крайней мере, у меня так. Если вы держите все чего когда-либо касались с 3хлетнего возраста в актуальной памяти — я вам и завидую, и нет одновременно.
Почему-то вы не хотите признать простой вещи: на собеседовании вам времени на переключение контекста не дадут.
Вот этого
я вообще не понял. Как можно «увидеть как вы решаете задачи», если не наблюдать «решение, ход ваших мыслей и рассуждений»?
Я бы не сказал, что это школьная математика. Вернее так: по Арнольду, такое и в 6 классе решать можно. Можно, если у тебя преподаватель — Арнольд, и школа типа ФМШ. Но мы же вроде как не социальным снобизмом заниматься хотим, а конкретные навыки проверить.
Возьмем меня, выпускника математического факультета одного сибирского вуза, с опытом работы постдоком последние 4 года. У меня голова забита задачами другой тематики и чтоб голову переключить на задачу нумер 46 по ссылке, нужно сосредоточенно потратить сколько-то времени. Я вот сейчас условие прочитал и понял что мгновенно даже идеи решения не приходит. Значит, нужно отложить в сторону на «подумать». В обстановке собеседования же времени на переключение контекста — нет.