Глеб Ницман gleb_l

Lefter и righter конечно не существуют, но leftmost и rightmost запросто - и не только в сказочных контекстах )

БД обладает некоторым информационным контекстом I - это память цифрового автомата. Чтобы перевести его из состояния Xn (соответствующего контексту In) в состояние Xn+1, нужно в общем случае зафиксировать In на все время вычисления In+1 = F(In), где F - бизнес-функция. Когда F может быть описана в терминах множеств, и требует большого количества данных одновременно (то есть принадлежащих одному номеру состояния n), способ обработки данных (на уровне множеств - T-SQL, или на уровне потоков выполнения - процедурные ЯП) и близость обработчика к самим данным становятся архикритичными. Никакие удобства разработки и сопровождения для этих случаев (а это собственно, основное предназначение СУБД, как систем массового обслуживания - многопоточная обработка множеств) не стоят отказа от использования этих свойств.

И обратно - как только вы отказались от СУБД, как от машины обработки множеств - вы отказались от большинства ее преимуществ, за которые заплачены деньги на покупку лицензии - то есть вы покупаете автобус, чтобы возить в нем пассажиров по-одному.

Вычитали-сделали-собираемся записывать - пусть даже с контролем версий строк. Как вы сделаете когерентный апдейт? Например, какое-нибудь сведение текущего баланса пользователей из агрегата их суточных расходов? Будете по одному итерироваться?

Опять всё про выборку данных. Скажите что-нибудь про эффективную модификацию.

Исходный пост был больше о том, где брать сами мысли, а не о способе их оформления стандартным для профессии образом.

У меня была такая идея несколько лет назад. К камере надо прикрутить не motion detection, а анализ полицейского или эвакуаторного маячка в кадре. Это можно сделать частотным методом (Фурье). Отправлять предупреждение владельцу нужно только тогда, когда рядом - проблесковые маячки

Интеллект (искусственный, или естественный, неважно) - это отрицательный преобразователь подводимой энергии в информационную энтропию. Что-то наподобие туннельного диода на участке с отрицательным сопротивлением. Если робот способен увеличить количество знания в инфосфере - значит он обладает интеллектом. Человек - способен ;)

Именно так. Считайте, что вы выиграли в лотерею автомобиль премиум-класса, который в обычных условиях не то, что купить - содержать вам не под силу. Чем просто на нем таксовать, лучше на его основе придумать сервис премиум-уровня (раз уж он у нас есть) - так хоть может придёт шанс его отбить. Если же ничего не делать - то шанс гарантированно НЕ придёт - и когда наступит время вкладываться в обслуживание - вам не на что это будет сделать, и бизнес лопнет. То есть Кесарю - кесарево )

В исходном посте написано, как повысить эффективность — то есть кпд. Если подключить вместо одного паровоза два — эффективность не изменится. Сила тяги — да. Но за это придётся и заплатить дважды.

Если у вас увеличилась внешняя эффективность (кпд) системы в два раза, и при этом увеличилась ее сложность (количество звеньев, в каждом из которых есть свои внутренние потери), то какой же кпд был изначально? Похоже, что исходные конфигурации имели эффективность паровоза

Разница ключевая. Стоимость Дрона не имеет смысла делать меньше стоимости его доставки — «лишние» деньги лучше вложить в его гибкость, надёжность — то есть в конструкцию. Потому что за кирпич на Марсе вы все равно заплатите условный миллион — так лучше заплатить два за гарантированно полезный зонд. Тем более, что следующий шанс представится на уже совершенно другом уровне технологий (через 17 лет)

Сколько стоит фунт полезной нагрузки, доставленной на поверхность Марса? Сколько стоит та часть софта, которая наблюдает за вертолетом из основного модуля? Сделанная, кстати, не на raspberry pi. Поэтому не имеет смысла экономить на зонде, даже если он является побочной частью эксперимента.

