Pull to refresh

Comments 37

UFO just landed and posted this here
Топик не читай — комментарий скорее оставляй…
Интересно было бы увидеть Usecase с этой библиотекой. Единственное, что приходит на ум — продвинутые игры?
Какой развернутый аргументированный и главное полезный коммент. Я вот тоже задаюсь тем же вопросом про юзкейс
Да что угодно. Сейчас все типы софта уходят в веб. И 3д редакторы, и редакторы музыки, и программы для решения мат. задач. Все что есть в десктопе, вскоре может быть и в вебе. А без математики — ололо будет.
Ну с тяжелой математикой на клиенте, по моему логичнее организовать веб-сервис — расчет, который занимает больше чем 100ms, выгоднее сделать на сервере, чем грузить браузер (тут задумываемся над различным перформансом разных браузеров)

Как модуль для Node.js или какой нибуть скриптовый игровой движок — годится, вот только что с этим делать на сервере (ну допустим можно в случае веб-сервиса на ноде, но такие проекты вроде изначально выгоднее реализовать на Java/.NET)
хотя вероятно для небольшой размерности вполне сгодится и на клиенте сделать, придумал например электронные таблицы — такое там показано
Математические задачи не имеют алгоритмической сложности.
Если сложные задачи делать на сервере — он может лопнуть.
Это для меня сюрприз. Особенно про сервера.
Сервер-то не лопнет, а вот заставлять слабого клиента тужиться на серьезных вычислениях — это не гуманно.
Ну, не такие уж и слабые клиенты нынче пошли. Хотя, разумеется, клиент клиенту рознь, но всё же — какого уровня вычисления становятся серьёзными? Сейчас на иных клиентах, вон, десктоп игрушки запускают, портированные в JS, HD видео силами то же JS декодируют в реальном времени…
Если в арсенале имеются статистические функции, то это как бы подразумевает работу с большим объемом данных, а переносить это на какой-нибудь мобильный клиент, когда проще отдать уже готовый результат, как минимум странно. Хотя это, конечно, все inDepend.
Тут нельзя однозначно утверждать. Если результатами планируется воспользоваться как основой для других вычислений — то на клиент не спихнёшь, а в целом во многих прикладных задачах, имхо, куда выгоднее озадачить 1000 клиентов, чем под то же самое покупать сервера. Ну и опять же — то ли это вычисление одно на всех и его можно закешировать — это одно, а если это нечто уникальное — проще отдаль клиенту. Много pro et contra в этом вопросе.
А разве не гораздо удобнее вместо того, чтобы городить дебри многострочного кода с умеренно кривыми (особенно при самостоятельном написании) реализациями численных методов, задействовать готовое решение в виде одного вызова функции?
Любые серверные приложения на Node.js, где нужна не только тривиальная арифметика. Домашняя бухгалтерия, игра, исследовательская база с большим количеством разных выброк данных и динамическим подсчётом результатов и статистик по ним.
У меня огромная торговая система для биржи написана на Node.js. В том числе я там сделал свою библиотечку для таких вещей как рассчет гауссова распределения и так далее. Появись эта либа на несколько лет раньше… :)
А работу с числами произвольной длины (как GMP) эта библиотека умеет?
Пока не умеет, никаких типов для длинных чисел там нет. Тут ведь всё от популярности и необходимости зависит, может, в будущем и вырастет до уровня GMP, но только если кому-нибудь это будет нужно на ноде.
У библиотеки 2 больших минуса:
Она похоже не прописывается просто так в window в браузере. А как бы небрежно писать в доках «With node, simply require it: var numbers = require('numbers');», и не упоминать о первом синусе, как минимум некрасиво.

