Применение Data Mining MS SQL 2005 для трейдинга - страница 3

Новый комментарий
 
На этой неделе начинаю подобную масштабную работу
 
Клиента внешнего писать под это будете? Я перебирать параметры вручную при создании модели уже упарился в SQL Management Console, хочу сделать клиента под Analyses базу и автоперебор.
Таймфреймы какие пробовали грузить в модель? Я GBPUSD, EURUSD на D1, H4, H1.
 
chv:
Клиента внешнего писать под это будете? Я перебирать параметры вручную при создании модели уже упарился в SQL Management Console, хочу сделать клиента под Analyses базу и автоперебор.
Таймфреймы какие пробовали грузить в модель? Я GBPUSD, EURUSD на D1, H4, H1.
Именно так. Основное не клиент, а то что перебирать
 
Понятно, что перебирать параметры создания data mining модели, от этого будет зависеть её выдаваемый прогноз. Клиент просто средство для ускорения и автоматизации этого процесса.
 
chv:
Понятно, что перебирать параметры создания data mining модели, от этого будет зависеть её выдаваемый прогноз. Клиент просто средство для ускорения и автоматизации этого процесса.
Угу
 
Парни а резултат есть какой то или все заглохло из-за неперспективности?
 
Приветствую! С SQL и базами знаком неплохо, тут вообще проблема то в другом - уважаемый Рош даже публиковал гдет библиотеки функций, фактически аналог для некоторых расчетов SQL и мног всего пробегало на MQL, НО самое важное - то же что и с нейросетями - но в том случае чем качать, а тут в общем то как выделить область статобработки и каким образом менять ее - вот в чем вопрос, то есть номинально наличие данного инструмента с точки зрения решения задачи прогнозирования ничего нового не дает. То есть если номинально я мог и вчера и позовчера связать через вызовы прогу с Метатрейдера да хоть с Клиперовскими библиотеками и таблицами, то я бы имел практически тож самое, то есть это не вдруг решение, а просто новые уровень возможностей и не более. И немного философии - сам SQL обрабатывает построчно либо селективно, но более важно например для поиска паттернов, как закономенрностей осуществлять процедурную обработку по некоему ключу из строк, анализируя уже последовательности, в противном случае мы не можем смоделироваать конечную структуру БД и вынужденны будем столкнутся с проблемой, что даже и самой мощной СУБД при постоянном росте объемов базы нам недостаточно, выход из этой ситуации прост - использовать собственные процедурные обработки по ключам в ограниченной таблице, например просто закаченной из коллекции баров таймфрейма или нескольких, но тогда принципиальное преимущество SQL отсутствует уже при сравнении с процедурной обработкой массивов средствами MQL. То есть это может быть удобством при реализации некоего алгоритма, где преимущества от использования SQL будут реализовываться, но не является решением как таковым.
 
dasmen:
Приветствую! С SQL и базами знаком неплохо, тут вообще проблема то в другом - уважаемый Рош даже публиковал гдет библиотеки функций, фактически аналог для некоторых расчетов SQL и мног всего пробегало на MQL, НО самое важное - то же что и с нейросетями - но в том случае чем качать, а тут в общем то как выделить область статобработки и каким образом менять ее - вот в чем вопрос, то есть номинально наличие данного инструмента с точки зрения решения задачи прогнозирования ничего нового не дает. То есть если номинально я мог и вчера и позовчера связать через вызовы прогу с Метатрейдера да хоть с Клиперовскими библиотеками и таблицами, то я бы имел практически тож самое, то есть это не вдруг решение, а просто новые уровень возможностей и не более. И немного философии - сам SQL обрабатывает построчно либо селективно, но более важно например для поиска паттернов, как закономенрностей осуществлять процедурную обработку по некоему ключу из строк, анализируя уже последовательности, в противном случае мы не можем смоделироваать конечную структуру БД и вынужденны будем столкнутся с проблемой, что даже и самой мощной СУБД при постоянном росте объемов базы нам недостаточно, выход из этой ситуации прост - использовать собственные процедурные обработки по ключам в ограниченной таблице, например просто закаченной из коллекции баров таймфрейма или нескольких, но тогда принципиальное преимущество SQL отсутствует уже при сравнении с процедурной обработкой массивов средствами MQL. То есть это может быть удобством при реализации некоего алгоритма, где преимущества от использования SQL будут реализовываться, но не является решением как таковым.
А ты вот попробуй этим скриптом че-нить прочти из базы.. Мы тут всемером уже 2 недели на это убили.
 
А смысл делать это? SQL - Это СУБД, а не скрипт и конвертить в имеено в базу надо, хотя можно и просто связанные таблицы использовать. Если конвертануть в SQL просто таблицу котировок - это ничо не даст на самом деле, ну кластерезируется в Data Mining, но к примеру связать это в модель, пусть даже посредством кластеризации и сегментации не выдет - это не то же самое, что выделение сегментных групп из покупателей - в том случае просто проход по столбцам проходит и выделение неких совкупностей осуществляется. Нам же интересно куда дальше цена двинет, а вот это уже задача для выделения совкупностей по строкам, а не по столбцам - именно из этого и можно выделить паттерные комбинации для рынка - но эти задачи ни SQL ни Data Mining не помогут решить. Вот такие же задачи при обработке данных всегда и возникают при проектеровке промышленных баз данных - этого мы уже прям там и нагляделись и технологии OLAP ничем не помогат, а клиенты недоумевают - чего програмер урыт так в делах, когда Макрософт такие вот готовые решения ну просто на все имеет - обычная такая модель утомительных непоняток, так и хочется сказать громко - Здравствуйте обычные люди!))
123
Новый комментарий
Причина обращения: