All streams
Search
Write a publication
Pull to refresh
3
0
Bronx @Bronx

User

Send message
Чтобы не путаться, посчитайте мощность непосредственно на колёсах, для обоих случаев, при одинаковой скорости и тяге. Сюрприз — она будет одинакова и не будет зависеть от оборотов двигателя, потому что обороты двигателя связаны с оборотами колёс передаточным числом (как и момент на валу).

Ещё раз: обороты ДВС нужны лишь для того, чтобы выйти на режим максимальной мощности, которая конвертируется в момент на валу. Электродвигателю ничего этого не нужно — у него будет сразу вся потребная мощность и момент.
на малых оборотах мощности электромотора все равно не хватит

При равной скорости мощность будет выше у того мотора, который разовьёт бОльший момент на данной скорости. Электромотор выдаёт этот момент сразу. ДВСу, чтобы выдать ту же мощность, нужно набрать высокие обороты, что требует последующего их понижения.
Интересно, спасибо. Про фейл Таргета в курсе, ага :)

Мне почему-то представлялось, что для дебеток использование ПИНа — это правило, исключения из которого довольно редки, и что аутентификация по ПИНу не связана с чипованностью карты, потому что ПИНы были и до чипов (чип просто добавляет секьюрности за счёт встроенной криптографии). Две моих дебитки — нечипованные, но всякие Костко и их заправки ПИН исправно просят.
Технически да, сумма таки указывается, хотя часто это всего $1, лишь бы проверить валидность карты; зависит от заправки.

А как отель может начать новую транзакцию по дебитке без повторного ввода ПИНа?
Фишка в том, что если лимит уже был полностью выбран ранее, то карта уже стала неактивной, и банк отклонит транзакцию уже на этапе авторизации, которая происходит до платежа и не требует знания суммы платежа. Если авторизация таки прошла, это означает, что банк взял на себя обязательство заплатить продавцу столько, сколько потребуется позже по факту — даже если итоговый баланс клиента выйдет за лимит. У клиента потом просто инактивируют карту пока он не восстановит баланс, и, возможно, возьмут штраф за овердрафт.

С дебетной картой так не выйдет — там для авторизации нужно уже знать всю сумму платежа. Исключение — если продавец вначале блокирует на карте максимально возможную сумму покупки (скажем, 100 литров бензина за раз), а потом берёт из неё сколько надо, но это неудобно покупателю, потому что заблокированная сумма некоторое время «висит» как недоступная.
Нужно добавить центрифугу :)
Их-за возможности искры запрещается наливать бензин в канистру, держа её на весу — нужно обязательно ставить на землю.
Может потому что карта дебитная? Потому как на кредитной деньги всегда «есть», потому что это деньги банка, и он с вас будет их стрясать в конце биллингового периода.
Ещё немножко удобств:
* Zen Coding
* JavaScript parser
* MultiEditing
* Indent Guides
* Tab Studio (платный, но того стоит)
1. Настраивать диаграмму направленности датчиков так, что бы мосты не попадали.
2. Принудительно временно отключать режим по повторному нажатию педали акселератора.
Тормоза нужны только трусам и не умеющим рассчитывать оптимальную скорость :)
Тут нужно разделять понятие «арифметики» (что и как считаем) и «нотации» (как записываем числа и операции).

Простота опирается на «целость», поэтому имеет смысл лишь в целочисленной арифметике (считаем только целые числа, причём нас тут интересуют только натуральные).

Десятичная система счисления — это просто нотация для записи числа («десятичное число» — это число записанное в позиционной системе с основанием 10). Таких нотаций может быть множество, некоторые весьма замысловатые (скажем, можно записывать числа как простые дроби, а можно как десятичные; можно использовать римские цифры и правила). Выбор конкретной нотации диктуется удобством (как выбор системы единиц или системы координат в физике). Взаимные соотношения чисел в заданной арифметике остаются неизменными, так как зависят лишь от самих чисел и от свойств операций, а не от способа записи.

Простота — это как раз одно из таких взаимных соотношений в целочисленной арифметике. Оно теряет смысл при преходе в арифметику рациональных/вещественных чисел, но сохраняется при смене нотации (основания системы счисления, например, или при переходе к римским цифрам)
Стеклянная призма --> тёплое ламповое преобразование Фурье :)
Я бы сказал, основная мотивация для последовательных id — это всё же возможность использования кластерных индексов. Непоследовательный уникальный id всегда можно сгенерировать на основе последовательного, применив какую-нибудь обратимую функцию, но выгоды никакой — и кластеризацию поломает, и нижеописанные проблемы останутся.

Другие проблемы:
* Простота последовательных id может обернуться боком, когда захочется, например, смерджить данные из двух баз в одну, и целые диапазоны первичных ключей перекроются. Особенно весело, если эти значения уже расползлись по другим базам, и уже нельзя их просто так взять и поменять.
* Невозможность генерить уникальный id на клиентской стороне, что несколько усложняет создание объектов — приходится вместо простого результата «успех/неуспех» возвращать ещё и id свежесозданного объекта, затем апдейтить его у клиента, что не даёт использовать immutable object pattern и загрязняет код.
Скорее био-кибер-панк: клеточные механизмы (РНК, белки и проч) — как раз в основном механические :)

Дело в том, что на некотором уровне миниатюризации механика начинает выигрывать. Свободный электрон слишком лёгкий и поэтому слишком легко туннелирует, так что есть неиллюзорный нижний предел на размеры проводников/транзисторов/емкостей, при котором тепловой шум и туннельный эффект ещё не выводит из строя устройства на свободных носителях зарядов. А вот атомы — они тяжёлые и устойчивые, валентные связи между ними крепкие, и даже устройство с характерным размеров в один-два атома (скажем, полимерная нить) будет продолжать работать. Скорость будет ограничена скоростью распространения звука (т.е. механических колебаний) в веществе, но она довольно высока (за счёт силы валентных связей), и при таких расстояниях это уже не очень существенная разница.
Интересная штука.

На bitbucket-e у вас в примерах в документации закралась ошибка, как мне кажется: в Option<int> скармливаются строки. Соответствующий юнит-тест при этом корректен.
Ускорение — это и есть «искривление» локального пространства-времени, причём доступное здесь и сейчас, и задёшево. Курить принцип эквивалентности сил гравитации и инерции и помнить, что мы сами выбираем удобные нам координатные системы, и для ускоренных систем криволинейные координаты оказываюются удобными.
Насколько серьёзна проблема поиска работы для ex-гуглера? Учитывая упомянутый вами фактор остановки в развитии, плюс проблема over-qualification («он из гугла, ему у нас не будет хватать мотивации, ну его нафиг») и проч.
Это не так важно, как то, что 15 апреля налоги не нужно будет платить :)
В принципе, есть более сложный случай: личные данные случайно утекли и разползлись по тысяче ресурсов. Дыру закрыли, поисковик очистил кеш — но это касается только сайта-виновника утечки. А те тысячи сайтов, на которых личные данные успели осесть, прекрасно находятся. Человеку со всей этой толпой сражаться нереально, но ущерб может быть снижен, если эти сайты не будут попадать в выдачу.

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

Information

Rating
5,315-th
Registered
Activity