Там как-то пофигистично относятся к производительности. Глянул 1-ю функцию, дальше наверное еще хуже. jsperf.com/numbers-js-sum
Все почему-то смотрят на использование в браузере. Однако, мне кажется, что даже по докам основной юзкеис — Node.js на сервере. С производительностью, думаю, со временем будет лучше, пока важно, чтобы был какой-то удобный и общий интерфейс доступа к функциям, а там уже народ подтянется и допилит не оптимальные решения.
Node.js это тот же V8 что и в WebKit-браузерах. Поэтому тесты в Хроме позволяют сравнить производительность на сервере.
Прошу прощения, про браузеры это было в тему комментариев чуть выше, где все ищут способ использования на клиенте. Да, в плане производительности библиотека не фонтан. Просто потому, что там везде стоят проверки и пока нет никаких оптимизаций. Такие вещи делаются со временем, не сразу и, вообще говоря, не всегда.
Подключаем библиотеку под Node.js и вычисляем интеграл Римана


Понимаете, хотя разных интегралов действительно много, но с точки зрения численного счета бывают только интегралы Римана, а никаких других не бывает (если вдруг кому-то захочется просветить меня насчет других интегралов, которые таки считаются численно, то сразу скажу, что все они в конечном счете сводятся именно к интегралу Римана). И для вычисления этого одного типа интегралов есть как минимум два десятка широко применяемых сейчас методов и в каждом случае выбирается оптимальный (если этим занимается специалист). Так что и само название функции совершенно неинформативно и сама функция опасна (поскольку ничего не говорит о том, как и что она там на самом деле считает).

позволяет в явном виде задавать необходимую точность вычислений, что помогает избежать ошибок округления


Эх, если бы явное задание необходимой точности вычислений позволяло всегда достигать этой точности и магическим образом избегать ошибок округления, то мне бы давно пришлось уйти в веб-программисты (чур меня, чур).

Все же язык в очень большой степени определяет мышление.
Понимаете, хотя разных интегралов действительно много

Да? Не перечислите?

если вдруг кому-то захочется просветить меня насчет других интегралов, которые таки считаются численно, то сразу скажу, что все они в конечном счете сводятся именно к интегралу Риман

Интеграл Лебега. Сведите к Риману для функции Дирихле
И как Вы будете численно считать интеграл Лебега? Особенно интересуют функции, неинтегрируемые по Риману.
Библиотека для меня оказалась очень полезная, т.к. она решает кучу геморроя, связанного с анализом данных (для получения красивых графиков в админке). Потихоньку портирую ее на PHP, репозиторий на github: github.com/powder96/numbers.php. Буду рад, если пригодится кому-нибудь кроме меня.
if (Object.prototype.toString.call(arr) === '[object Array]') { ... }


Зачем? Может я чего-то не понимаю, но почему так, а не

if (arr instanceof Array) { ... }

На самом деле вообще дурная на голову проверка, потому что JS следует концепции duck-typing'а, а проверка её нарушает. Без неё я бы мог спокойно создать свой объект со свойством length и числовыми свойствами 0, 1, 2 и т. д. Или подсунуть в функцию arguments. А так я ограничен только объектами Array.
Насчёт typeof ладно — его поведение не всегда очевидно и его стоит использовать только в случаях, определенных спецификацией.

Но с instanceof-то что не так? Написанное здесь мне непонятно.

<<цитата>>
function Foo() {}
function Bar() {}
Bar.prototype = new Foo();

new Bar() instanceof Bar; // true
new Bar() instanceof Foo; // true

// Всего лишь присваиваем Bar.prototype объект функции Foo,
// но не экземпляра Foo
Bar.prototype = Foo;            // # WAT???!!!
new Bar() instanceof Foo; // false # А с чего бы должно быть true?
<<конец цитаты>>

Зачем присваивать прототипу не экземпляр, а класс и удивляться, что instanceof возвращает false?

В общем:
console.log([] instanceof Array); // true
console.log(new Array() instanceof Array); // true
console.log(Array() instanceof Array); // true

Это работает.
Внимательно читали?
Здесь надо отметить одну важную вещь: instanceof не работает на объектах, которые происходят из разных контекстов JavaScript (например, из различных документов в web-браузере), так как их конструкторы и правда не будут конструкторами тех самых объектов.

Заключение

Оператор instanceof должен использоваться только при обращении к пользовательским объектам, происходящим из одного контекста JavaScript.
Спасибо, прочитал спецификацию, п. 15.2.4.2

Буду знать.
Sign up to leave a comment.

Articles

Change theme settings