Как стать автором
Обновить
1
0

Пользователь

 Если говорить о среднем значении, то риски настолько минимальны, что вам потребуется летать в течение 25 тыс. лет, чтобы умереть в авиакатастрофе с вероятностью 100%.

Ну как бы вероятность 100% никогда не будет. Среднее значение - ок, но писать по-другому нужно. Сильно глаз резануло.

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

Вёрстку особо трогать не буду, но что там абсолютные значения высоты - а задумывались что будет если фамилия например длинная и не влезет в одну строку?

ApiResult выглядит опасно, у вас можно быть в теории Success с null значением? Мне кажется это уже совсем не успех.

Адаптер - смесь when и if выглядит странно, плюс у вас адаптер и холдер склеены в один класс.

Куча мест где есть проверка на null выглядит странно, чисто для примера Color.parseColor(item.lesson?.color) что тут будет если цвет null?

sortLessons выглядит максимально странно, создание мутабельного map куча конвертов данных, отдача изменяемого списка.

Может это прозвучит и цинично, а проблема то в чём? Он работает как считает нужным, ему платят. Если бы его работой были недовольны то ему или сказали или уволили. Если это не происходит, значит сделка устраивает обе стороны. Кто в этой ситуации страдает? Другие сотрудники, которые так не делают? Ну так можно дойти до того, что все, у кого перфоманс ниже топового в команде, немного нехорошие люди, работают меньше а получают столько же. Если работодатель начнёт платить меньше, работник будет сильно выяснить а что случилось? Или пойдёт резюме обновлять. Мне кажется тут тоже самое.

К вопросу "В чем различия ArrayList и LinkedList?"

" каждый раз при вставке элемента будет создаваться новый массив размера n+1(где n размер массива до вставки)."

Что-то не верится, а там нет умножения на 1.5 (2) размерности? Вот реально каждый раз переаллокация?)

то что не подошли именно эти символы не значит что там такой фигни нет.

Спасибо за тест, сложнее всего было понять где именно ошибка в паттерне вида

*ptr
ptr -> call()
if (ptr)

Для меня тут ошибка в лишней проверке, а не в вызове) но 10/10 со второй попытки.

По поводу делать продукт быстрее — есть вопросы. Теперь у вас программисты сами тестируют свой код по тест кейсам, сколько на это уходит времени от времени разработки? Не бывает ли такого, что задача условная перекрасить кнопку (со временем разработки полчаса), а тестирование занимает полдня (проверить эту кнопку во всех случаях). Не вырос ли из-за нововведения ФОТ (программисты обычно получают в несколько раз больше чем ручные тестировщики, которые по тест кейсам работают), нет ли жалоб от программистов что им не особо нравится тест кейсы тыкать по 10 раз в день?

Хотелось бы если честно подробностей.

странно. При копировании -1 что-то не скопировались.


for (int l=0,r=sizeof(v)/sizeof(v[0]) - 1,lM = v[0], rM = v[sizeof(v)/sizeof(v[0]) - 1];

Иначе выход за границы массива и что угодно может быть.

на сях как-то так в один проход делается.


int v[] = {1, 2, 3, 4, 6, 3, 2, 4, 7, 3, 4, 6, 1, 2, 1};
int count = 0;
for (int l=0,r=sizeof(v)/sizeof(v[0]),lM = v[0], rM = v[sizeof(v)/sizeof(v[0])]; 
                l < r; 
                lM = max(lM,v[l]), rM = max(rM,v[r]))
    if(lM >= rM)
        count += rM - v[r--];
    else
        count += lM - v[l++];

Ну давайте. Посчитаем количество мальчиков. Кеп говорит что будет 1 в сумме. Считаем количество девочек.
0/2 + 1/4 + 2/8 + 3/16 + 4/32+… ну вы поняли. Итого 1. Вроде всё правильно.

Самый простой способ. Берём большое количество пар у которых нет детей. Ровно у половины будет мальчик. У второй половины девочка. Пока 50/50. Начинаем 2 раунд. У оставшихся у половины мальчик, у второй половины девочка. Опять 50/50 и так далее.


А вы кстати ряд неправильно написали. Надо было (n-1)/2^n что в точности равно единице. Ну и мальчиков единица по определению.


И сразу AlexTest. Вероятности так не работают) У каждого броска монеты 50/50. Какую стратегию ни строй, ничего изменить нельзя. Любое множество бросков будет иметь именно такую вероятность среднюю.


P.S. вопрос оказался сложнее, чем я думал.

Как-то большего ожидал. Вопросы имхо совершенно начального уровня.


Ну по вопросам всё просто.


первый

99 надёжно. последний передаёт бит чётности.


второй

ну если не думать то f = (f + 1) /2 отсюда на 1 мальчика будет 1 девочка. И ничего не меняется. Ну что логично в целом, так как количество детей никак не влияет на проценты рождаемости.


По задачам


Первая

Ну известная формула. https://oeis.org/A000124


Во второй ещё бы цикл обычный попросили написать, ну это несерьёзно даже...


Третья

