Нет. Коэффициент ротации надо хранить в виде верхней границы, т.е.:
name k_orig k
banner1 10 10
banner2 10 20
banner3 20 40
banner4 10 50
У баннеров 1,2 и 4 в этом случае коэффициент ротации 10, а у баннера 3 — 20. Из неудобств: при удалении баннера или изменении коэффициентов надо будет пересчитывать цифирки. Из удобств: работать будет быстро. Если куда нибудь ещё кэшировать максимум — то совсем быстро будет работать, за log(n).
В синтаксисе MySQL rand() должен выглядеть так:
SELECT * FROM banners where k < FLOOR(RAND() * (max_k + 1));
Можно хранить нижнюю границу и тогда сравнивать k > ...., не суть важно, на скорость не влияет.
О том, что такое случайная величина и как получить требуемое распределение из равномерного рассказывают на лекциях по теории вероятности. В любом случае построить отрезок из интервалов, соответствующих коэффициенту ротации, и взять rand() на этом отрезке проще, чем городить массивы. Причём можно сделать так, что при показе баннера надо будет сделать только 2 запроса, и оба по PK. Апдейтить коэффициенты, правда, будет чуть сложнее. По сложности можно уложиться в log(n), так что 100 000 записей не страшно.
Ещё один вариант — построить индекс по полю коэффициента, а коэффициенты хранить в виде суммы всех предыдущих + коэффициент текущей записи. Тогда 1 запрос даёт максимальный коэффициент (это 1 проход по индексу), потом запрос типа where k > rand(max_k) limit 1 ещё раз пройдётся по индексу и вернёт нужную запись. Сложность этого алгоритма log(n) (т.к. есть индексы, а индексы — деревья), что вполне приемлемо. Удалять записи опять будет немного сложно, зато вся логика в базе.
Скорее всего окисление бутана в присутствии катализатора (платины, например), и протонной мембраны, примерно как в прямом метальном топливном элементе. Проблема только в нагреве до ~100 градусов цельсия.
Не стоит путать WRC и машины группы N. Более-менее свежие WRC стоят больше 300k евро, и от стоковых автомобилей там вообще мало что остаётся. А вот группа N — там да, переделки минимальны. Но обслуживание всё равно стоит денег, это же спортивный болид. Стоит закладывать минимум 1-2k евро на выезд без происшествий.
А в каком нибудь Мячково можно и на стоке прокатиться без проблем, на гражданской резине тормозов на 1 заезд хватает легко.
В Звёдном Городке как-то проводили эксперимент: там для McLaren Mercedes F1 (лет 10-15 назад) сделали симуляцию одной из гоночных трасс в центрифуге. Култхард тогда сказал, что очень похоже, но откатать сессию на настоящем болиде стоит дешевле :)
На сколько я в курсе, MS принимала довольно пассивное участие в разработке ECU, используется их SQL Server и обвязка к нему в системе мониторинга и сбора статистики, а на стороне машины всё делает Макларен.
Так зачем вы соотносите полученную на АЭС электроэнергию с общей энергией, вырабатываемой человечеством? А U238 можно использовать в реакторах на быстрых нейтронах.
На быстрых нейтронах, а не электронах.
Современные АЭС на тепловых нейтронах выжигают примерно 5% U235. То, что осталось — называют отработанным ядерным топливом, но его можно использовать в реакторах на быстрых нейтронах, а можно переработать и снова использовать в реакторах на тепловых нейтронах. Почитайте про замкнутый цикл ядерного топлива.
Еще часто забывают, что обычно в серверные матери можно воткнуть больше памяти. Скажем, 96 гигов на одну машину — без проблем.
Ну и рассыпуха более качественная, те же конденсаторы, например. Мелочь, кажется, а в итоге на надежности сказывается.
Защищённый режим на x86 архитектуре придумали в далёком 1985 году, там багов точно нет :) А шаред мемори — так она на то и шаред, что в адресном пространстве вашего процесса. В общем, этот плюс для демона не засчитывается :)
На половину ваших замечаний можно ответить «используйте пакеты и системы автоматического деплоя!» :) Решение использовать внешний демон или модуль к интерпретатору не так однозначно, надо тестировать и проверять.
Low-level программирования в статье, кстати, не было — использовали готовую библиотеку, так что тут с поддержкой всё ок.
Кусок СВОЕЙ памяти. В случае с демоном у него будет, конечно же, своё адресное пространство, и веб-сервер или сервер приложений (php-fpm, например) его память выплюнуть никак не сможет.
Касательно вибраций — чтобы в машине работало, даже при езде по гравийной дороге.
Совсем любитель — это нету практически никакого опыта разводки. Видео, по крайней мере HDMI — это совершенно точно высокие частоты, дифференциальные линии и т.д., шансов развести правильно крайне мало :) Какие частоты при разводке на матрицу, подключаемую напрямую, не знаю, честно говоря.
А вообще, на плате должно быть питание, GPS-приёмник на UART, датчики ускорения скорее всего на SPI, sd-карточка и usb-device, ну и в идеале экран с тачем. Вроде совсем немножко. Главное, чтобы габариты не особо большие получились.
А как разъём процессорного модуля относится к вибрациям? Есть ли шансы у совсем любителя развести плату-носитель так, чтобы оно завелось более-менее сразу? Я так понимаю, что там уже можно без многослойных текстолитов обойтись, достаточно двухстороннего, если не разводить видео.
У баннеров 1,2 и 4 в этом случае коэффициент ротации 10, а у баннера 3 — 20. Из неудобств: при удалении баннера или изменении коэффициентов надо будет пересчитывать цифирки. Из удобств: работать будет быстро. Если куда нибудь ещё кэшировать максимум — то совсем быстро будет работать, за log(n).
В синтаксисе MySQL rand() должен выглядеть так:
Можно хранить нижнюю границу и тогда сравнивать k > ...., не суть важно, на скорость не влияет.
Ещё один вариант — построить индекс по полю коэффициента, а коэффициенты хранить в виде суммы всех предыдущих + коэффициент текущей записи. Тогда 1 запрос даёт максимальный коэффициент (это 1 проход по индексу), потом запрос типа where k > rand(max_k) limit 1 ещё раз пройдётся по индексу и вернёт нужную запись. Сложность этого алгоритма log(n) (т.к. есть индексы, а индексы — деревья), что вполне приемлемо. Удалять записи опять будет немного сложно, зато вся логика в базе.
А в каком нибудь Мячково можно и на стоке прокатиться без проблем, на гражданской резине тормозов на 1 заезд хватает легко.
Современные АЭС на тепловых нейтронах выжигают примерно 5% U235. То, что осталось — называют отработанным ядерным топливом, но его можно использовать в реакторах на быстрых нейтронах, а можно переработать и снова использовать в реакторах на тепловых нейтронах. Почитайте про замкнутый цикл ядерного топлива.
Ну и рассыпуха более качественная, те же конденсаторы, например. Мелочь, кажется, а в итоге на надежности сказывается.
Low-level программирования в статье, кстати, не было — использовали готовую библиотеку, так что тут с поддержкой всё ок.
Совсем любитель — это нету практически никакого опыта разводки. Видео, по крайней мере HDMI — это совершенно точно высокие частоты, дифференциальные линии и т.д., шансов развести правильно крайне мало :) Какие частоты при разводке на матрицу, подключаемую напрямую, не знаю, честно говоря.
А вообще, на плате должно быть питание, GPS-приёмник на UART, датчики ускорения скорее всего на SPI, sd-карточка и usb-device, ну и в идеале экран с тачем. Вроде совсем немножко. Главное, чтобы габариты не особо большие получились.