В этой серии упомянута печатная машинка с действующей клавишей backspace (IBM Selectric Typewriter) - при нажатии на нее, буква пробивалась через клейкую ленту, что позволяло начисто убрать напечатанное с бумаги
FT232 (к примеру), да и сама STM32, работают в BULK. Ну и за неимением лучшего (аппаратного RS232 в большинстве современных девайсов), некий колхоз с участием USB-Audio выглядит приемлемым способом ввести в компьютер что-то низкочастотное и критичное по времени.
Так в USB есть изохронный режим - будет какое-то запаздывание, но фиксированное. А вот как потом точно по времени ловить момент перехода ноги RS232 между состояниями - не поделитесь?
1) В нем таки есть декларативная часть, все эти pubic, private, virtual, etc 2) Эта декларативная часть, внезапно, элегантно позволяет реализовывать декомпозицию и управление сложностью. 3) При наличии перегрузок, можно поиграть в алгебраическое мышление, рассматривая взаимодействие двух объектов как бинарную операцию.
Ух ты, ООП - это обкатанная практикой технология, которая совмещает декларатив с императивом и вроде позволяет освоившим ее вкусно кушать и мягко спать!
А помните, были такие "Компьютеры пятого поколения"? Это такая история про то, как Пролог и несколько миллиардов иен (aka полмиллиарда долларов) ухнули в трубу в 80е годы.
Одна из причин уха была банальной - чтобы надекларировать таким образом серьезную бизнес задачу (не демку, а нормальное такое ТЗ листов на 30-50), и при этом сохранить рассудок всех причастных, нужны какие-то средства управления сложностью и декомпозиции (вроде как ООП с этим кое-как справляется, со скрипом правда), а также люди с декларативно-функциональным мышлением, которых мало. (Потому что такому ремеслу учат на матфаке, а сажать на разработку магазина детских сосок Ph.D, который напишет диссертацию "Алгебраизация сосок. Оператор композиции бутылочки и молочка." - очень накладно. За эти деньги можно нанять десяток слесарей-императивщиков "бери ближе, швыряй дальше").
Автоматизировать создание правил на практике не представляется возможным, потому что теорема Геделя о неполноте формальных систем встает на пути like a boss (Ну или как Гендальф и его YOU SHALL NOT PASS!). Японцы погорели и на этом в том числе - их системы умнели-умнели, а потом внезапно тупели.
То есть, при всем нынешнем Agile и отжайле, где хотелку можно быстренько заткнуть костылем "вооон в том php-шнике", в декларативном конструкте вполне может оказаться, что систему нужно менять буквально всю, если просчитались с декомпозицией на ранних этапах.
Это ни в коем случае не говорит о том, что ваша идея плохая. Но вы ходите почрезвычайно тонкому льду. И когда (и если!) он провалится, под ним вас будут ждать те самые японцы, а также компьютер с аппаратной реализацией LISP на компонентах с датам 80х годов прошлого века.
Пример некорректен, так как Боб — открытая система, он не находится в вакууме. Пролетит через его мозг альфа-частица, подвинет что-то как-то, и все, прогноз сломался. Вы можете возразить, что можно взять компьютер побольше, на что я вам отвечу, что в качестве компьютера вам понадобится еще одна Вселенная.
Электрический потенциал — это относительная величина, его можно измерить только между двумя точками цепи. Вот соединили вы браслет с кожей, у вас получился один полюс. Где вы возьмете второй? Это ровно то же самое, что попытка хлопнуть в ладоши одной рукой — невозможное действие.
Нарисуйте для себя мысленно схему — к усилителю биопотенциалов идут два провода, один идет на кожу запястья через браслет часов. Куда идет второй?
Мои выводы основаны на полезной обзорной статье, собственном опыте написания минимакса (не для шахмат) и скромном опыте игры:
1. У вас не описана рокировка (потому что это движение одновременно короля и ладьи, из кода навскидку непонятно, как это должно работать)
2. Не хватает «взятия на проходе» для пешки.
3. Оценка веса позиции не учитывает мобильности фигур — с одной стороны, мало проку от зажатого со всех сторон ферзя (у которого большой вес), с другой стороны, проходная пешка может навести много суеты, когда протопает доску насквозь. Также неучет мобильности может, вероятно, привести к тому, что вашему движку можно будет поставить детский мат. Простейший способ учета мобильности — умножить вес фигуры на число возможных ходов.
4. Использование в крайней степени неэкономичного способа хранения данных лишит вашу программу преимущества в виде возможности хранить (да и перебирать — перекидывание нескольких бит в регистрах CPU на порядки быстрее ковыряния в мапе) больше состояний в памяти. С другой стороны, это может мотивировать на поиск более оптимальных эвристик для отсечения и более точных оценок для позиций. Может показаться интересной задача сделать код и читаемым и оптимальным по ресурсам одновременно.
Возможно я чего-то не учел, но куда могла деться мощность, если RPM=const и момент = const?
Правильно ли я понимаю, что вы говорите о том, что для регулирования частотником в широких пределах, придется брать общепромышленный двигатель с неоправданно большим типоразмером, или конструировать двигатель специально под частотник, с более толстой обмоткой?
Система управления поддерживает постоянный момент, повышая ток, пока не дойдет до отсечки. Можете посмотреть на эксперимент со шпинделем для CNC
В эксперименте автор пытается остановить шпиндель, который до этого свободно вращался и потреблял 0.23А. Ток подскакивает до отсечки в 14А, но шпиндель продолжает вращаться с той же частотой.
Так вот эта технология позволяет, в пределах первых десятков киловатт уж точно, выкинуть из оборудования практически всю механику с заменой на сеть приводов — «виртуальный редуктор». Современные любители/частники/энтузиасты металлообработки поступают просто — от советского станка остается только станина (как в этой производственной байке), шестерни / коробки передач выбрасываются и заменяются виртуальным редуктором, люфтящие/косые/стертые лимбы — на УЦИ с точностью в микроны. И получается машина совершенно другого класса.
Про векторное управление вы сознательно умолчали или не слышали? В лифтовой отрасли, например, сначала выкинули двухобмоточные двигатели, а потом и редукторы. Вместо червячной чугунины весом 200-300кг — легкий движок с энкодером + частотник.
Ок. Я выброшу консоль в помойку (ладно, отдам на переработку) и пойду в качалочку. И вот в качалочке я буду вырабатывать 70 кг* 1.5 Вт/кг = 105 Вт в режиме легкой тренировки, и 70 кг * 3 Вт/кг = 210 Вт на средней и до 450 Вт в пиках. Сколько-сколько я при этом надышу CO2? Может, качалочки будем закрывать?
Ой, я знаю, на что это похоже. Это же вылитые тезисы Хрущева с какого-то там партсъезда. Помнится, он еще художников обзывал, не стесняясь в выборе формулировок.
Это называлось "Об устранении излишеств в проектировании и строительстве".
Как бы это не было прискорбно для вас, а также для начальников, видящих в этом ущерб бизнесу — человек не является рациональным существом — плохо себя чувствует среди бетонных коробок, на станции метро-сороконожке, отделанной кафелем, а также среди типовых задач, для решения которых, по хорошему, талант программиста и не нужен.
Если игнорировать факт накопления технического долга, вы правы.
Однако, 5-6 «работающих» решений, приляпанных с разных сторон продукта превращают его в лоскутное одеяло из кода/стиля/решений разных эпох программирования, сделанных разными командами без рефакторинга.
А самое страшное, что с ростом техдолга растет и время, необходимое на новые фичи. По экспоненте растет — первую фичу добавляли два часа, пятую будем к плохой архитектуре прилаживать месяц, при этом будет этап (двухнедельный, по классике) «исследование возможностей для внедрения».
Это можно сравнить с мастерской, или с кухней, кому что ближе — «зачем делать уборку, если завтра опять готовить / точить детали». Спустя полгода, сидя на горе мусора «А, вот зачем».
У вас в тексте нигде не упоминается дифференциал (да и вовсе нет разбора математической записи интеграла и первообразной — действительно, зачем их рассматривать в статье про интеграл).
Однако, именно дифференциал играет роль того самого множителя, соучастника умножения, к которому вы подводите на протяжении всего текста статьи.
При интегрировании происходит не суммирование значений функции, а суммирование произведений функции на этот самый дифференциал, который представляет собой линеаризованный элемент множества, по которому происходит интегрирование.
На уровне вуза это легко понять, если рассмотреть криволинейные и поверхностные интегралы — для них уже явно видно, что под дифференциалом появляется миниатюрный кусочек того, по чему мы интегрируем.
На уровне школы этот же факт можно заметить при применении формулы замены переменных и интегрирования по частям, потому что под дифференциал переносят часть сложной функции, которую хотят проинтегрировать, фактически переходя к интегрированию на другом множестве.
Этим (бесконечным суммированием произведений) объясняется и школьное изложение интеграла как площади криволинейной трапеции — нарежем нашу трапецию на вертикальные полоски, теперь заменим криволинейный кусок кривой, являющийся «крышкой» нашей полоски на прямую, получился прямоугольник, площадь прямоугольника мы уже умеем считать — это f(x) * dx, где dx — тот самый миниатюрный кусочек отрезка интегрирования — дифференциал.
С точки зрения физики (школьной), например, ваше объяснения интеграла как суммы также не проходит — еще на первом уроке детям объясняют, что все преобразования величин нужно делать строго совместно с физическими размерностями этих величин.
Если объяснять интеграл как результат суммирования, то непонятно, как из [м/c] у нас в результате интегрирования скорости по времени получились просто [м]. Зато с дифференциалом все встает на свои места, у нас под интегралом [м/c] * d [с], физическая размерность имеет смысл множителя, выносим ее из-под дифференциала, сокращаем и получаем метры.
Если глубоко копать, выбросив из интеграла дифференциал, вы совершили ту же ошибку, что и Зенон в своих апориях, от чего у него нефизичные чудеса получались — бегун не мог черепашку догнать.
Такой системой может являться проект сторонней команды, которая на своей стороне делает все проверки. А записан этот факт в вордовском документе канцелярским языком, потом напечатан, подписан (паркером, не ЭЦП) гендиректором компании, отсканирован и засунут в PDF
Чтобы формальное доказательство и автовывод полноценно работали, придется научить аналитиков писать требования не канцелярским языком а языком формальных систем.
В противном случае, программа будет лоскутным одеялом для верификатора — вот сюда смотри, а тут рыбу заворачивалиunsafe.
В этой серии упомянута печатная машинка с действующей клавишей backspace (IBM Selectric Typewriter) - при нажатии на нее, буква пробивалась через клейкую ленту, что позволяло начисто убрать напечатанное с бумаги
Все же не кварц, а RC-генератор, хоть и калиброванный (даташит, стр. 23).
FT232 (к примеру), да и сама STM32, работают в BULK. Ну и за неимением лучшего (аппаратного RS232 в большинстве современных девайсов), некий колхоз с участием USB-Audio выглядит приемлемым способом ввести в компьютер что-то низкочастотное и критичное по времени.
Так в USB есть изохронный режим - будет какое-то запаздывание, но фиксированное. А вот как потом точно по времени ловить момент перехода ноги RS232 между состояниями - не поделитесь?
Ну и пять копеечек про ООП. Как ни странно:
1) В нем таки есть декларативная часть, все эти pubic, private, virtual, etc
2) Эта декларативная часть, внезапно, элегантно позволяет реализовывать декомпозицию и управление сложностью.
3) При наличии перегрузок, можно поиграть в алгебраическое мышление, рассматривая взаимодействие двух объектов как бинарную операцию.
Ух ты, ООП - это обкатанная практикой технология, которая совмещает декларатив с императивом и вроде позволяет освоившим ее вкусно кушать и мягко спать!
А помните, были такие "Компьютеры пятого поколения"? Это такая история про то, как Пролог и несколько миллиардов иен (aka полмиллиарда долларов) ухнули в трубу в 80е годы.
Одна из причин уха была банальной - чтобы надекларировать таким образом серьезную бизнес задачу (не демку, а нормальное такое ТЗ листов на 30-50), и при этом сохранить рассудок всех причастных, нужны какие-то средства управления сложностью и декомпозиции (вроде как ООП с этим кое-как справляется, со скрипом правда), а также люди с декларативно-функциональным мышлением, которых мало. (Потому что такому ремеслу учат на матфаке, а сажать на разработку магазина детских сосок Ph.D, который напишет диссертацию "Алгебраизация сосок. Оператор композиции бутылочки и молочка." - очень накладно. За эти деньги можно нанять десяток слесарей-императивщиков "бери ближе, швыряй дальше").
Автоматизировать создание правил на практике не представляется возможным, потому что теорема Геделя о неполноте формальных систем встает на пути like a boss (Ну или как Гендальф и его YOU SHALL NOT PASS!). Японцы погорели и на этом в том числе - их системы умнели-умнели, а потом внезапно тупели.
То есть, при всем нынешнем Agile и отжайле, где хотелку можно быстренько заткнуть костылем "вооон в том php-шнике", в декларативном конструкте вполне может оказаться, что систему нужно менять буквально всю, если просчитались с декомпозицией на ранних этапах.
Это ни в коем случае не говорит о том, что ваша идея плохая. Но вы ходите по чрезвычайно тонкому льду. И когда (и если!) он провалится, под ним вас будут ждать те самые японцы, а также компьютер с аппаратной реализацией LISP на компонентах с датам 80х годов прошлого века.
Нарисуйте для себя мысленно схему — к усилителю биопотенциалов идут два провода, один идет на кожу запястья через браслет часов. Куда идет второй?
1. У вас не описана рокировка (потому что это движение одновременно короля и ладьи, из кода навскидку непонятно, как это должно работать)
2. Не хватает «взятия на проходе» для пешки.
3. Оценка веса позиции не учитывает мобильности фигур — с одной стороны, мало проку от зажатого со всех сторон ферзя (у которого большой вес), с другой стороны, проходная пешка может навести много суеты, когда протопает доску насквозь. Также неучет мобильности может, вероятно, привести к тому, что вашему движку можно будет поставить детский мат. Простейший способ учета мобильности — умножить вес фигуры на число возможных ходов.
4. Использование в крайней степени неэкономичного способа хранения данных лишит вашу программу преимущества в виде возможности хранить (да и перебирать — перекидывание нескольких бит в регистрах CPU на порядки быстрее ковыряния в мапе) больше состояний в памяти. С другой стороны, это может мотивировать на поиск более оптимальных эвристик для отсечения и более точных оценок для позиций. Может показаться интересной задача сделать код и читаемым и оптимальным по ресурсам одновременно.
Правильно ли я понимаю, что вы говорите о том, что для регулирования частотником в широких пределах, придется брать общепромышленный двигатель с неоправданно большим типоразмером, или конструировать двигатель специально под частотник, с более толстой обмоткой?
В эксперименте автор пытается остановить шпиндель, который до этого свободно вращался и потреблял 0.23А. Ток подскакивает до отсечки в 14А, но шпиндель продолжает вращаться с той же частотой.
Это называлось "Об устранении излишеств в проектировании и строительстве".
Как бы это не было прискорбно для вас, а также для начальников, видящих в этом ущерб бизнесу — человек не является рациональным существом — плохо себя чувствует среди бетонных коробок, на станции метро-сороконожке, отделанной кафелем, а также среди типовых задач, для решения которых, по хорошему, талант программиста и не нужен.
Однако, 5-6 «работающих» решений, приляпанных с разных сторон продукта превращают его в лоскутное одеяло из кода/стиля/решений разных эпох программирования, сделанных разными командами без рефакторинга.
А самое страшное, что с ростом техдолга растет и время, необходимое на новые фичи. По экспоненте растет — первую фичу добавляли два часа, пятую будем к плохой архитектуре прилаживать месяц, при этом будет этап (двухнедельный, по классике) «исследование возможностей для внедрения».
Это можно сравнить с мастерской, или с кухней, кому что ближе — «зачем делать уборку, если завтра опять готовить / точить детали». Спустя полгода, сидя на горе мусора «А, вот зачем».
Однако, именно дифференциал играет роль того самого множителя, соучастника умножения, к которому вы подводите на протяжении всего текста статьи.
При интегрировании происходит не суммирование значений функции, а суммирование произведений функции на этот самый дифференциал, который представляет собой линеаризованный элемент множества, по которому происходит интегрирование.
На уровне вуза это легко понять, если рассмотреть криволинейные и поверхностные интегралы — для них уже явно видно, что под дифференциалом появляется миниатюрный кусочек того, по чему мы интегрируем.
На уровне школы этот же факт можно заметить при применении формулы замены переменных и интегрирования по частям, потому что под дифференциал переносят часть сложной функции, которую хотят проинтегрировать, фактически переходя к интегрированию на другом множестве.
Этим (бесконечным суммированием произведений) объясняется и школьное изложение интеграла как площади криволинейной трапеции — нарежем нашу трапецию на вертикальные полоски, теперь заменим криволинейный кусок кривой, являющийся «крышкой» нашей полоски на прямую, получился прямоугольник, площадь прямоугольника мы уже умеем считать — это f(x) * dx, где dx — тот самый миниатюрный кусочек отрезка интегрирования — дифференциал.
С точки зрения физики (школьной), например, ваше объяснения интеграла как суммы также не проходит — еще на первом уроке детям объясняют, что все преобразования величин нужно делать строго совместно с физическими размерностями этих величин.
Если объяснять интеграл как результат суммирования, то непонятно, как из [м/c] у нас в результате интегрирования скорости по времени получились просто [м]. Зато с дифференциалом все встает на свои места, у нас под интегралом [м/c] * d [с], физическая размерность имеет смысл множителя, выносим ее из-под дифференциала, сокращаем и получаем метры.
Если глубоко копать, выбросив из интеграла дифференциал, вы совершили ту же ошибку, что и Зенон в своих апориях, от чего у него нефизичные чудеса получались — бегун не мог черепашку догнать.
Чтобы формальное доказательство и автовывод полноценно работали, придется научить аналитиков писать требования не канцелярским языком а языком формальных систем.
В противном случае, программа будет лоскутным одеялом для верификатора — вот сюда смотри, а тут
рыбу заворачивалиunsafe.