Всё в один массив пар элементов (дата, флаг ухода) сортировка, проход. Сложность O(n log n). Абсолютно каноничная задача.

спорно если честно. Я например аниме смотрел буквально пару штук, корейские новеллы вообще не читал, ранонбе тоже почти что не читал, но книга зашла. Я не вижу в ней такой прям азиатчины. Самое интересное, что серия масок (Метельский) мне кажется как раз ближе к азиатчине, но тем не менее тоже зашла. Эх, может реально корейские новеллы пойти почитать)


P.S. хотя рекомендовать почитать ВПНТ, например в кругу коллег, я бы не рискнул.

Спасибо за статью. Было интересно взглянуть на функциональный подход в таких задачах. Честно говоря, удивлён что скорости ввода/вывода было достаточно. Например в задаче С обычные операции ввода/вывода на С++ (используя cin/count) заняли 321 ms на 193 тесте.


В задаче F всего 20 тестов и тут уже интересно. Одно и то же решение (речь идёт о честном, не используя подсчёт на [0,100]), но последовательно заменяя cin/count -> cin/count + cin.tie + sync_with_stdio(false) -> посимвольное чтение и сборка числа "руками" ускорила 0.611s -> 345ms -> 213ms. Отсюда видно что ввод/вывод данных в моём решении занял не менее 0.4s а это почти половина лимита…


Сами задачи мне не очень понравились. На таких языках как Java или C# было на порядок сложнее сделать быстрое чтение/запись чем решить саму задачу.


Мне кажется что решение на хаскеле надо ускорять не в сторону красивой свёртки а именно со стороны чтения.


P.S. прилагаю самый быстрый вариант чтения (может натолкнёт на идею, к сожалению я сам недостаточно хорошо знаю хаскель что бы это реализовать)


Заголовок спойлера
inline int read(){
    int tmp;
    do
    {
        tmp = cin.get();
    } while (tmp < '0' || tmp > '9');
    int res = tmp - '0';
    for (tmp = cin.get();tmp >= '0' && tmp <= '9';tmp = cin.get())
    {
        res = res * 10 + tmp - '0';
    }
    return res;
}

А если учитывать, что точность сильнее теряется подальше от 1, то становится ещё интереснее. Что лучше, умножить 2 числа 10 порядков или 10 раз но 2 но 0.5 (пример грубый).

Можно. А чем это будет лучше сразу системы непересекающихся множеств, которая за 2 умножения/деления всегда даёт ответ? Добавление в систему в среднем O(1). Построение всей системы строго O(N) (1 BFS или подобное из корневой).


А вообще задача мне показалась как-то ну очень простой. Граф пришёл в голову сразу, отсчёт от центра тоже.

Вставлю свои 5 копеек) Мне лично удобнее всего переключать по Win + пробел. Хоткей работает в Винде начиная с 8, на Маках и по умолчанию на линуксе. Удобно.

Это чистое имхо, сильно серьёзно не воспринимайте.


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


К чему это я, да к тому что тут причина и следствие вывернуты мне кажется, не бизнесу выгоден медленный код, а люди которые могут написать быстрый в этот бизннс не пошли. По скорост разработки, разница минимальная, что 10 уровней фора написать, что пару коллекций грамотно использовать.

Для написания. В цепочках вызовов легко сделать что-то не так (прочитать весь файл целиком например), забыть обработчик исключений (привет реактивная Java, собраться соберётся, но упадёт потом если что), или просто перепутать функцию (использовать flatMap без побочных эффектов, забыть dispose сделать и так далее). Так же императивный стиль просто физически не даст сделать вложенность операций на 30 (в функциональном стиле занимало 10 полных строк).


Все эти примеры я встречал на одном проекте, после этого я понимаю что правильно использовать функциональный стиль сложнее чем писать императивно.


Ну и в целом, первый код понятен любому джуну, если что-то пойдёт не так — есть отладчик. А в функциональном стиле отладчик особо не поможет, джун пойдёт читать документации об потоках и застрянет надолго.


Это моё имхо, я могу и так и так, но предпочитаю писать проще, особенно если поддерживать не мне.

Николай Ромашкин, Бета-тестеры, примерно 2005 год.

— Вот я и говорю, — подавленно говорил он слегка заплетающимся языком. — Применение всех этих стандартных библиотек скотинит и развращает программиста. Низводит его до состояния быдла. Животного. Собаки Павлова. Загорелась зеленая лампочка — вызывай эту функцию. Загорелась синяя — другую. А почему?! П-почему лампочки загораются?!


Последнюю фразу Ксенобайт произнес с тоскливым надрывом. Гордо выпрямившись, ударил себя кулаком в грудь, потом снова сник.


— Н-никто не помнит. Никто не помнит, откуда там эти лампочки и почему горят. Ты меня понимаешь? Понимаешь, что я чувствую, когда смотрю на эти лампочки?


Собственно ничего не меняется)


P.S. Считаю вариант с циклом более читаемым и надёжным. Вот только константы -1 и 10 стоило бы так и назвать. Тем более что сравнение некорректно, можно было и императивно использовать BufferedReader.readline() (если это конечно Java).

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность