dom1n1k: А за все ужимки с потайным функционалом надо отбивать руки.
Нафига время тратить? Если руки итак не очень, и мозги в заморозке, считай отбиты?
Там где руки "на уровне" - заказчик твой шильдик никогда не тронет. У "старой гвардии" другие проблемы - рад бы снять "свидетельство грехов ногтей младых", да доступа лет дцать как нет, а заказчик так привык, так привык...
Сколько раз твердили миру: для кажного дела, свой струмент, негоже гвозди биноклей колошматить, а за блохой с кувалдой! Станислав Макаров - респект!
И чисто практический пример: несколько лет назад народ набрал бабла на кикстартере, но продукт так и не выкатили. Причина была в том, что выбрав МангоБД в качестве основного хранилища не смогли впихнуть в него реляционные данные.
По своему опыту: у меня в некоторых проектах мирно сосуществуют Редис, Манго и старый добрый Мускл сдобренный Сфинксом, а на клиентской стороне плюс ко всему еще IndexedDB и Local Storage вместе с Session Storage.
Не нужно плодить сущности без надобности - это харам, нефиг бегать за модными названиями, но использовать подходящие инструменты для решения подходящих задач - вполне кошерно даже.
и не забываем - сабл работает на Питоне, все Штормы - на Java, а VSCode, Atom, Brackets - NodeJS + Electron или подобная среда (читай - Хромиум), поэтому Сабл всегда будет выигрывать в скорости реакции интерфейса и отрисовки у всех, выигрывать у Штормов в обработке и проигрывать Нодовским в скорости реакции плагинов.
И еще не забываем - очень многое зависит от того, какой кривизны ручки писали плагин: если кривизна ручек выше кривизны извилин, тут не спасет никакая крутая основа.
ЗЫ. По поводу снятия шильдиков с машин. Честно говоря, ни разу не видел, чтобы какой-нибудь адекватный человек этим заморачивался. А по детству вспомню: были "коллекционеры", втихушку от хозяев эти шильдики тырили, а потом на жвачку меняли :)
Про "копирайтеров", читай литературные негры, с ними отказ от авторства - часть договора об оказании услуги именно в таком виде. Их услуга именно в этом и состоит: текст + отказ от авторства в пользу заказчика.
Прошу не путать понятия, основу и следствия. Не елка пахнет Новым годом, это в новый год пахнет елочной хвоей и мандаринами. :)
LEXXiY: все верно. Уточню: активная ссылка - хоть и слабая, но гарантия, что подпись не подделана. В этом топике, помимо предыдущего комментария, я оставил еще и ответ. Полагаю, он расставит все точки и на i и на ё.
Ты еще Рембранту или Микеланджело расскажи, что они не имели права ставить подписи на своих полотнах.
Веб сайт - это инструмент.
Ты покупаешь машину, а на багажнике - шильдик, и на капоте - второй, в последние годы размером во всю решетку радиатора, а в багажнике набор инструментов и на каждом ключе - оттиск, и на молотке надпись во всю ручку. Даже на буксировочном тросе, если он качественный, обязательно пришит кусочек тряпочнки, на котором написано, что сделала его ответсвенная Маша, а не безымянный китайский партизан.
Создаю инструмент я, и я решаю - подписать свою работу или нет, это мое авторское право, кстати защищенное законом, а в огромном количестве случае закон напрямую обязывает делать это - указывать производителя.
Те же, кто убирает подпись творца - просто тупые шкодники, срывающие шильдики с машин и срезающие лейблы со штанов.
И от таких придурков, реально нужно защищаться.
Кстати, подписи в первую очередь важны для заказчиков: когда ты выбираешь будущего исполнителя, ты шаришься в его портфолио, и чтобы убедиться, что в портфолио указана работа реально выполненная этим исполнителем, ты идешь по ссылкам в портфолио и ищешь там подтверждение - подпись. Ссылки подписи - гарантия качества, нерадивый вебмастер не станет шуметь о своей нерадивости.
То есть, подпись разработчика, это для тебя же и таких как ты. По этим ссылкам не переходит кто попало, по ним переходишь ты и твои коллеги в поисках толкового исполнителя. По ссылке нерадивого вебмастера, ты не пойдешь.
Бывало, я продавал автомобили, у них на заднем стекле, иногда на лобовом, были объявления. Крупными буквами. Просто огромными. После покупки новые хозяева смывали эти объявления, но я не видел, чтобы они отрывали шильдики производителя.
А если я большими буквами масляной краской на лобовое стекло нанесу ВАСЯ, то у меня не купят автомобиль.
В LESS нет циклов?
Рекурсивные миксины - на самой первой странице офсайта - пример с построением сетки. Синтаксис остается предельно близко к CSS, а мощность офигенная, позволяет творить чудеса, которые с другими препроцессорами делаются с большим количеством бубнов и костылей.
Это не в каждом Javascripte, тут уже ресурсные ограничения, ограничения среды, но как вариант, да - второй солдат с лопатой, при необходимости - взвод: Map&Reduce как раз про это. C MR можно и отдать этот паттерн и необходимый кусок потока для обработки, а получить уже готовый "вкл" или "выкл" если не за процессорный цикл, то в пределах следующего ping
> Если вертикальная и горизонтальная - это плоский массив
При разворачивании в плоский массив - вообще один и тот же, а в идеале - совсем исходный.
> Создать набор крестов и в этом же цикле транспонировать
Можно, и даже в той же итерации, но зачем?
> SHL и SHR
Их применение - 1) другой подход, 2) применение ограничено
В ответе алгоритм, который описывался конкретно для JS и имеет массу ограничений на длину исходной строки и на длину искомой комбинации, он идеально решает конкретно эту поставленную задачу, но не годится для общего случая с плоским массивом.
> можно сравнивать любые массивы данных в любом языке
да, и оценка времени алгоритма практически не изменится и будет уже зависеть и от размера "креста" и собственно от функции сравнения.
Упускаем самое главное - изначально я говорил о подходе: рассматривать матрицу, как плоский массив, даже как поток, а не преобразовывать ее. Это дает преимущество в использовании индексов смещения для одновременного вычисления нескольких соответствий (вдоль, поперек и накрест, и хз как вздумается) в одном шаге итерации. А преобразование же ведет к (а) дополнительным вычислениям при поиске у краев строки, (б) большим значениям индексов, (в) ресурсным ограничениям при больших объемах, таким как память, размеры индексов и т.п., (г) невозможность обрабатывать данные в потоковом режиме, когда на определенном этапе используется только часть данных.
Т.е., чтобы иметь возможность работать в потоковом режиме нам на каждой итерации достаточно иметь в распоряжении лишь столько строк, сколько нужно, чтобы построить подстроку для вертикального сравнения. Это единственное ограничение именно для организации потоковой обработки, про ресурсные ограничения здесь речи нет.
Еще одним плюсом потокового подхода есть то, что массив может содержать в ячейках не биты, а любые данные, в том числе - сложные структуры данных и даже результаты других функция. Временная оценка алгоритма от этого не измениться, просто реальные затраты времени выполнения будут зависеть от сложности функции сравнения. Сам же алгоритм может оставаться во временных рамках O((n-2*l)*m*l), т.е. количество операций сравнения всегда будет меньше количества элементов массива, что уже считается хорошим поисковым автоматом, а если временные функции сравнения будут константами или хотя бы линейными - вообще красота.
Короче для больших данных:
1. бежим привычно по массиву двумя индексами по столбцам и строкам, внутренний цикл включают все следующее, что мы называем итерацией (это про эти INC и DEC ?)
2. Если валидный адрес для сравнения, сравниваем искомую подстроку (паттерн) с подстрокой вычисленной из позиции, используем результат и тут же вычисляем следующий валидный адрес (это еще не поток, хоть и похоже).
3. Используя индекс вертикального смещения определяем - нужно ли проводить вертикальное сравнение. На основании абсолютной позиции, значений длин строки и паттерна (вот оно где! - представление как потока или плоского массива!), вычисляем значение кусочка столбца необходимого для вертикального сравнения (1), делаем сравнение (2), используем результат (3), на основе результата, вычисляем сколько итераций мы НЕ будем делать вертикальное сравнение (4). Если нам нужен крест фиксируем и его, также легко мы можем фиксировать и другие окружающие ячейки, хоть кругом, хоть квадратом, лишь бы они нам были доступны.
Т.е. это основа для любого ланшафтного алгоритма: сжатие JPEG, фильтры в Фотошопе, сравнение отпечатков пальцев, распознавание лиц, карты погоды, прокладка курсов, контроль качества поверхностей, поиск игиловских "тачанок" в песках сирийщины, запуск Вояджера к херам и Обамы за картой и ластиком. Просто некоторые из перечисленных примеров используют эту же основу рекурсивно с применением различных функций сравнения, что "утяжеляет" алгоритм лишь на значение в степени, соответствующей глубине рекурсии. Все отличие данного конкретного случая в том, что рекурсия без надобности и функция сравнения это A&0b111===A - процессору на 2-3 цикла.
С Обамой будет посложнее: и функций сравнения разнообразие, и глубина рекурсий, хоть и конечная величина, но все же достаточно серьезна. Понадобятся уже другие методы оптимизации - наличие нескольких матриц, принудительный отказ от обработки неактуальных данных: скорость подлета той же Булавы - сверхзвуковая, не все данные поступающие в потоке необходимо обрабатывать; возможно, понадобиться применение уже не 2мерной, а 3Д или же больше, матрицы; понадобятся дополнительные матрицы функций сравнения и паттернов и т.п., НО основа алгоритма останется прежней, а значит, задача - решаемой.
> неизвестно как делать это действительно параллельно при таком объёме операндов
Каком объеме? Операндов не так уж и много и плодить сущности необходимости нет. Во первых, нет такой большой и подробной карты, которую нельзя было бы порвать на мелкие кусочки, это раз.
Третье. Два солдата из стройбата заменяют экскаватор, и пример тому - распределенные сети ПК, заменяющие мощные суперкомпьютеры; про модные кластеры и алгоритмы Map&Reduce - вообще молчу - и так у каждого на слуху.
Третье. Если паттерн реально огромен. Допустим аналитическое сравнение аэрофотоснимков огромных территорий за вчера и за сегодня. Кто нас заставляет какой-то снимок делать паттерном? Пусть оба снимка будут входными потоками, а еще лучше поступают в одном потоке, а паттерном пусть будет некая функция с линейным, а еще лучше константным временем выполнения. Такой паттерн переданный в функцию сравнения может за ОДНУ итерацию дать результат сразу по ДВУМ снимкам. С этим подходом не то, что игиловскую тачанку позволит обнаружить, а еще позволит вычислить куда она с@$сь и с какой скоростью. Любой армейский старшина в курсе, как чугун люмином назначить, а нам, что? - высшее образование мешает? Главное не терять разумность подхода - трактор коню не замена, трактор может заменить только сотню коней, но никак не одного. Т.е. действительно большие массивы данных - в поток; если надо - сделать паттерн "думающим", например - регэксп, конечный автомат (некий "черный ящик" с предсказуемыми конечными состояниями от простых "вкл" и "выкл", до более сложных, но определенно перечислимых) годится и для роли паттерна и для роли функции сравнения и при необходимости мы их можем использовать одновременно для обработки одного потока данных на одном уровне рекурсии. Т.е. тут я говорю, что используя регексп в качестве функции сравнения, можно ему передавать в качестве паттерна результат другого регекспа, т.е. паттерн не обязательно должен быть "железным".
Идея размотать массив в ряд очень перспективная, особенно если размерность матрицы будет меняться. Особенно в ширину (высота не особо критична, и если ширину принимать, как длину строки, и всем должно быть понятно, что здесь строка, ширина, высота - понятия условные и связанные лишь с наглядностью).
А в таком случае, когда строки изменяемой длины или с длинной строки, превышающей разрядность операционной среды (именно среды, Javascript, например, имеет разрядность 32 в большинстве случаев, даже на 64 битных машинах, в 64 битных ОС в 64 битном браузере.
Но Вы не используете ее преимуществ, пытаясь оперировать ВЫСОКОУРОВНЕВОЙ логикой. Вспомните про операции SHL и SHR и сразу построение алгоритма станет другим, за счет использования других принципов.
По моим прикидкам, ассемблерный код решения этой задачи для процессора К580 должен уложиться примерно в 400 байт, со временем выполнения O(n) < n^2. Описание подхода дал ответом, хотя, уверен, что даже описанный подход можно еще улучшить, например, за счет комбинирования прохода "крестом".
В Вашем подходе можно сэкономить память и ресурсы за счет отказа от второго - плоского транспонированного - массива, а использовать второй набор индексов смещения. Это же позволит в одной и той же итерации вести проверку, как на вертикальное, так и на горизонтальное совпадение, и плюсом еще и на совмещенное совпадение "крестом", тогда Ваш подход будет иметь преимущества перед низкоуровневым подходом. Ну, соответственно, еще кое-что в алгоритме нужно изменить.
Оптимизировал, оптимизировал, да невыоптимизировал :)
Идея с разверткой в ряд - неплохая, НО: 1) битовой-то логики и не использовано, 2) транспонирование - РЕАЛЬНО кривая идея - если уж речь об оптимизации, то надо было уж сразу flatten90 или ключ для флэттера, но это возможно б было, если битовая логика все-таки была :) 3) читать этот код - реальный труд, убил бы :)
Array.filter - еще более затратная по времени и ресурсам функция, чем поиск indexOf, плюс еще ведется копирование в новый Array, а потом еще обработать как-то надо. Да он просто повеситься!
P.S. он - в данном случае и браузер, и человек ожидающий результата :)
Главная плюха Sublime - уже давно все есть и он легкий и стабильный, если всякую хрень в него не пихать.
Несмотря на наличие плагинов для отладки Sublime, в т.ч. визуальной, отладка под Node - это VSCode или WebStorm, в край - Atom. Минус VSCode - до фига зависит от мышки, а дараг-н-дропа текста НЕТУ!
В Сабле не кисло вообще без мыши, а при необходимости можно и наоборот однопальцевым способом работать -одним пальцем левой ноги :)
А в Angular изначально дофига изучить и той самой коробкой он ограничен и чтобы расширить нужно извернуться как удаву. И размер Ангулровской коробки его и плюс и минус: много чего есть, но все это плашмя, порог входа слишком высок. Тем не менее, скорее всего Ангуляр2 будет лидировать в дальнейшем - слишком уж распиаренный 1й, от преимуществ использования которого осталась лишь его популярность.
Нафига время тратить? Если руки итак не очень, и мозги в заморозке, считай отбиты?
Там где руки "на уровне" - заказчик твой шильдик никогда не тронет. У "старой гвардии" другие проблемы - рад бы снять "свидетельство грехов ногтей младых", да доступа лет дцать как нет, а заказчик так привык, так привык...