«Решение интеграла» в том случае, когда он решаем — обычно функция (производная которой и дает заданную в условии функцию). Видимо, численное решение подразумевает получение значений этой ф-и с заданным шагом в заданном диапазоне при заданных граничных условиях. Чтобы хотя бы график можно было нарисовать. Или полиномом апроксиммировать.
И вообще, с интегралами у меня всегда было плохо. Что вы такие сложные вопрсоы задаете!
Но в любом случае, я сомневаюсь, что библиотека, интегрирующая любую функцию в аналитическом виде, вообще существует в наблюдаемой нами части вселенной.
Во-первых, даже с использованием flush контент может скапливаться в буере веб-серера (зависит от используемого сервера и его конфигурации). Во-вторых, в случае использования AJAX не факт, что яваскрипт сможет читать данные из незавершенного запроса. Потому для надежной реализации данные надо либо слать каким-нибудь веб-сокетом, либо отдельными запросами.
Нету. Это было бы слишком сложно и дорого в плане производительности (так как процессору надо читать/записывать данные в память с очень блоьшой скоростью). Если вы пишете (или будете писать) на ассемблере, то узнаете, что память — просто набор ячеек, с адресами (номерами), и в каждую (или в несколько соседних) можно положить число или прочитать оттуда число. Это самый простой и быстрый способ. Правда, при этом надо не забыть, в какой ячейке что хранится, но это уже заботы ОС, компилятора, рантайма и программиста.
В одну ячейку можно записать 1 байт (= 8 бит) т.е. целое число от 0 до 255. Чтобы записывать большие числа, или дробные, их представляют в виде нескольких байт.
Например, на системах на процессоре Intel x86 (то есть на обычных домашних компьютерах):
Целые числа (например, переменная типа int на 32-битной системе) хранятся в памяти в 4 соседних ячейках в двоичном виде. Числа с плавающей запятой (переменная типа float/double) хранятся в памяти, разбитые на мантиссу и экспоненту, в 4 или 8 соседних ячейках. Строки и тексты хранятся посимвольно, каждый символ кодируется определенным числом (1 символ в 1 ячейке, если же используется юникод, то 1 символ хранится в нескольких ячейках). Картинки хранятся попиксельно (1 пиксель = 4 байта, в которых в числовом виде хранится яркость красной, зеленой, синей составляющей и степень прозрачности пикселя). Звук (несжатый) тоже хранится в виде последовательности чисел.
Вообще, компьютер − это же усовершенствованный калькулятор, потому там все хранится в виде чисел.
То есть когда вы в программе (если вы программируете) пишете x = 1, то это сводится к тому, что в определенные ячейки памяти сохранятся число 1 в двоичном представлении.
В linux, если ваша строка лога (а так оно обычно и бывает) записывается в файл одним системным вызовом write(), система гарантирует, что она не будет перемешана с другой строкой (хотя что-то я не могу найти подтверждения этого в мануалах сейчас). А вот LOCK_EX может выплюнуть ошибку доступа, и в лог вообще ничего не попадет. Потому это худший вариант. Разве не так?
> в месте вызова функции инстанцировать объект и вызывать метод. Кроме всего прочего это иногда позволяет разгруппировать несколько параметров на конструктор и сам метод
А нафига? В чем логика вместо makeMeGood($a, $b, $с) вызывать $goodMaker = new GoodMaker($a); $goodMaker->setSomeOption($b); $goodMaker->finallyMakeMeGood($c);? Получаем кучу мусорного кода в классе, получаем раскиданный по приложению код создания и использования объекта, и гораздо больше писанины.
Я понимаю, если этот $goodMaker потом раз 20 используется, но вы-то предлагаете заменить «вызов функции» на эту цепочку. Давайте еще абстрактную фабрику и стратегию добавим, что уж там.
Профита три. 1) Функции группируются в классы по смыслу. Например, вместо function directoryCopy(), directoryRemove() и т.д. получаем простой и логичный класс Utils_Directory с методами copy(), remove(). 2) работает автозагрузка. 3) вместо глобальных всюду-видимых и конфликтующих переменных у нас приватные статические поля класса. Инкапсуляция.
Главное — уметь давать правильные названия и правильно группировать методы в классы.
А, еще проверяйте страну-источник IP-адреса. Пост на русском с китайского IP, конечно, возможен, но крайне подозрителен — может, такому товарищу стоит попросить пройти дополнительную проверку?
Четвертая задача (а что себя ограничивать то?). Open Source модуль для сбора и статистического анализа любых данных. То есть, демон, который накапливает поступающие большим потоком числа в памяти, потихоньку сбрасывает сборную статистику в таблицу и позволяет делать выборки. На его основе, например, можно сделать свой модуль статистики посещений сайта и путей пользователя, только в реальном времени. Или модуль для распознавания аномалий в HTTP трафике.
А, еще вдогонку. Про именование функций. Не называй функции в стиле do*, типа doMakeRequest() или doConnect() — это реально уродливо смотрится, особенно когда там же есть функция connect() и остается гадать чем она отличается от doConnect().
Это не будет работать почти во всех ИЕ. Вы бы хоть потестили прежде чем спасибо писать. Минусовать в карму надо за такие «советы». Тем более, что есть древний метод с document.write()