Я имел в виду, что определить количество правильных многогранников можно следующим образом:
для наглядности считаю в градусах, а не в радианах:
Начнем с треугольных граней (угол между ребрами 60 градусов):
В вершине сходятся три равносторонних треугольника (3*60=180 < 360) — многогранник возможен (тетраэдр)
Возьмем 4 треугольника (4*60=240 < 360) — многогранник возможен (это октаэдр).
Возьмем 5 треугольников (5*60=300 <360) — многогранник возможен (это икосаэдр).
Возьмем 6 треугольников (5*60=300 = 360) — многогранник выраждается в плоскость (не возможен).
Квадратные грани (угол между ребрами 90 градусов)
Возьмем 3 квадрата — это куб (3*90 = 270 < 360).
4 квадрата (4*90 = 360) — многогранник вырождается в плоскость.
Пятиугольник — угол между ребрами 108 градусов
Возможен также только один случай (108 * 3 = 324 < 360) (додекаэдр).
Нетрудно видеть (как любят говорить математики в особо трудных местах доказательств:), что других вариантов нет.
Конечно, данные выкладки математически экивалентны приведенным в статье.
За статью спасибо — она предлагает более общий взгляд на вроде бы простые вещи.
Дурацкий вопрос дилетанта: А нельзя, просто сложить все углы при вершине? Если меньше 360 градусов то многогранник физически возможен, если нет, то невозможен?
Как заставить человека работать 24 часа в сутки, заставить забыть про друзей, любовь, красоту науки и жажду творчества? Очень просто — надо давать им время от времени почитать подобные посты, замешанные на алчности, мерящие личный успех суммой на банковском счете. Все это — очередная американская бихевиористическая чушь, очевидно кем-то вдолбленная автору на очередном бизнес-тренинге.
Думаю, что по RS-485 и подобным протоколам XML передавать слишком накладно. Но должны быть железки, потключаемые прямо по TCP/IP. У них тогда и настроечною морду можно сделать на HTTP. Что-то вроде того, как роутеры сейчас работают. Ну и полный стек Web-сервисов с XML можно организовать.
В более-менее крупной организации, имеющей промышленные здания, необходимо контролировать потребляемые энергоресурсы. На практике это выливается в десятки счетчиков (электроэнергия, газ, отопление, холодная и горячая вода, стоки). Система, о которой идет речь в этой статье, помогает главному энергетику оперативно учитывать расход энергоресурсов, не бегая при этом по подвалам.
С НОРЭМ я не сталкивался, но думаю, что модуль, подобный тому, которыя я разработал пригодился бы и в глабальных системах контроля энергоресурсов.
У Филлипа Дика есть роман (по моему, роман Убик). Начинается он с того, что вся техника (включая даже входную дверь) работала As Service. Нужно сварить кофе — плати кофеварке, нужно погладить брюки — плати утюгу. Дверь за каждое открытие и закрытие списывала со счета деньги… Жуть. Гениальный Филлип Дик еще много лет назад увидел, куда катится мир.
В целом — согласен. IDE-отладчиками тоже иногда пользуюсь, но у них есть некоторые недостатки:
— Нужен IDE.
— Не все можно посмотреть, а особенно вычислить (особенно в компилируемых средах).
— Когда происходит останов по брекпоинту, трудно сразу понять в какой именно вызов процедуры это произошло (нужно поднимать стек и прочий контекст), а если функция вызывается постоянно из многих частей программы — то выловить нужный вызов — большое искусство.
— При отладке циклов — не так то легко добраться до ошибочной итерации — приходится на брекпоинты вешать условия, и заниматься прочими танцами с бубнами.
— Бывают случаи, когда важно все выполнить в реальном времени
С другой стороны, точно и грамотно поставленные вызовы трассировки на разных уровнях формируют протокол, по которому сразу становится ясной ПОЛНАЯ картина происходящего в системе. На трассировку можно ставить условия, вызывать ее в циклах, добираться до всего до чего можно дотянуться — в общем развлекаться как хочешь. Кроме того, вся работа в отладчике после отладки исчезает, не оставляя следов. Вызовы же трассировки можно либо оставлять (заглушая саму функцию трассировки), либо комментировать. В любом случае — остаются некие результаты.
Действительно, каюсь, что всех собак спустил на прикладных программистов. Должно достаться также и системным программистам (которые проектируют операционки с нерегламентируемым временем реакции на системные вызовы) и сетевикам (проектирующим гигабайтные сети с внезапными задержками) и сайтостроителям с непредсказуемо-тормозными страницами и сервисами (в основном из-за неоптимизированных запросов к БД). Как говорится, вот дом, который построил Джек Мы.
И все-таки, думаю, вы согласитесь, что о прогресс-баре редко кто задумывается по серьезному. В инсталляторах вообще ничего специально не делают — пользуются стандартным функционалом. При сетевом обмене — не меряют скорость соединения, при вычислениях — производительность системы, при обработке файлов — считают количество файлов, но не учитывают размер, скорость чтения-записи не учитывают. Самое простое — разделить на какие-то этапы, и плюсовать в цикле, не задумываясь о реальном времени. Прогресс бар на положении Золушки. Вроде есть, чего-то делает и на том спасибо.
Давно уже не наблюдал адекватно построенного прогресс-бара. (Который движется равномерно и реально отображает ситуацию с процессом). Часто еще бывает, что прогресс-бар пробегает до конца, потом начинается снова и снова… и снова, со все новыми леденящими душу комментариями (расаковка, запаковка, регистрация компонентов, удаление чего-то-там и тд.). Бывает зависает намертво на последних процентах. Бывает долго не может начать движение.
Все это — полная профанация идеи прогресс-бара, как средства взаимодействия компьютера с человеком. Думаю — основная причина — лень разработчиков реально оценить временные затраты на полный процесс, а также хоть немного времени потратить продумывание поведения этого очень важного в плане юзабилити элемента интерфейса. Конечно, бывают случаи, когда время действительно сложно оценить, но думаю, что даже в этом случае грамотный подход может значительно улучшить поведение прогресс бара.
Иногда бывает, что IDE-отладчик не справляется с кодом, генерируемым в режиме оптимизации. Оптимизатор же в Delphi может делать очень интересные вещи — может например, перевернуть цикл вверх ногами (i заменить на n-i). Не удивлюсь, если он и с булевскими значениями может что-нибудь сделать. Рекомендую при отладке снимать галочку оптимизация в компиляторе. (Хотя может в данном посте — не этот случай, но то, что глюк исчез при пересборке проекта очень напоминает ситуацию с оптимизацией)
Конечно!!! Очень ценное замечание. Ради этого все и задумывалось. В Demo4. (Построение тетраэдра) в самом начале переменной присваивается размер стороны. Все остальные координаты вычисляются из нее. Параметрическое моделирование здесь получается естественно, если придерживаться определенных правил при построении. Кроме того, можно использовать процедуры (как в Demo3). При этом написав один раз построение объекта, как процедуру можно вызывать эту процедуру сколько угодно раз с разными параметрами.
Согласен. Система предполагает навыки в программировании. Но при этом открывается масса возможностей. Можно строить интересные математические объекты, которые мышкой не построить при всем желании. Данная система больше задумывалась как-раз для такой науко-содежащей графики. И конечно, ручной редактор для меня реализовать было сложно. Соревноваться с 3DMax я бы не рискнул.
для наглядности считаю в градусах, а не в радианах:
Начнем с треугольных граней (угол между ребрами 60 градусов):
В вершине сходятся три равносторонних треугольника (3*60=180 < 360) — многогранник возможен (тетраэдр)
Возьмем 4 треугольника (4*60=240 < 360) — многогранник возможен (это октаэдр).
Возьмем 5 треугольников (5*60=300 <360) — многогранник возможен (это икосаэдр).
Возьмем 6 треугольников (5*60=300 = 360) — многогранник выраждается в плоскость (не возможен).
Квадратные грани (угол между ребрами 90 градусов)
Возьмем 3 квадрата — это куб (3*90 = 270 < 360).
4 квадрата (4*90 = 360) — многогранник вырождается в плоскость.
Пятиугольник — угол между ребрами 108 градусов
Возможен также только один случай (108 * 3 = 324 < 360) (додекаэдр).
Нетрудно видеть (как любят говорить математики в особо трудных местах доказательств:), что других вариантов нет.
Конечно, данные выкладки математически экивалентны приведенным в статье.
За статью спасибо — она предлагает более общий взгляд на вроде бы простые вещи.
С НОРЭМ я не сталкивался, но думаю, что модуль, подобный тому, которыя я разработал пригодился бы и в глабальных системах контроля энергоресурсов.
— Нужен IDE.
— Не все можно посмотреть, а особенно вычислить (особенно в компилируемых средах).
— Когда происходит останов по брекпоинту, трудно сразу понять в какой именно вызов процедуры это произошло (нужно поднимать стек и прочий контекст), а если функция вызывается постоянно из многих частей программы — то выловить нужный вызов — большое искусство.
— При отладке циклов — не так то легко добраться до ошибочной итерации — приходится на брекпоинты вешать условия, и заниматься прочими танцами с бубнами.
— Бывают случаи, когда важно все выполнить в реальном времени
С другой стороны, точно и грамотно поставленные вызовы трассировки на разных уровнях формируют протокол, по которому сразу становится ясной ПОЛНАЯ картина происходящего в системе. На трассировку можно ставить условия, вызывать ее в циклах, добираться до всего до чего можно дотянуться — в общем развлекаться как хочешь. Кроме того, вся работа в отладчике после отладки исчезает, не оставляя следов. Вызовы же трассировки можно либо оставлять (заглушая саму функцию трассировки), либо комментировать. В любом случае — остаются некие результаты.
Регулярно так делаю (правда не print, а trace), и не знаю, чем заменить.
ДжекМы.И все-таки, думаю, вы согласитесь, что о прогресс-баре редко кто задумывается по серьезному. В инсталляторах вообще ничего специально не делают — пользуются стандартным функционалом. При сетевом обмене — не меряют скорость соединения, при вычислениях — производительность системы, при обработке файлов — считают количество файлов, но не учитывают размер, скорость чтения-записи не учитывают. Самое простое — разделить на какие-то этапы, и плюсовать в цикле, не задумываясь о реальном времени. Прогресс бар на положении Золушки. Вроде есть, чего-то делает и на том спасибо.
Все это — полная профанация идеи прогресс-бара, как средства взаимодействия компьютера с человеком. Думаю — основная причина — лень разработчиков реально оценить временные затраты на полный процесс, а также хоть немного времени потратить продумывание поведения этого очень важного в плане юзабилити элемента интерфейса. Конечно, бывают случаи, когда время действительно сложно оценить, но думаю, что даже в этом случае грамотный подход может значительно улучшить поведение прогресс бара.