Алексей Тен, итак...я постараюсь обобщить, всё что удалось узнать в пачку тезисов. Если, в целом, мои догадки верны, то можно закрывать вопрос и потом отмечу решения, что мне помогли.
1. В скриншоте из книги - асимптотическая точная оценка функции, которая говорит что:
1.1. при определённых константах c1 и c2, есть функции c1*f(n) и c2*f(n), которые являются, соответственно, верхней (О-большое) и нижней(о-малое) границей для f(n), т.е. f(n), при наличии определённого множителя, может стремится либо к верхней границе, либо к нижней, но никогда не достигнет их.
1.2. В данном случае, Θ(n^2) (Тета) показывает характер роста функций - парабола. Даже, полагаю, может являться верхней границей. При этом "характер роста", соответственно, сохраняется как для границ, так и для самой функции.
2. Вышеуказанные определения не имеют ничего общего со "сложностью алгоритмов", кроме "нотации О", которая используется для упрощения членов меньшего порядка, определениях худших/лучших случае (верхняя/нижняя граница) и т.д., при анализе сложности алгоритма.
3. "Сложность алгоритма" описывается путём подсчёта необходимого количества инструкций в конкретной реализации (коде).
---
Прошу поправить, если есть неточности, или может какие-то ещё важные нюансы, которые могут пригодится и о которых я забыл отписать? Заранее, спасибо.
Как уже говорили выше, разница почти в 2 раза...Как-то тяжело понять, что это несущественно, даже для бесконечных величин...ну да ладно.
Ок...картинка по - тихонечку вырисовывается, почитав другие ответы, побороздив ещё раз книгу...
Тогда, как связать "оценку" (как я понимаю, это то, что ниже Mercury13 назвал "асимптотический порядок многочлена") со "сложностью"?
Всё это я прочитал и ранее. Если бы мне были понятные сухие мат. определения, то, вероятно, здесь бы писать и смысла не было бы )
По правильному, как пишут на вики, "n входит/принадлежит в O(n^2)", что в целом соответствует проиллюстрированный выше в комментарии картине, но...вопросов это, лично для меня, не снимает :(
Понятно. Тогда почему Кормен пишет о второй степени, если ни в одном случае, на практике (по приведённым методам: цикл и формула), выйти на этот порядок не удаётся?
Сумма натуральных чисел при росте n растёт как n^2
От этой формулировки, складывается впечатление, что при
n = 1, формула Кормена, должна быть равна 1;
n = 2, должна быть равна 4; (на самом деле = 3)
n = 3, должна быть равна 9; (на самом деле = 6)
И т.д.
Нынче вроде бы динамические маршруты, которые Вам нужны для минимизации веса / размеров подгружаемых файлов, у react-router'a из под коробки реализуются. По крайней мере точно помню, что в 4-ой версии были какие-то импрувы в этой области. Этого должно хватить. Ну и плюс, грамотная реализация вебпэк конфига с чанками и т.д.
computed и их практическая польза на начальном этапе вызывает множество вопросов для меня, особенно в контексте данной задачи...Перечитал ещё раз. Попробовал применить...но что-то как-то не вышло...
Безусловно, наличие key необходимо для адекватного ре-рендера чилдренов React'a без MobX в виде массива. Но как я посмотрел с MobX - другая ситуация. Дополнительно, проверив опытным путём, увидел, что ему абсолютно всё равно на их наличие, т.к. подменяет механизмы обработки ре-рендера (включая shouldComponentUpdate)
Для бОльшей наглядности я опубликовал проект, иллюстрирующий проблему (без экспериментов с computed):
Проект: https://github.com/Naararouter/mobx-problem-001
Девелопер-тулз: https://chrome.google.com/webstore/detail/mobx-dev...
Буду бесконечно благодарен, если удастся посмотреть и найти решение, либо направить меня по "пути истинному".
P.s.: проект - модель реальной задачи, в итоге получилось что-то похожее на банальный ToDo List. Постарался максимально абстрагироваться от контекста, сохранив структуру компонентов в реальных условиях.
Господи...сработало, спасибо! Часа 4 пытался понять в чём дело ( ~_~ )...Не припомню, что бы это было в документации в июле прошлого года...стараюсь периодически перечитывать оф.доки, ибо часто обновляются...но что-то этот абзац упустил...Еще раз спасибо.
Mikhail Osher: хм...что-то подобное я и имел ввиду, говоря о "ленивой загрузке". Но изначально не совсем понял суть приведённых Вами компонентов. :) Теперь дошло, спасибо, думаю, подобный вариант для решения в текущих условиях подойдет больше всех.
В целом, текущая разработка - попытка переосмысления компонента, который мне достался от другого разработчика. Там было множество строчек кода, которые "велосипедно" пытались эмулировать движения прокрутки и т.д., включая touch-события и т.д., но в итоге компонент был не рабочим, разбираться в том, что было наворочено - тоже не малая часть времени, при том, что было сделано ~20% от общего объема работ и предъявленных к компоненту требований. Собственно на тот момент и сейчас, мой компонент выдался, я считаю, более удачным, т.к. большая часть забот по обработке событий скролла досталась браузеру с его стандартным скроллом и, вроде бы, это себя оправдало.
По поводу Canvas, в комментариях к самому вопросу, уже высказали подобное мнение. Вероятно, если альтернатив не поступит, придётся переписывать на Canvas.
Поюзал компонент по ссылке. Если я правильно понял, то данные таблицы/списки, а именно List, на который перенаправило по-умолчанию, выступает в качестве визуализации некоего конечного множества сущностей. Т.е. они имеют начало и конец прокрутки. У меня же должна быть бесконечная прокрутка, как в игровых автоматах (где дёргают за рычаг и барабаны на экране начинают прокручиваться...как раз и в моей задаче необходимо 3 подобных колеса), с соответствующей плавностью и т.д.
Stalker_RED: Хм...думаю, что в конечном счёте, если оптимизировать и адекватно работать ЭТО не будет, то придётся делать так, чтобы адекватно работало, несмотря на смену стека технологий...
Конкретно отвечая на вопрос: нет, не думал, если честно изначально даже в голову не пришло. Видимо потому, что опыт работы с Canvas'ом крайне небольшой (парсил рукописные черно-белые символы для подачи на вход нейронной сети).
Если не сложно, может, посоветуете с чего можно быстро начать, что бы реализовать подобную задачу? Может какие фреймворки и т.д., которые могли бы облегчить рутинные операции и т.д.? Возможно, есть какие-то ссылки, где можно почитать как это работает "под капотом" и за счёт чего я получу необходимый прирост производительности?
