Data.table: функции качения, агрегаты качения, скользящее окно, скользящее среднее

Предлагаемая реализация rollmean , упрощенная.

x = data.table(v1=1:5, v2=1:5)
k = c(2, 3)

i - single column
j - single window
m - int referring to single row
w - current row's sum of rolling window
r - answer for each i, j



md5-be70673ef4a3bb883d4f334bd8fadec9



for i in x
  for j in k
  r = NA_real_
  w = 0
    for m in 1:length(i)
      w = w + i[m]
      w = w - i[m-j]
      r[m] = w / j

да, и многие другие свернутые функции следуют той же основной идее (включая
скользящее стандартное отклонение / любой ожидаемый момент и любая функция
как рулонный продукт, который использует обратимый * вместо + для агрегирования внутри
окно

Я всегда представлял себе функцию скользящего окна как группировку набора данных в несколько перекрывающихся групп (окон). Тогда API будет выглядеть примерно так:

DT[i, j,
   by = roll(width=5, align="center")]

Затем, если j содержит, скажем, mean(A) , мы можем внутренне заменить его на rollmean(A) - точно так же, как мы делаем сейчас с gmean() . Или j может содержать произвольно сложную функциональность (например, запускать регрессию для каждого окна), и в этом случае мы предоставим ему .SD data.table - точно так же, как мы делаем с группами Сейчас.

Таким образом, нет необходимости вводить 10+ новых функций, только одну. И он тоже чувствует себя data.table-y по духу.

да согласен

В сб, 21 апреля 2018 г., 15:38 Паша Стеценко [email protected]
написал:

Я всегда представлял себе функцию скользящего окна как группировку
набор данных в несколько перекрывающихся групп (окон). Тогда API будет выглядеть
что-то вроде этого:

DT [i, j,
by = roll (width = 5, align = "center")]

Тогда, если j содержит, скажем, mean (A), мы можем внутренне заменить его на
rollmean (A) - точно так же, как мы делаем сейчас с gmean (). Или я могу
содержат произвольно сложную функциональность (скажем, запустить регрессию для
каждое окно), и в этом случае мы предоставим ему таблицу данных .SD - именно
как мы поступаем с группами прямо сейчас.

Таким образом, нет необходимости вводить 10+ новых функций, только одну. И это
тоже чувствует data.table-y по духу.

-
Вы получили это, потому что прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/Rdatatable/data.table/issues/2778#issuecomment-383275134 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AHQQdbADiE4aAI1qPxPnFXUM5gR-0w2Tks5tquH8gaJpZM4TeTQf
.

@ st-pasha интересная идея, выглядит как data.table-y, но накладывает много ограничений и не совсем подходит для этой категории функций.

• как выполнить rollmean по группе

DT[, rollmean(V1, 3), by=V2]

• как рассчитать разные размеры окон для разных столбцов

DT[, .(rollmean(V1, 3), rollmean(V2, 100))]

• как рассчитать rollmean за пределами [.data.table поскольку теперь мы допускаем сдвиг

rollmean(rnorm(10), 3)

• как поддерживать такие запросы, как

DT[, .(rollmean(list(V1, V2), c(5, 20)), rollmean(list(V2, V3), c(10, 30)))]

• как вызвать mean и rollmean в одном вызове j

DT[, .(rollmean(V1, 3), mean(V1)), by=V2]

Обычно при использовании by мы агрегируем данные в меньшее количество строк, в то время как функции прокрутки всегда возвращают вектор той же длины в качестве входных данных. Эти типы функций в SQL имеют API в следующем стиле:

SELECT AVG(value) OVER (ROWS BETWEEN 99 PRECEDING AND CURRENT ROW)
FROM tablename;

Вы все еще можете комбинировать его с GROUP BY следующим образом:

SELECT AVG(value) OVER (ROWS BETWEEN 99 PRECEDING AND CURRENT ROW)
FROM tablename
GROUP BY group_columns;

Таким образом, в SQL эти функции остаются в SELECT что относится к j в DT.
В DT мы могли добиться того же с помощью:

DT[, rollmean(value, 100)]
DT[, rollmean(value, 100), group_columns]

Функции прокрутки входят в ту же категорию функций, что и shift которые также возвращают то же количество строк, что и при вводе.
Сдвиг в SQL выглядит так:

SELECT LAG(value, 1) OVER ()
FROM tablename;

mean и rollmean - это не просто разные функции, это разные категории функций. Одно предназначено для агрегирования по группам, другое - не для агрегирования. Это легко увидеть в SQL, где мы не используем GROUP BY для типа скользящих функций, но нам действительно нужно использовать GROUP BY для агрегатов, таких как mean (в конечном итоге получение суммы гранта при группировке статьи нет).
Я не вижу веских оснований пытаться применять те же правила оптимизации, что и мы для mean , особенно когда это действительно не подходит для использования, и все это просто ради данных. Table-y дух. Текущее предложение - это тоже дух data.table-y, его можно легко комбинировать с := , как и shift . Он просто добавляет набор новых функций, в настоящее время недоступных в data.table.

@jangorecki Спасибо, это все обоснованные соображения. Конечно, у разных людей разный опыт и разные взгляды на то, что следует считать «естественным».

Можно выполнить rollmean по группе: это всего лишь двухуровневая группировка: DT[, mean(V1), by=.(V2, roll(3))] . Однако я не вижу, как с моим синтаксисом сделать окна разных размеров в разных столбцах ...

Должен признаться, я никогда раньше не видел синтаксиса SQL для скользящих соединений. Интересно, что они используют стандартный агрегатор, такой как AVG но применяют к нему спецификацию окон. В документации по Transact-SQL есть несколько интересных идей, например, различие между логическим и физическим выбором строк. Они позволяют использовать разные операторы «OVER» для разных столбцов, однако во всех приведенных ими примерах одно и то же предложение OVER повторяется несколько раз. Таким образом, это предполагает, что этот вариант использования гораздо более распространен, и, следовательно, использование одной группы roll() приведет к меньшему повторению.

Кроме того, этот вопрос SO дает интересное понимание того, почему синтаксис OVER вообще был введен в SQL:

Вы можете использовать GROUP BY SalesOrderID. Разница в том, что с помощью GROUP BY вы можете иметь только агрегированные значения для столбцов, которые не включены в GROUP BY. Напротив, используя оконные агрегатные функции вместо GROUP BY, вы можете получать как агрегированные, так и не агрегированные значения. То есть, хотя вы не делаете этого в своем примере запроса, вы можете получить как отдельные значения OrderQty, так и их суммы, числа, средние значения и т. Д. По группам с одинаковыми идентификаторами SalesOrderID.

Таким образом, похоже, что синтаксис разработан для обхода ограничения стандартного SQL, в котором результаты группировки не могут быть объединены с неагрегированными значениями (т.е. выбор A и mean(A) в одном выражении). Однако data.table не имеет такого ограничения, поэтому у него больше свободы в выборе синтаксиса.

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

Функция «скользящего среднего» используется для сглаживания некоторых шумных входных сигналов. Скажем, если у вас есть наблюдения с течением времени, и вы хотите иметь некоторое понятие «среднего количества», которое, тем не менее, будет меняться со временем, хотя и очень медленно. В этом случае можно рассматривать «скользящее среднее за последние 100 наблюдений» или «скользящее среднее за все предыдущие наблюдения». Точно так же, если вы наблюдаете определенную величину в диапазоне входных данных, вы можете сгладить ее, применив «скользящее среднее более ± 50 наблюдений».

• Итак, первое расширение - посмотреть на «гладкие окна»: представьте себе среднее значение по прошлым наблюдениям, где чем дальше наблюдение в прошлом, тем меньше его вклад. Или среднее значение ближайших наблюдений по гауссовскому ядру.
• Во-вторых, адаптивные окна. Например, если у вас есть шумный вход, определенный в интервале [0, 1], то сглаживание его с использованием окна ± N дает смещенный результат около краев. Несмещенный оценщик адаптирует форму окна в зависимости от расстояния от края.
• Передискретизация сглаживания: ограничение на создание ровно столько наблюдений, сколько в исходных данных, является слишком ограничивающим. Если вы думаете о своих данных как о зашумленных наблюдениях некоторой базовой функции, то вполне разумно попросить вычислить сглаженные значения этой функции на сетке, которая является более грубой / более тонкой, чем исходный ввод. Или, возможно, исходные данные расположены неравномерно, и вы хотите преобразовать их в обычную сетку.
• Складной нож: для каждого наблюдения вы хотите вычислить среднее значение / регрессию по всем наблюдениям, кроме текущего.
• K-кратное разбиение: просмотр данных в виде нескольких групп, каждая из которых исключает только небольшую часть наблюдений.

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

Должен признаться, я никогда раньше не видел синтаксиса SQL для скользящих соединений.

Я предполагаю, что вы имеете в виду скользящие функции, проблема не имеет ничего общего с скользящими соединениями.

Они позволяют использовать разные операторы «OVER» для разных столбцов, однако во всех приведенных ими примерах одно и то же предложение OVER повторяется несколько раз. Таким образом, это предполагает, что этот вариант использования гораздо более распространен, и, следовательно, использование одной группы roll () приведет к меньшему повторению.

Это просто вопрос использования, если вы вызываете один и тот же OVER () много раз, вы можете найти более эффективным использование GROUP BY , создание таблицы поиска и повторное использование в других запросах. Какие бы примеры ни были, повторение функции OVER () необходимо для сохранения характеристики местоположения для каждой предоставленной меры. Мои примеры использования из хранилищ данных не так просты, как примеры из документации Microsoft.

Напротив, используя оконные агрегатные функции вместо GROUP BY, вы можете получать как агрегированные, так и не агрегированные значения.

В data.table мы выполняем := и by в одном запросе для достижения этой цели.

Таким образом, похоже, что синтаксис разработан для обхода ограничения стандартного SQL, в котором результаты группировки не могут быть объединены с неагрегированными значениями (т. Е. Выбор как A, так и среднего (A) в одном выражении). Однако data.table не имеет такого ограничения, поэтому у него больше свободы в выборе синтаксиса.

Это не большое ограничение SQL, а просто дизайн GROUP BY, который будет агрегироваться так же, как агрегатируется наш by . Новый API требовался для охвата новых функций окна. Группировка для оконной функции SQL может быть обеспечена для каждого вызова функции с помощью FUN() OVER (PARTITION BY ...) где _partition by_ похожа на локальную группировку для одной меры. Поэтому для достижения гибкости SQL нам нужно будет использовать j = mean(V1, roll=5) или j = over(mean(V1), roll=5) сохраняя этот API в j . Тем не менее, этот подход не позволит поддерживать все варианты использования, упомянутые выше.

вы можете сгладить это, применив «скользящее среднее более ± 50 наблюдений».

Для этого используется аргумент align .

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

Существует множество вариантов (практически неограниченное количество) скользящих средних, наиболее распространенной функцией окна сглаживания (кроме скользящей средней / SMA) является экспоненциальная скользящая средняя (EMA). Что следует включить, а что нет, решить нетривиально, и на самом деле лучше всего принять это решение в соответствии с запросами функций, которые будут исходить от пользователей, до сих пор ничего подобного не запрашивалось.

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

Конечно, могут, но если вы посмотрите на SO и проблемы, созданные в нашем репо, вы увидите, что эти несколько скользящих функций здесь отвечают за 95 +% запросов от пользователей. Я счастлив работать над EMA и другими MA (хотя я не уверен, что data.table - лучшее место для них), но как отдельный вопрос. Некоторые пользователи, в том числе я, уже 4 года ждут простой скользящей средней в таблице data.table.

Вот мой вывод с точки зрения статистики

Моя точка зрения исходит из хранилищ данных (где я использовал оконную функцию, по крайней мере, один раз в неделю) и анализа ценовых тенденций (где я использовал десятки различных скользящих средних).

rollmean draft помещается в ветку roll . Я обнаружил, что большинство других пакетов, реализующих скользящее среднее, не могут хорошо справляться с na.rm=FALSE и NA, присутствующими во входных данных. Эта реализация последовательно обрабатывает NA до mean , что накладывает дополнительные накладные расходы из-за вызовов ISNAN . Мы могли бы позволить API использовать более быструю, но менее безопасную версию, если пользователь уверен, что на входе нет NA.
PR находится в # 2795

@mattdowle отвечает на вопросы PR

Почему мы делаем это внутри data.table? Почему мы интегрируем его вместо того, чтобы вносить вклад в существующие пакеты и использовать их из data.table?

1. Было создано 3 разных вопроса, запрашивающих эту функциональность в data.table. Также несколько вопросов SO помечены как data.table. Пользователи ожидают, что это будет в области data.table.
2. data.table идеально подходит для данных временных рядов, а скользящие агрегаты - довольно полезная статистика.

я предполагаю, что все сводится к синтаксису (функции, которые возможны или удобны только в том случае, если они встроены в data.table; например, внутри [...] и оптимизированы) и встраиванию внутренних компонентов data.table в функцию прокрутки на уровне C; например, froll * должен знать и использовать индексы и ключ data.table. Если да, то по этому поводу необходимо больше подробностей; например, простой короткий пример.

Лично для меня речь идет о скорости и отсутствии цепочки зависимостей, что в настоящее время непросто.
Ключ / индексы могут быть полезны для frollmin / frollmax, но маловероятно, что пользователь создаст индекс для переменной меры. Маловероятно, что пользователь сделает индекс по переменной меры, к тому же мы еще не сделали эту оптимизацию для min / max. Я не вижу особого смысла в оптимизации GForce, потому что выделенная память не освобождается после вызова roll *, а возвращается в качестве ответа (в отличие от непереключающегося среднего, суммы и т. Д.).

Если нет убедительных аргументов в пользу интеграции, то вместо этого мы должны внести свой вклад в другие пакеты.

Я перечислил некоторые из них выше, если вы не уверены, я рекомендую вам задать вопрос пользователям data.table, спросить в твиттере и т. Д., Чтобы проверить ответ. Эта функция давно была востребована многими пользователями. Если ответ не убедит вас, вы можете закрыть эту проблему.

Я обнаружил, что sparklyr может очень хорошо поддерживать функции прокрутки в очень крупномасштабном наборе данных.

@harryprince мог бы
По "Оконным функциям" виньетка dplyr

Прокатные агрегаты работают в окне фиксированной ширины. Вы не найдете их в базовом R или dplyr, но есть много реализаций в других пакетах, таких как RcppRoll.

AFAIU вы используете собственный Spark API через sparklyr, для которого интерфейс dplyr не реализован, правильно?

Эта проблема касается скользящих агрегатов, другие «типы» оконных функций уже давно находятся в data.table .

Также было бы полезно предоставить некоторый пример, чтобы мы могли сравнить (в памяти) производительность с sparklyr / SparkR .

Мне просто пришло в голову, что этот вопрос:

как рассчитать разные размеры окон для разных столбцов?

на самом деле имеет более широкую сферу применения и не применяется только к функциям прокрутки.

Например, кажется вполне разумным спросить, как выбрать среднюю цену продукта по дате, затем по неделям, а затем, возможно, по неделям + категории - и все это в рамках одного запроса. Если мы когда-нибудь реализуем такую ​​функциональность, естественным синтаксисом для нее мог бы быть

DT[, .( mean(price, by=date), 
        mean(price, by=week), 
        mean(price, by=c(week, category)) )]

Теперь, если бы эта функциональность уже была реализована, то это был бы простой переход к скользящим средствам:

DT[, .( mean(price, roll=5), 
        mean(price, roll=20), 
        mean(price, roll=100) )]

Я не говорю, что это однозначно лучше, чем rollmean(price, 5) - просто добавляю некоторые альтернативы для рассмотрения ...

@ st-pasha

как выбрать среднюю цену продукта по дате, затем по неделям, а затем, возможно, по неделям + категории - все в рамках одного запроса.

AFAIU это уже возможно с использованием ?groupingsets , но еще не подключено к [.data.table .

@jangorecki , @ st-pasha и Ко - Спасибо за всю вашу работу! Мне любопытно, почему частичная поддержка окон была удалена из области видимости, есть ли потенциал для этой функции, чтобы вернуть ее в дорожную карту? Иногда мне пригодится и восполнит пробел в функциональности, который, насколько мне известно, не был восполнен ни zoo ни RcppRoll .

Этот вопрос о переполнении стека является хорошим примером скользящего приложения, которому может быть полезен аргумент partial = TRUE .

@msummersgill Спасибо за отзыв. В первом посте я явно связал commit sha, где можно найти код функции частичного окна. Реализация, которая там есть, была позже удалена, чтобы упростить код. Это также требовало небольших затрат на производительность, даже если эта функция не использовалась. Эта функция может (и, вероятно, должна) быть реализована другим способом: сначала заполнить как есть, а затем просто заполнить недостающее частичное окно, используя дополнительный цикл 1:window_size . Таким образом, накладные расходы этой функции заметны только тогда, когда вы ее используете. Тем не менее, мы предоставляем эту функциональность через аргумент adaptive , где функция partial - это просто частный случай скользящего среднего значения adaptive . В руководстве по partial с помощью adaptive . Вставляем сюда:

d = as.data.table(list(1:6/2, 3:8/4))
an = function(n, len) c(seq.int(n), rep(n, len-n))
n = an(3, nrow(d))
frollmean(d, n, adaptive=TRUE)

Конечно, это будет не так эффективно, как неадаптивная функция прокрутки, использующая дополнительный цикл для заполнения только частичного окна.
AFAIK zoo имеет функцию partial .

Есть ли у вас планы добавления функций скользящей регрессии в data.table?

@waynelapierre, если на это будет спрос, то да. У тебя есть мой +1

спасибо, это здорово. Только один вопрос. Я вижу только простые скользящие агрегаты, такие как скользящее среднее или скользящая медиана. Вы также реализуете более совершенные функции прокрутки, такие как прокрутка кадров данных DT? Скажем, создайте скользящее ОУ, используя последние 10 наблюдений, и запустите на нем регрессию lm .

Спасибо!

@randomgambit Я бы сказал, что это выходит за рамки, если на это не будет большого спроса. Было бы не очень сложно сделать это быстрее, чем базовый R / zoo, просто обработав вложенный цикл в C. Но мы должны попытаться реализовать его с использованием «интерактивного» алгоритма, чтобы избежать вложенного цикла. Это более сложно, и в конечном итоге мы могли бы сделать это для любой статистики, поэтому в какой-то момент мы должны отключить эту статистику.

@jangorecki интересно спасибо. Это означает, что я буду продолжать использовать tsibble для встраивания ... DATA.TABLES в tibble ! взорванный ум: D

Пытался использовать frollmean для вычисления непараметрической «логистической кривой», которая показывает P[y | x] для двоичного y с использованием ближайших соседей x . Был удивлен, что y сохраненное как logical не было автоматически преобразовано в integer :

DT = data.table(x = rnorm(1000), y = runif(1000) > .5)
DT[order(x), .(x, p_y = frollmean(y, 50L))]

Ошибка в игре (fun = "mean", x = x, n = n, fill = fill, algo = algo, align = align,:
x должен иметь числовой тип

Пример того, как векторизованные аргументы x / n могут повлиять на производительность.
https://github.com/AdrianAntico/RemixAutoML/commit/d8370712591323be01d0c66f34a70040e2867636#r34784427
меньше циклов, код легче читается, намного быстрее (ускорение в 10–36 раз).

frollapply готов: https://github.com/Rdatatable/data.table/pull/3600

    ### fun             mean     sum  median
    # rollfun          8.815   5.151  60.175
    # zoo::rollapply  34.373  27.837  88.552
    # zoo::roll[fun]   0.215   0.185      NA
    # frollapply       5.404   1.419  56.475
    # froll[fun]       0.003   0.002      NA

привет, ребята, будет ли FUN (определяемый пользователем), переданный в frollapply, будет изменен, чтобы вернуть объект R или data.frame (data.table), x, переданный в frollapply, может быть data.table символа, не приведенного к числовому, тогда FUN может сделать на label и frollapply возвращают список? затем мы можем выполнять скользящую регрессию или скользящее тестирование, как тестирование Бенфорда или сводку на этикетках.

Всегда полезно привести воспроизводимый пример. Чтобы прояснить ... в таком сценарии вы хотели бы frollapply(dt, 3, FUN) вернуть список длиной nrow(dt) где каждый элемент списка будет data.table возвращенный FUN(dt[window]) ?
frollapply(x=dt, n=3, fun=FUN)[[3]] равно FUN(dt[1:3])
frollapply(x=dt, n=3, FUN=FUN)[[4]] равно FUN(dt[2:4])
это верно? @ jerryfuyu0104

В настоящее время мы поддерживаем несколько столбцов, передаваемых в первый аргумент, но обрабатываем их отдельно, в цикле. Вероятно, нам понадобится дополнительный аргумент multi.var=FALSE , при значении true он не будет перебирать x (как сейчас: list(FUN(x[[1]]),FUN(x[[2]])) ), но передаст все столбцы FUN(x) .

какое-нибудь обновление для этого?

Я поддерживаю предыдущую просьбу.

Кроме того, можно ли было бы поддержать «частичный» аргумент, чтобы разрешить частичные окна?

@eliocamp не могли бы вы рассказать, что такое окно partial ?

@eliocamp можно было бы поддерживать «частичный» аргумент. Возможно, вы это уже знаете, но поддержка этой функции уже есть, с использованием аргумента adaptive=TRUE , см. Примеры для подробностей.

Это означало бы вычисление функции от начала до конца, а не формирование точки полуокна.
Например, для скользящего среднего ширины 11 первый возвращенный элемент будет средним значением элементов с 1 по 6. Второй - средним значением с 1-го по 7-й и так далее.

@jangorecki о, спасибо, я этого не знал! Я проверю это.

Согласитесь, нам нужны частичные аргументы не только по удобству, но и по скорости. adaptive=TRUE добавляет накладные расходы.
И да, нам также нужна скользящая регрессия, поэтому мы предоставляем несколько переменных и запускаем их сразу, а не каждую отдельно.
О статусе этих обновлений нет.

Я хотел бы помочь, но мои навыки C ++ совершенно отсутствуют. : sweat: Как думаешь, он подойдет для полных новичков?

Мы кодируем не на C ++, а на C. Да, это хорошее место для начала. Я сделал именно это на frollmean.

Я смотрю на код, и он кажется устрашающим. Но сообщу в любом случае.

Но теперь еще одна просьба: frollmean (.SD) должен сохранять имена. В более общем смысле, froll * должен сохранять имена, если входные данные представляют собой список с именами.

Как частый пользователь data.table, я считаю чрезвычайно полезным иметь функции, учитывающие время, как те, которые в настоящее время предлагаются в пакете tsibble . К сожалению, этот пакет разработан около dplyr . Интересно, возможна ли реализация data.table. Оконные функции, предлагаемые в этом выпуске, являются подмножеством этих функций.

@ywhcuhk Спасибо за отзыв, на самом деле я думал, что эта проблема уже рулоном упаковки, который работает очень быстро. Что касается других функций, я предлагаю создать новую задачу для каждой интересующей вас функции, поэтому обсуждение того, хотим ли мы реализовать / поддерживать, можно решить для каждой отдельно. Просто взглянув на readme tstibble, я не вижу ничего нового, что он предлагает ...
Его название - «Tidy Temporal Data Frames», но, похоже, он даже не предлагает временных соединений.

Спасибо @jangorecki за ответ. Возможно, это проблема, зависящая от контекста. Структура данных, с которой я работаю чаще всего, известна как «данные панели» с идентификатором и временем. Если программа "осведомлена" об этой функции данных, многие операции, особенно операции с временными рядами, будут выполнены очень легко. Для тех, кто знает STATA, это операции, основанные на tsset и xtset , такие как опережение, отставание, заполнение пробелов и т. Д. Я думаю, что "индекс" в таблице data.table можно улучшить каким-то образом разрешить такие операции.

Конечно, эти операции можно выполнять в функциях data.table, таких как shift и by . Я просто подумал, что index в таблице data.table имеет большой потенциал для изучения. Я согласен, это должно относиться к другому вопросу. Но я не знаю, как переместить его, не теряя при этом обсуждений ...