Современная космическая техника — sparkfun, snapdragon, Linux. Никаких кремниев-на-сапфире, своих RTOS, золотых плат сверху донизу — типичный коммерческий дрон в космосе ;). Завтра на Марсе появится Ардуино и breadboard!

Так как людей в самолёте много, каждого можно не взвешивать — достаточно верно определить принадлежность чела к кластеру, а дальше г-н Гаусс сам справится. Другое дело, что среднеамериканский мистер может оказаться тяжелее среднего сухонького месье из Франции, поэтому нужно ориентироваться ещё на перцентили веса по национальностям — скорее всего, так и делается. Но вот ошибка кластеризации да, может существенно сдвигать расчетные данные от фактических. Щетильней надо, ребята! (с)

Если у Вас есть бесконечное время, бесконечный бюджет, и бесконечная энергия — можно, конечно, превратить рыбу в птицу, внеся стохастику в модель наследования, функцию штрафа за ошибку, и самому наблюдать, просто покуривая в сторонке. Но в условиях ограничений приходится интенсивно впрыскивать внешнюю информацию в модель системы, чтобы сократить количество итераций ;). Что касается амфибий и прочих межсредовых комбинаций — оно не может быть одинаково эффективно в обеих средах так, как это делают нативные организмы или устройства. Поэтому в естественной среде (эволюция), или искусственно-организованном выживании (война) амфибии неизбежно вымрут

Полностью соглашусь!
О производительности нужно думать на этапе продумывания архитектуры. Вспомните Создателя — он придумал птицам, в числе прочего, трубчатые кости. Не стал их высверливать, увидев, что опытный экземпляр птицы способен лишь подпрыгивать, а придумал и сделал сразу )
Поэтому нельзя, проектируя аппарат передвижения по воздуху, “просто подкрутить что-то, или добавить памяти/ядер”, чтобы корабль стал самолетом. Не взлетит.

И ещё — посмотрите, как отличаются в фармакологии этапы создания препаратов, эффективные in vitro и in vivo. Между ними — «дистанция огромного размера». В инженерии все очень похоже — если опытный экземпляр с трудом оторвался от земли — то, чтобы серийный безопасно летал — нужно затратить ещё 10*X усилий. Поэтому если тестовая версия софта с трудом укладывается в требования по производительности — это не только не повод для радости, но и означает, что исходно требования по производительности не были «встроены» в архитектуру, и если кардинально ничего не поменять — то прод их гарантированно провалит.

“При \gamma_1 близким к нулю..” — можно ведь виртуально повернуть ГСК, скажем на 45 градусов в тех плоскостях, по которым проекции углов малы, и посчитать ещё раз. Затем скорректировать эйлеровским методом, так как поворот априори известен. Будет так работать?

Это несомненно. Раздельным управлением тормозным усилием на каждом колесе без участия ГТЦ пользуются, кроме АБС, ещё и системы курсовой устойчивости и виртуальная блокировка дифференциала. Просто исходный пост был про педаль )

«Насколько помню а/м с усилителем тормозов — они управлялись более перемещением педали, чем усилием на ней. При исправном усилителе.»
Нет, не так. Теоретически, при отсутствии зазоров в механизме, сила торможения пропорциональна силе прижатия колодок к дискам (барабаны с самозаклиниванием не берём). Усилитель — более-менее линейная вещь, этой функции кардинально не меняет. То есть, педаль в идеальном механизме вообще может не иметь хода, но транслировать силу нажатия в силу прижатия колодок — то есть в интенсивность торможения. То, что в реальном автомобиле ход есть — результат конструктивных и эксплуатационных допусков. В системе break by wire можно даже поставить вместо педали колодку с тензосенсором — и это будет даже уменьшать остановочный путь за счёт снижения времени перемещения ноги вместе с педалью. Правда, последнее считается контринтуитивным в управлении человеком, поэтому даже в полностью электронных системах ход командных органов все же делают

Нули не гашу