Рубрика «сложность» - 2

Примечание. Сокращенный перевод, скорее пересказ своими словами.
UPD: как отметили в комментариях, примеры не идеальны. Автор не ищет лучшее решение задачи, его цель объяснить сложность алгоритмов «на пальцах».

Big O нотация нужна для описания сложности алгоритмов. Для этого используется понятие времени. Тема для многих пугающая, программисты избегающие разговоров о «времени порядка N» обычное дело.

Если вы способны оценить код в терминах Big O, скорее всего вас считают «умным парнем». И скорее всего вы пройдете ваше следующее собеседование. Вас не остановит вопрос можно ли уменьшить сложность какого-нибудь куска кода до n log n против n^2.

Структуры данных

Выбор структуры данных зависит от конкретной задачи: от вида данных и алгоритма их обработки. Разнообразные структуры данных (в .NET или Java или Elixir) создавались под определенные типы алгоритмов.

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

Здесь мы будем использовать только массивы чисел (прямо как на собеседовании). Примеры на JavaScript.
Читать полностью »

Простое объяснение простоты

image
КДПВ с областями, которые нам придется посетить, чтобы ответить на ГЛАВНЫЙ вопрос.

Предисловие

Я часто слышал совет: сделай проще.

А что значит простой? Когда мы говорим, что X — простой, каковы наши ожидания от X? Когда мы говорим, что X проще Y — как мы это оцениваем?

Что проще:
“Небольшое предложение из пяти слов” или слово “Дезоксирибонуклеиновый”?
“6*5” или “481”?

Или так:
У вас есть экран настроек. Пять пунктов из них относятся к графике, другие пять к уведомлениям. Надо ли вам создавать отдельные пункты «графика» и «уведомления» в основном меню? Или оставить все 10 пунктов на одном экране? Что будет проще для пользователя?
Читать полностью »

В недавней статье товарищ KvanTTT поднял вопрос:

Можете пояснить что вам не нравится в современной записи (математических положений и) формул и как ее можно улучшить?

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

Сразу скажу, материал холиварный. Местами слишком эмоциональный. Очень спорный. Слишком личный — часто основан на собственном опыте, небогатом, хоть и разнообразном. Пост касается школьных и университетских текстов учебников: у «профессиональной» литературы своя специфика, своя аудитория. Решения у проблемы в текущих реалиях нет. При этом, часть «моих» наблюдений задолго до меня высказывали такие авторитеты, как Кнут и Хэмминг; чуть менее популярные ребята даже запилили инструкцию "Как читать математику".

Проблемы современной записи математических текстов - 1 Итак, на мой взгляд, основные претензии не столько к записи формул, сколько к подаче материала. Причем, к подаче материала на практически всех уровнях образования, начиная со школы, и заканчивая передовой наукой. Начало текущей ситуации положил Евклид, заявивший про отсутствие царской дороги в математике. Царскую дорогу не проложили до сих пор. Евклид обходился, и мы сможем.
Читать полностью »

Секретные материалы

В 2014-м году я присоединился к небольшой команде в Schibsted Media Group в качестве 6-го специалиста по Data Science в этой компании. С тех пор я поработал над многими начинаниями в области Data Science в организации, в которой теперь таких уже 40 с лишним человек. В этом посте я расскажу о некоторых вещах, о которых узнал за последние четыре года, сперва как специалист, а затем как менеджер Data Science.

Этот пост следует примеру Robert Chang и его отличной статьи «Doing Data Science in Twitter», которую я нашел очень ценной, когда впервые прочитал ее в 2015-м году. Цель моего собственного вклада ― поведать настолько же полезные мысли специалистам и менеджерам Data Science по всему миру.

Я поделил пост на две части:

  • Часть I: Data Science в реальной жизни
  • Часть II: Управление командой Data Science

Читать полностью »

Это выступление состоялась 12 октября 2017 года на конференции Mirror Conf в Браге (Португалия) и ещё раз 9 февраля 2018 года на Awwwards Conference в Берлине.

