Регулярные выражения в Python от простого к сложному

Мега-Учебник Flask, Часть XII: Даты и время (издание 2018)

Miguel Grinberg

Туда Сюда

Это двенадцатая часть серии Мега-Учебник Flask, в которой я расскажу вам, как работать с датой и временем таким образом, что бы пользователи, не зависели от того, в каком часовом поясе они находятся.

Привет, Хабр! Этой статьёй я открываю цикл материалов, посвящённых работе с большими данными. Зачем? Хочется сохранить накопленный опыт, свой и команды, так скажем, в энциклопедическом формате – наверняка кому-то он будет полезен.

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

Начинать надо от простого к сложному, поэтому первая статья – о принципах работы с большими данными и парадигме MapReduce.

Является продолжением предыдущих публикаций.

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

Сама постановка задачи предельно проста: обеспечить графический интерфейс для рисования разнообразных графических представлений по произвольным табличным данным. Классическое решение представляет собой две связанные сущности:

• интерфейс с большим-большим количеством менюшек и кнопочек, с множественными закулисными IF для управления взаимными состояниями этих элементов;
• «гибкий плоттер» с большим количеством вложенных IF для отрисовки графиков в соотвествии со скормленным данными и положением кнопочек-ползунков, выставленных в UI.

С одной стороны делать «Yet Another Tableau» совершенно неинтересно. С другой стороны, постановка в стиле «сделать так, чтобы все было, но ничего не надо делать» — типичная задача для ТРИЗ.

В целом, после непродолжительных размышений было выработано решение, которое почти удовлетворяет последней постановке. Само Shiny приложение пока под NDA, свободно публикуемый прототип приведен на картинке.

Две ключевых идеи по упрощению задачи следующие (ничего нового, все уже придумано до нас):

1. вместо статически заданного UI переходим к динамически генерируемому;
2. используем интерпретатор R не только для исходного кода, но и внутри самого кода.

Идея 1. Динамический web-интерфейс

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

Сделаем по-другому. Вместо UI элементов со сложным поведением раскидываем с помощью uiOutput placeholder-ы, в которые динамически рассчитываем и генерируем с помощью shiny::renderUI представление этого элемента. Все внешние параметры, требуемые для генерации элемента, трактуем как реактивные элементы (reactive). При этом все такие интерактивные элементы выступают в качестве «автономных агентов», которые смотрят на окружение и подстраиваются под него. Пользователь изменил состояние одного элемента — все зависимые стали пересчитывать по очереди свое состояние (мы явно не обрабатываем события, а используем реактивный подход shiny). При изменении их состояния могут возникнуть новые индуцированные изменения. И так, пока все не стабилизируется.

  observeEvent(input$gen_plot, { # код демонстрирует принцип

    escname <- function(x){
      # имена колонок надо закавычить
      # .....
    }

    point_code <- ""
    if(input$shape_type!="__NO_MAPPING__") {
      aes <- c("shape"=escname(input$aes_shape_col), "color"=escname(input$aes_color_col))
      point_code <- buildPointCode(fixed=c("shape"=input$shape_type, "color"=glue("'{input$plot_color}'")), aes=aes)
    }

    line_code <- ""
    if(input$line_type!="__NO_MAPPING__") {
      aes <- c("linetype"=escname(input$aes_linetype_col), "color"=escname(input$aes_color_col))
      line_code <- buildLineCode(fixed=c("linetype"=input$line_type, "color"=glue("'{input$plot_color}'")), aes=aes)
    }

    gcode <- glue("ggplot(data_df(), aes(x=`{input$x_axis_value}`, y=`{input$y_axis_value}`))\\
                  {point_code} {line_code} + xlab('{input$x_axis_label}')") %>%
      style_text(scope="spaces")

    plot_Rcode(gcode)
  })  

На днях мне пришла в голову мысль, что было бы здорово написать простой Redis-подобный сервер баз данных. Хотя у меня значительный опыт работы с приложениями WSGI, сервер базы данных представил новый вызов и оказался хорошей практикой в процессе обучения работе с сокетами в Python. В этой статье расскажу, что я узнал в процессе исследования.

Обучение сверточной нейронной сети

Предисловие

Привет! В этой статье я хочу рассказать о проекте Akumuli, специализированной базе данных для сбора и хранения временных рядов. Я работаю над проектом уже больше четырех лет и достиг высокой стабильности, надежности, и возможно изобрел кое-что новое в этой области.

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

“Мне не нужна TSDB, у меня уже есть Х”

Х может быть чем угодно, начиная с SQL базы данных и заканчивая плоскими файлами. На самом деле все это действительно можно использовать для хранения временных рядов, с одной оговоркой — у вас мало данных. Если вы делаете 10 000 вставок в свою SQL базу данных — все будет хорошо какое-то время, потом таблица вырастет в размерах настолько, что время выполнения операций вставки увеличится.

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

Введение.

1. Введение, знакомство с tensorflow и базовыми алгоритмами (эта статья)
2. Первые нейронные сети
3. Свёрточные нейронные сети
4. Рекуррентные нейронные сети

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