От них - это от кого? От трансформаторов?
Предположим, нам надо запитать потребителя с напряжением 5 В и мощностью 100 Вт на расстоянии в 1 км. То есть, нам надо обеспечить ток в 20 А.
Удельное сопротивление медного провода 0.017 Ом*мм2/м. Для длины в 2000 м (туда и обратно) получим 34 Ом*мм2.
Если мы хотим, чтобы потери составили не более 1%, или 1 Вт, то нам нужно сопротивление провода не более 1/202 = 1/400 Ом. Тогда сечение провода будет 34/(1/400) = 13600 мм2, что соответствует диаметру 131.6 мм.
Если же передача будет идти напряжением 220 В, то ток будет 0.45 А. В этом случае допустимо сопротивление 4.84 Ом, соответственно провод понадобится диаметром 3 мм.
Значит гораздо удобнее для передачи электричества поднять напряжение рядом с источником и понизить его перед потребителем. Здесь и используются трансформаторы.
Но повышение или понижение напряжения - это не единственное их предназначение. Они работают как электрические развязки в измерительных приборах, как согласующие элементы в схемах.
Bodrosh, Во-первых, не количество вхождений, а позицию вхождения. Во-вторых, если элемента нет в строке, то возвращается 0, что эквивалентно FALSE, если есть - то не 0 (TRUE).
Sienore, Получить можно в PHP, и в JS. Но для подписи вам надо шифровать не сам файл, а только хэш от него.
На мой взгляд, оптимальная последовательность будет примерно следующей:
- Клиент передаёт файл на сервер.
- Сервер записывает файл в базу, вычисляет хэш от него, передаёт хэш на клиент.
- Клиент шифрует хэш закрытым ключом, передаёт полученную подпись на сервер.
- Сервер дешифрует подпись открытым ключом, привязанным к пользователю, удостоверяется, что хэш правильный, записывает подпись в базу.
HadjyGit, У вас же права на участок могут меняться, соответственно если нужна история владения участком, то придётся держать отдельную таблицу. И, возможно, учитывать ещё и долю владения.
`owners` (`area_id`, `user_id`, `acquisition_date`, `loss_date`, `share`)
yuriy2, Если я правильно понимаю документацию, то Using where присутствует всегда, кроме случаев, когда в запросе явно указано, что нужно взять все строки (то есть отсутствуют WHERE, JOIN, HAVING и т.п.).
Об использовании составного индекса здесь прямо говорится, что используется только непрерывная левая часть индекса.
Эврика! Здесь говорится, что в случае покрывающего индекса (а здесь именно такой случай) записи индекса используются для ускорения доступа к данным при переборе, так как записи индекса, в общем случае, занимают меньше места и расположены компактнее, чем записи самой таблицы.
Неправильно. Часть составного индекса используется, только если она совпадает с началом ключа.
В вашем примере WHERE a=1 будет использовать индекс, WHERE a=1 and b=2 тоже, а WHERE c='text' - не будет.
Вячеслав Барсуков, Значит берёте нужную часть, изучаете, смотрите, почему не работает, восстанавливаете. Реверс-инженеринг занятие не из простых.
Либо просто обращаетесь к автору и просите исходники.
Вячеслав Барсуков, Нет, файлы не склеили, а запаковали в сборку с помощью webpack.
Большую часть проще скачать из источников, благо все ссылки там присутствуют. Ну а остальное - только скопипастить нужный фрагмент и вручную восстанавливать имена функций и переменных.
evgeniy_lm, В графическом представлении интеграл - это площадь. Вспомните, как даётся определение интеграла через трапеции. Теперь возьмите, например, трапецию, нижняя сторона которой - ось X, боковые стороны x = 0 и x = 10, верхняя - y = x/2+10. Посчитайте площадь трапеции, сначала по стандартной формуле, затем через интеграл (x/2+10)dx от 0 до 10. Удивитесь, что результат получился тот же самый.
Когда контур задан ломаной линией (то есть координатами концов отрезков), то обычный интеграл по нему можно представить в виде суммы площадей трапеций, интеграл относительно точки - в виде суммы площадей треугольников.
Конечно, если исходные данные представлены исключительно в виде картинки цвет(x, y), то интегрирование не поможет, но там и ваш метод суммирования углов даст дикую погрешность.
