senior не будет проходить весь массив абсолютно каждый раз. Он будет использовать для этой задачи обычные циклы и напишет brake, если на текущей итерации стало понятно, что массив unordered
Это хорошая оптимизация, респект! В худшем случае мы можем понять неупорядоченность массива только в самом конце, поэтому на сложность алгоритма это условие не влияет 🤓
Спасибо за видео и интересную задачу! 👍 20:30 Решение конечно любопытное. Однако, утверждение о том, что мы один раз проходимся по массиву и используем константную память, к сожалению, никак не соответствует действительности. Дело в том, что slice, как и reduce, тоже является методом обхода массива, к тому же он возвращает новый массив. Получается, что проход у нас не один, та и память не константная. 🤔
Я прям повысил свою самооценку :)) у меня опыта в программировании 3 года , но 15 лет в математике , алгоритмы оптимальные придумать не проблема, а вот перенести на код занимает больше времени. Хотя эта задача простая, попадались и такие где алогитм придумать уходила неделя, потому что бизнеспроцесс приходилось изучать подробно, а код написать уже день два. Так что все относительно.
алгоритм также будет оптимизирован по памяти если использовать arr.reduce и Set как аккумулятор. Использование битовых операторов не показатель сеньора, битовые операторы тяжело читать и его используют только в местах которые редко читают - кор компоненты или команды из одного сеньора
Middle: много вычислний size + математические операции над массивом (тем более, если он будет большим) - тоже не сильно оптимальнее первого варианта джуна
Есть вариант с рейтингом чего либо. Например 1го числа у штерна было 100 слушателей, 2-110, 3-120. Берешь массив [100,110,120] - рейтинг растущий. Это условно, в твоем проекте если это надо посчитать на миллион моргенштернов плохая затея, а если на пару сотков строк в таблице - то норм
А копию массива сделать (который как говорилось в видео может миллион элементов содержать) чисто ради того, чтобы нормальный цикл не писать - это точно норм для синьора? Точно ли оптимально по памяти выйдет?
Страшно, очень страшно, если бы мы знали, что это такое но мы не знаем, что это такое. Видео отобьёт любое желание заниматься программированием у начинающих.
Забей вообще. Даже не думай. Это приколы просто с математических кружков. Типа у кого писька длиннее, кто круче напишет. В 99% реальности такое не встречается. Последний пример реально для сениоров, сениоров извращенцев 😂
Сразу же поправлюсь, что в решении из видео для сеньёров есть совместимость с `Intl.Collator().compare`: с помощью функции Math.sign, так что остаётся только предварительный выход из цикла, если с массивом и так понятно, что он unsorted.
Это прикольный код с точки зрения оптимизации, если нужен очень-очень быстрый код и есть много времени его писать, но по факту лучший код для прода это код по принципу KISS, что больше всего подходит к решению джуна.
Я бы сказал, что получившийся код сеньора - это код крепкого олимпиадника по программированию. Как правило, в реальной жизни не требуется настолько сильной оптимизации. Что гораздо более важно - это писать понятный, легко расширяемый и поддерживаемый код. Конечно, не стоит писать так, как было показано в первом примере, но и чрезмерно оптимизировать код в угоду читабельности в современном мире тоже вредно (за исключением задач, которые требуют таких оптимизаций)
А если я просто 3 переменные создал куда просто посчитал, количество числе которые > предыдущих, < предыдущих или равны предыдущему. И по ним определил? Кто я? P.s. риторический вопрос. Как по мне это самый лучший способ (можно конечно вообще весь массив не проходить, но для понятности решил написать так, но битовые операции это уже оверхед как по мне, не знаю, мне кажется сеньор не стал бы запариваться так).
Могу только сказать, что решение Джуна быстрее выполняется )) если возьмем допустим массив из 100.000 то Jun 0.800, а Mid 1.6! А если от 1 млн то 7.00 и 16.00 ))
первое решение (джуновское) - выполнение за 3242ms. второе решение (миддловское) - выполнение за 6080ms (должно быть оптималеньнее, по идее). по третьему вопросов нет.
очень не хорошее решение, куча масок, главное ничего не забыть захендлить, я бы сказал это код джуна ‘когда понял как работать с битами’. Проще в цикле и используя паттерн rules
Как говорят умные люди, синьёрский код это код который понятен даже джунам, я не уверен, что такой вариант оптимальный, так как код поймёт не каждый разработчки, редьюс было использовать изначально очевидно, но остальное просто выпендрёж.
Это не код джуна, а код идиота. Или джаваскиптизеров не учат все делать за один проход цикла? Да и мидл мог бы заполнять сет на том же проходе и использовать брейк. Про читабельность всех вариантов вообще молчу, такое у меня ревью бы не прошло. Руки поотрывал бы за километровые строки
Ну серьезно это не сеньерское решение :))) почти все последовательности в этом мире не являются константами или строго монотонны и не строгомонотонны. А тут всгда алгоритм проходит по всему массиву. Есть более оптимальный алгоритм .
Не хотел бы я в проекте увидеть такой сеньёрский код, и сидеть думать что происходит
да никто так не пишет, это задрота бест практис тиснули с кодварс, разобрали и выкатили) с реальными задачами не имеет ничего общего
@@suspenseorigin5542 в реализации некоторых криптографических алгоритмов так и пишут)
Моя любимая рубрика) Жду еще!
Нам очень приятно, новый выпуск уже снят, ожидайте в ближайшее время на канале :)
senior не будет проходить весь массив абсолютно каждый раз. Он будет использовать для этой задачи обычные циклы и напишет brake, если на текущей итерации стало понятно, что массив unordered
Это хорошая оптимизация, респект! В худшем случае мы можем понять неупорядоченность массива только в самом конце, поэтому на сложность алгоритма это условие не влияет 🤓
Большое спасибо за материал! Открыли новый взгляд на решения.
Спасибо за видео и интересную задачу! 👍
20:30 Решение конечно любопытное. Однако, утверждение о том, что мы один раз проходимся по массиву и используем константную память, к сожалению, никак не соответствует действительности. Дело в том, что slice, как и reduce, тоже является методом обхода массива, к тому же он возвращает новый массив. Получается, что проход у нас не один, та и память не константная. 🤔
Я прям повысил свою самооценку :)) у меня опыта в программировании 3 года , но 15 лет в математике , алгоритмы оптимальные придумать не проблема, а вот перенести на код занимает больше времени. Хотя эта задача простая, попадались и такие где алогитм придумать уходила неделя, потому что бизнеспроцесс приходилось изучать подробно, а код написать уже день два. Так что все относительно.
алгоритм также будет оптимизирован по памяти если использовать arr.reduce и Set как аккумулятор. Использование битовых операторов не показатель сеньора, битовые операторы тяжело читать и его используют только в местах которые редко читают - кор компоненты или команды из одного сеньора
Middle: много вычислний size + математические операции над массивом (тем более, если он будет большим) - тоже не сильно оптимальнее первого варианта джуна
Спасибо за рубрику)
Спасибо за видео! Подскажите, пожалуйста, варианты где подобная задача может использоваться на практике?
Есть вариант с рейтингом чего либо.
Например 1го числа у штерна было 100 слушателей, 2-110, 3-120.
Берешь массив [100,110,120] - рейтинг растущий.
Это условно, в твоем проекте если это надо посчитать на миллион моргенштернов плохая затея, а если на пару сотков строк в таблице - то норм
А копию массива сделать (который как говорилось в видео может миллион элементов содержать) чисто ради того, чтобы нормальный цикл не писать - это точно норм для синьора? Точно ли оптимально по памяти выйдет?
Страшно, очень страшно, если бы мы знали, что это такое но мы не знаем, что это такое. Видео отобьёт любое желание заниматься программированием у начинающих.
Забей вообще. Даже не думай. Это приколы просто с математических кружков. Типа у кого писька длиннее, кто круче напишет. В 99% реальности такое не встречается. Последний пример реально для сениоров, сениоров извращенцев 😂
Почему так мало комментариев и лайков ? Хорошая рубрика, хороший материал, хорошая подача, спасибо!.
Предполагаю, потому что действительно увлекающихся мало.
Срасибо за видео, интересно. Но пожалуйста озвучивайте задачу полностью, пришлось пересматривать что бы понять почему входные данные не проверяются))
Если ваше последнее решение для сеньёров, то: 1. совместимость с `Intl.Collator().compare` (в случае массива строк) и 2. предварительный выход из цикла, если обнаружено unsorted; это видимо для надмозгов, не меньше.
```javascript
function sequenceClassifier(arr) {
let flags = 0, prev = arr[0];
for (let i = 1, len = arr.length ; i < len ; i++) {
const item = arr[i];
// the [-1, 0, 1] is compatible with `new Intl.Collator().compare`
if ((flags |= ((0b011 & (
item === prev ? 0// ((0b11 & 0) + 1) === 0b001
: item > prev ? 1// ((0b11 & 1) + 1) === 0b010
: -1// ((0b11 & -1) + 1) === 0b100
)) + 1)) === 0b111) {
break;
}
prev = item;
}
if (flags >= 0b110)return 0;
if (flags === 0b001)return 5;
return flags - 1;
}
```
Сразу же поправлюсь, что в решении из видео для сеньёров есть совместимость с `Intl.Collator().compare`: с помощью функции Math.sign, так что остаётся только предварительный выход из цикла, если с массивом и так понятно, что он unsorted.
Классный, очевидный код!
Это прикольный код с точки зрения оптимизации, если нужен очень-очень быстрый код и есть много времени его писать, но по факту лучший код для прода это код по принципу KISS, что больше всего подходит к решению джуна.
Можно пытаться как-то совмещать удобочитаемость и понятность кода с его эффективностью.
Например, решить как-то так:
function sequenceClassifier(arr) {
const [decreasing, constancy, increasing] = arr.reduce((acc, curr, i, arr) => {
if (i > 0) {
const prev = arr[i - 1];
const index = Math.sign(curr - prev) + 1;
acc[index] ||= true;
}
return acc;
}, [false, false, false]);
if (decreasing && increasing) {
return 0; // unordered
}
if (increasing) {
return !constancy
? 1 // strictly increasing
: 2; // non decreasing
}
if (decreasing) {
return !constancy
? 3 // strictly decreasing
: 4; // non increasing
}
return 5; // constant
}
Я бы сказал, что получившийся код сеньора - это код крепкого олимпиадника по программированию. Как правило, в реальной жизни не требуется настолько сильной оптимизации. Что гораздо более важно - это писать понятный, легко расширяемый и поддерживаемый код. Конечно, не стоит писать так, как было показано в первом примере, но и чрезмерно оптимизировать код в угоду читабельности в современном мире тоже вредно (за исключением задач, которые требуют таких оптимизаций)
А если я просто 3 переменные создал куда просто посчитал, количество числе которые > предыдущих, < предыдущих или равны предыдущему. И по ним определил? Кто я?
P.s. риторический вопрос. Как по мне это самый лучший способ (можно конечно вообще весь массив не проходить, но для понятности решил написать так, но битовые операции это уже оверхед как по мне, не знаю, мне кажется сеньор не стал бы запариваться так).
Почти такая же идея пришла в голову. 🙂 Вот, что получилось:
function sequenceClassifier(arr) {
const [decreasing, constancy, increasing] = arr.reduce((acc, num, i, arr) => {
if (i) acc[Math.sign(num - arr[i - 1]) + 1] |= true;
return acc;
}, [false, false, false]);
if (decreasing && increasing) {
return 0; // unordered
}
if (increasing) {
return !constancy
? 1 // strictly increasing
: 2; // non decreasing
}
if (decreasing) {
return !constancy
? 3 // strictly decreasing
: 4; // non increasing
}
return 5; // constant
}
если усложнение это то чему способствует опыт, тогда совет новичкам, не гонитесь за опытом)))
а нельзя за 1н проход определить тип через for? просто каждый раз сравнивать элементы текущий и следующих. Все равно прийдется пройтись минимум 1 раз
У вас там копия массива и замыкание. Откуда константность по памяти?
Могу только сказать, что решение Джуна быстрее выполняется )) если возьмем допустим массив из 100.000 то Jun 0.800, а Mid 1.6! А если от 1 млн то 7.00 и 16.00 ))
Мне кажется что синьер не стал бы решать такую джунскую задачу, а поручил бы первому попавшемуся джуну 🎉😮😅
для определения неупорядоченной последовательности необязательно проходить весь массив
const classifier = (numbers) => {
let first = numbers.shift();
return numbers.reduce((acc, item, index) => {
console.log(first, item);
if (item < first) {
return VALUES.decrease
}
if (item > first) {
return VALUES.increase
}
if (item === first) {
return VALUES.same
}
first = item;
}, 0);
};
вроде работает без СИНЬЕРСКОГО КОДА
это если было бы три условия было, а там пять условий в задаче, еще not increase и not decrease
я думал наоборот код сеньора всегда элегантен и прост для чтения
код из видео ревью не пройдет и даже не оптимален
первое решение (джуновское) - выполнение за 3242ms.
второе решение (миддловское) - выполнение за 6080ms (должно быть оптималеньнее, по идее).
по третьему вопросов нет.
очень не хорошее решение, куча масок, главное ничего не забыть захендлить, я бы сказал это код джуна ‘когда понял как работать с битами’. Проще в цикле и используя паттерн rules
Как говорят умные люди, синьёрский код это код который понятен даже джунам, я не уверен, что такой вариант оптимальный, так как код поймёт не каждый разработчки, редьюс было использовать изначально очевидно, но остальное просто выпендрёж.
Это не код джуна, а код идиота. Или джаваскиптизеров не учат все делать за один проход цикла? Да и мидл мог бы заполнять сет на том же проходе и использовать брейк. Про читабельность всех вариантов вообще молчу, такое у меня ревью бы не прошло. Руки поотрывал бы за километровые строки
Ну серьезно это не сеньерское решение :))) почти все последовательности в этом мире не являются константами или строго монотонны и не строгомонотонны. А тут всгда алгоритм проходит по всему массиву. Есть более оптимальный алгоритм .