Сергей, Императивные языки разные, где-то есть хвостовая рекурсия, где-то нет, где-то компилятор решает использовать её или не использовать (https://habrahabr.ru/company/pvs-studio/blog/261027/). Ну и практически всегда хвостовую рекурсию можно циклом заменить.
romajke, От этого - никак. Поскольку запись числа 0.1 в двоичной системе бесконечна, а его представление в компьютере конечно, то это представление имеет погрешность и в компьютере хранится число 1.00000000000000005551115123126E-1. При вычислениях погрешность накапливается.
Методы исключения погрешности зависят от задачи. В финансовых системах применяют расчет не в десятичных дробях, а в целых числах, считая, например, не рубли а десятые или сотые доли копеек, то есть не 10.05, а 100500. В системах моделирования используют расширенные арифметические библиотеки.
Зачастую уменьшить погрешность можно просто правильно выбрав порядок выполнения операций.
romajke, Нет, это не переполнение. double содержит 15 значащих десятичных разрядов. Но никто не мешает попытаться вывести его и в 100 цифр, просто дальше пойдут абсолютно недостоверные разряды.
cicatrix, В css - то, что в самом ответе, только указываете нужный класс. Добавляете этот класс в div на сервере либо на клиенте - div не печатается. Не добавляете класс - div печатается.
cicatrix, Это правило указывается в css, media определяет, что оно применяется только при печати. В div вы можете определить дополнительный класс, например noPrint и в css сделать правило для этого класса.
Vlad852, А вы прямыми одиночными кавычками указали MySQL, что это строка. Поле обозначается обратными кавычками или вообще без таковых.
sku, `sku`- поле
'sku', "sku" - строка
Vlad852, Запрос выполняется, потому что он синтаксически верен. Ничего не изменяет - потому что неверен логически. У вас 'sku' - это строка или поле таблицы?
9StarRu, При создании таблицы добавляете к описанию поля AUTO_INCREMENT. При добавлении строки не указываете `invoice_id`. Сразу после успешного добавления строки получаете его через mysqli_insert_id.
Марат Даллин, Вынос миниатюр в отдельную таблицу как раз и будет нормальной формой. Опять же, если миниатюры стандартизованы (хотя бы по одному измерению), то можно просто в базовой таблице указать максимальный номер миниатюры. Картинка маленькая - миниатюры до 3 размера, средняя - до 5, большая - до 7. Отдельная таблица имеет смысл если все миниатюры разных размеров.
Марат Даллин, Если это соотношение меняется 90x60 vs 60x90, то можно просто учитывать ориентацию при генерации миниатюры.
Если один из параметров сохраняется, скажем 90x60 vs 90x120, то, опять же, можно генерировать миниатюры на лету, уменьшая пропорционально.
Если же размеры отличаются, скажем одна миниатюра 60x90, вторая 60x97, третья 63x99, то придётся писать в БД.
Если шесть-семь миниатюр будет всегда и расширение не планируется, то можно заносить их данные в одну таблицу с основной фотографией. Если же многих миниатюр может и не быть или планируете увеличивать их количество, то надо выделять в отдельную таблицу, особой нагрузки на БД это не даст.
Sienore, В хэш должны попасть те данные документа, изменять которые в подписанном документе нельзя.
Чтобы другие программы могли проверить подпись они должны уметь рассчитывать хэш по документу точно таким же образом и использовать тот же алгоритм шифрования. Скажем в MS Word есть встроенная система подписи документов, но она не совпадает с подписью через КриптоПро Office Signature.
Подпись подтверждает неизменность документа и личность того, кто поставил эту подпись. Авторство документа может подтверждаться, если поле автора включено в рассчёт хэш-суммы.
