Обсуждение

задача не более чем "сделать стартап" (то есть поработать Яндексом: "нужных инженеров найдём всех, поэтому ничего инженерного нам сейчас обсуждать не нужно") типа термин "стартап" уже так "опопсел", что что-то приличное им называть уже неприлично?

Может, термин не опопсел, но в понимании "курсов по созданию стартапов" и разных "кэмпов" там уж совсем как-то попсово стало. Сразу вспоминается "а вы не хотели бы создать не стартап, а бизнес?".

Кстати, еще вот такой интересный вопрос - а зачем студентам-физикам хорошие модели данных? Мне просто думаеццо, что хорошесть моделей данных - это такая концепция, которую глубоко освоить могут лишь "айтишнеги". В том смысле, что критерий хорошести он зависит от целей, а если цель "цифровое производство", т.е. модель должна быть "хорошей" с точки зрения человеко-компьютерной системы, то мне кажеццо, что студенту-физику будет трудновато хорошо разобраться и в физике, и достаточно хорошо - в практике примения компьютерных онтологий. Я тут не про то, что он не поймет, что такое онтология. А про то, что воткнуть в хорошесть моделей данных - мне думаеццо нетривиальная задача. Это ж надо иметь специфический опыт долго думать, медитировать и "вкуривать". Скажем у меня специфичны опыт есть, но я еще не очень много "вкуривал" :)

По поводу generative design я бы отметил такую вещь. Ну в смысле, мне думаеццо, что для поминания этой концепции имеет смысл рассмотреть немного более общую ситуацию. Типа: 1 на входе, у нас есть более-менее формальные требования, при этом они не конструктивны, а декларативны, в том смысле, что задают, что должно быть 2 на выходе нам нужно получить нечто конструктивное, т.е. как цель/требования достигаются, с учетом всеразличных ограничений (как явных, так и обнаруженных в процессе) 3 в некотором роде, задача дизайна: преодолеть неопределенность: ибо в теории, решение задачи существует, но конкретно пока непонятно как (есессно в реалиях оно может не существовать, и может потребоваццо изменения требований, но не суть важно). 4 ну и если у нас есть формальная постановка - определено пространство, в котором искать решения, заданы ограничения и цели, то можно запускать солвер/оптимизатор, который будет тем или иным образом рыскать в этом пространстве, ну и если найдет, то из решения мы извлекаем дизайн. Что типа и есть generative design Вкратце я просто не узрел в презентации каких-то явных упоминаний что такое design и причем тут солверы/оптимизаторы. Ну может оно конечно и нахрен нужно, но я в свое время долго ломал голову на тему на хрена нужен этот дизайн, так что я думаю, что при переходе к практике это очень важный момент :).

Виктор как раз на тему "зачем хорошие модели данных" и "какие свойства отличают хорошую модель данных от плохо" и говорил больше часа. Не пересказывать же тут текс его доклада? :-)

Так это только слайд. Устно я довольно долго и много на эту тему говорил: что называют солвером в САПРах, куда там втыкать оптимизатор, зачем нужна формализация. Там ещё и справочные данные, замечу, участвуют в немаленьких количествах. Конечно, надо бы всё это писать подробно, как книгу, но времени как-то не хватает, мотивации, сосредоточения и т.д.. Я помню, что немного в блоге у себя писал об этом, но именно что немного. Может, видео доклада выложат (камера там какая-то посреди зала стояла, красной лампочкой мигала). С другой стороны. у нас были на заседаниях Русского отделения INCOSE доклады и про generative design, и про оптимизацию (и даже про оптимизацию архитектуры тоже был доклад). Так что материалов в наших видео хватает и без моего этого доклада. Кроме определения "design" я ещё и про определение "generative" рассказывал, что это всё от Хомского пошло, от его порождающих грамматик. Но это мелочи.

Я просто уверен, что мы generative design понимаем несколько по разному. но не знаю в чем конкретно различия. Свой взгляд я описал тут http://avlasov.livejournal.com/136979.html понятно дело он в основном навеян софтовыми проблемами. Вобщем-то генерация тестов и автоматическое доказательство теорем можно рассатривать как генерейтив дизайн. С тестами очевидно, а в случае теорем нам фактически тоже нужно сгенерить доказательство. Ну и разные theorem provers просто используют разные подходы к конструированию этого доказательства, хотя иногда это может быть и в неявной форме.

Проблема в том, что сейчас все студенты, что физики, что лирики, пишут код и делают модели данных по факту. Код их писать хоть как-то учат всех, СУБД проектировать - больше трети руки подняли. Так что надо им хотя бы рассказывать - что модели делятся на хорошие и плохие.

Конечно, понимаем по-разному. В оригинале это вообще было порождение геометрической формы (shape) компьютером, без ручного редактирования в графическом редакторе. Понятно, что это нужно обобщать, ибо в инженерный проект (design) ещё много всякого входит, отнюдь не только геометрические формы.

-1- "Может, видео доклада выложат "(с) да,- неплохо бы -- ознакомился бы с приятствием. -2- " у нас были на заседаниях Русского отделения INCOSE доклады и про generative design, и про оптимизацию (и даже про оптимизацию архитектуры тоже был доклад). Так что материалов в наших видео хватает и без моего этого доклада." ну, к примеру, на ЖЖшном incose-ru -то я зафрендился... но вот подобного к п.1 не обнаружил, увы.

Про многокритериальную оптимизацию для инженерных солверов -- http://incose-ru.livejournal.com/37609.html Порождающее проектирование -- http://incose-ru.livejournal.com/36942.html Порождающая архитектура -- http://incose-ru.livejournal.com/31890.html