Препрег — предварительно приготовленный, ткань уже пропитана смолой, но при этом не липкая. Чтобы началась полимеризация смолы — надо её нагреть, для равномерного нагрева и поддержания температуры и давления и нужен автоклав. А вы, вероятно, видели примерение обычной ткани, которую по какой-то причине назвали препрегом.
То одна из них окажется снизу и будет работать :) Почитайте про лонжероны в крыльях самолётов, например, там как раз множество вариаций использования усиления из композитов.
Препреги наносятся не особо сложно, приложил, закрепил, нагрел. Есть только 1 мелочь — нужен автоклав :) В принципе, на доску можно и феном строительным нанести, но геморно очень будет и равномерно расплавить и держать температуру препрега вряд ли получится.
В домашних условиях намного проще работать непосредственно с эпоксидкой и карбоном/стекловолокном/кевларом, чем препреги юзать. В простейшем случае примерно так происходит: www.youtube.com/watch?v=X-q91ywCrqQ&feature=related.
Яростно плюсую! Практические темы по непосредственно программированию в универах должны быть в рамках спецкурсов, а не как основные предметы. А вот про основные предметы, типа ТАУ, преподаватели могут рассказывать интересно (если, конечно, самому слушать хоть немного), проверено на собственном вузе. Там люди преподают и занимаются наукой, могут примеры из практики приводить. У нас ещё были замечательные курсы типа «статистические методы обработки информации», уже после первых нескольких занятий мне было очень смешно читать книжки для трейдеров от форексклуба :)
Нет. Коэффициент ротации надо хранить в виде верхней границы, т.е.:
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 году, там багов точно нет :) А шаред мемори — так она на то и шаред, что в адресном пространстве вашего процесса. В общем, этот плюс для демона не засчитывается :)
В домашних условиях намного проще работать непосредственно с эпоксидкой и карбоном/стекловолокном/кевларом, чем препреги юзать. В простейшем случае примерно так происходит: www.youtube.com/watch?v=X-q91ywCrqQ&feature=related.
У баннеров 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. То, что осталось — называют отработанным ядерным топливом, но его можно использовать в реакторах на быстрых нейтронах, а можно переработать и снова использовать в реакторах на тепловых нейтронах. Почитайте про замкнутый цикл ядерного топлива.
Ну и рассыпуха более качественная, те же конденсаторы, например. Мелочь, кажется, а в итоге на надежности сказывается.