Всё простое опять стало сложным - 1Этим летом после лекции на веб-конференции у меня состоялась увлекательная беседа с молодой студенткой, которая изучает цифровой дизайн. Было интересно сравнить наши карьерные пути. У меня пятнадцать лет опыта дизайна для веб-клиентов, у неё — один год, но каким-то образом мы оказались в одинаковой ситуации: мы наслаждались работой, но были совершенно дезориентированы и обескуражены быстро растущей сложностью всего вокруг. Что за ерунда произошла? (Конечно, это риторический вопрос).

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

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

image
Сможете поставить ещё шесть? А найти все решения?
(картинка из статьи)

Далее, к сожалению, произошла какая-то совершенно невразумительная история из цепочки вот таких вот превращений:

Стоит отметить, что пять наугад открытых ссылок на русском ещё меньше проясняли картину происходящего.

Я тут подумал — надо бы кому-то эту странную цепочку прервать и нормальным языком изложить суть событий.

О чём пойдёт речь:

Изменение восприятия сложности - 1
Хочу поделиться очень субъективными мыслями об изменении отношения к сложности за последние лет 50. Возможно, мои наблюдения касаются всей инженерии, но я поостерегусь и буду писать только про разработку ПО.

В последние годы мне стало казаться, что я упускаю что-то в методах разработки ПО. Весь мир радостно и с песней ускоряется, создаёт софт всё быстрее и быстрее, а я торможу. Чтобы не отставать, приходится преодолевать внутренний барьер неясной природы, действовать за границей которого выгодно но неприятно (мне). Не понятно почему выгодно. И не понятно почему неприятно.

Сегодня понял. В былые времена со сложностью боролись, теперь её игнорируют принимают. Переход между этими воззрениями был долгим и плавным, но уже можно видеть разительные отличия.

Я же учился в основном по материалам, созданным в прошлом веке, «древним манускриптам», да ещё и научную фантастику читал классическую, поэтому невольно стал приверженцем «старой школы». В чем же разница?
Читать полностью »

Здравствуйте! Насколько я следил за Хабром за все время его развития, он двигался в сторону все более и более высокопрофессиональных статей. Это, с одной стороны, хорошо. А с другой и не очень — потому что статьи для новичков в IT-сфере, на мой взгляд, тоже нужны, но если их публиковать, то трудно избежать обвинений в «разжевывании очевидного».

Поэтому у меня есть идея — а почему бы создателям Хабра не добавить в пост свойство «уровень сложности», показывающее, на какую аудиторию рассчитан пост. Тогда и новички, и профессионалы смогут публиковать материалы, рассчитанные на свою аудиторию, и смогут избежать взаимных обвинений в «неформате».
Читать полностью »

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

Позднее, конечно, я обнаружил, что по теме прогнозов написано несколько умных книжек, которые в сумме с некоторым опытом делают оценку задач хоть и неблагодарным, но и небезнадёжным занятием. Самым удобным способом, конечно, является оценка по аналогии: когда ты уже делал нечто подобное, ты довольно точно знаешь, каких усилий эта задача потребует. Но как быть в ситуации, когда опыта сравнительно немного или аналогии брать неоткуда, а оценить все же хочется?

В одной из команд, где я работал, мы придумали оригинальный метод для предварительной оценки задач. Метод синтезирует некоторые известные из литературы приёмы, но в приведённой форме, пожалуй, никем не описан. Концепция была следующей: объективность (связь с измеримыми показателями); интегрируемость с Agile; повторяемость; быстрота оценки (меньше 0.5% от объема задачи); доступность для начинающих разработчиков. Я буду рад обсудить нашу идею и не исключаю, что кому-то из Хабрааудитории она придётся по душе.
Читать полностью »

Заметки о SQL и реляционной алгебре - 1

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

Зачем это может быть нужно сегодня? Не только специалистам по анализу данных и администраторам баз данных приходится работать с данными, фактически мало кому не приходится что-то извлекать из (полу-)структурированных данных или трансформировать уже имеющиеся. Для того, чтобы иметь хорошее представление почему языки запросов устроены определенным образом и осознанно их использовать нужно разобраться с ядром, лежащим в основе. Об этом мы сегодня и поговорим.

Большую часть статьи составляют примеры с вкраплениями теории. В конце разделов приведены ссылки на дополнительные материалы, а для заинтересовавшихся и небольшая подборка литературы и курсов в конце.

Содержание

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js