Распознавание траекторий частиц в детекторе

[Petrovich]

Запущу на компьютере на работе. Пусть пашет. А сроки какие обозначены? Какие-то странные наименования колонок. Наверное зашифрованные. Есть ли там какие-нибудь требования к погрешности предсказания величине транзакции? Если я возьму и разделю весь диапазон изменения величины транзакции на 10 интервалов, этого будет достаточно? Или нужно делить
этот диапазон на 100 или на 1000 интервалов? Комп на работе уже 2 часа преобразует train.csv в нормальный Excel-файл и уже около 60% преобразовал. Наверное тестовая выборка будет распознаваться на одном компе лет 10, точнее скажу позже. Сложность этой задачи в огромном объеме исходных данных и гигантском объеме тестирующей выборки. В какой форме нужно представить на Каггл результат распознавания тестирующей выборки? Мне еще ни разу не встречалась задача, в которой было бы 4990 описательных шкал, а в этой задаче их именно столько. Сейчас запустил процесс ввода этой Excel-таблицы в систему Эйдос и она вылетела. Попробую ввести в систему Эйдос dbf-файл, сначала сделав его из csv не используя Excel. Так что это не такая уж и простая задача

Это типичная банковская задачка - угадать объем покупки клиента по его имени. Для этого дается зашифрованное имя, которое потом встретится в тестовом файле. Результат распознавания надо будет занести в колонку target. Я вообще не могу открыть ни одного из файлов. Перемудрили они там с этой задачей. Физике тоже придумали такую ерунду, какую могут придумать только физики.

[Petrovich]

Метрика для банковской задачи https://www.kaggle.com/c/santander-valu ... evaluation
В файлах на отправку первая колонка с именами, а вторая - с числами. Но имена даны в каком-то уродском формате. Открывается в Математике и выглядит так

[Eugene Lutsenko]

да, у них там имена полей не всегда корректные. В Excel пытался корректировать с помощью формул, но потом отказался от этого, т.к. если тренировочный файл еще хоть как-то открывается, то тестовый уже нет из-за некорректностей и огромного объема данных. Поэтому я стал делать программу преобразования CSV-DBF. Файлы открываются и просматриваются в AkelPad-4.9.8-bin-rus. Структуру файлов я понял, когда посмотрел на них. Там еще вместо запятых стоит десятичная точка, поэтому Excel не понимает, что это числа.

[Eugene Lutsenko]

Я сделаю в своем модуле чтение данных напрямую из CSV-файла. Промежуточный перевод в DBF для моего модуля не нужен.

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

[Eugene Lutsenko]

Но вы не пугайтесь - для вас на верхнем уровне всё будет выглядеть предельно просто - указываете источник данных ( например тот же CSV-файл), указываете приемник результатов (например ваши файлы prc1.txt, inf1.txt и т.д.) и запускаете операцию - обучение либо верификация.

Вот этого я и пугаюсь, так перед запуском твоего модуля, который является аналогом режима 3.5, еще нужно создать классификационные и описательные шкалы и градации и обучающую выборку. Все это делается например, в режиме 2.3.2.2. А сразу создать и верифицировать модели без этого невозможно. Я не понимаю, какие данные ты собираешься вводить в свой модуль из CSV-файлов

[Petrovich]

да, у них там имена полей не всегда корректные. В Excel пытался корректировать с помощью формул, но потом отказался от этого, т.к. если тренировочный файл еще хоть как-то открывается, то тестовый уже нет из-за некорректностей и огромного объема данных. Поэтому я стал делать программу преобразования CSV-DBF. Файлы открываются и просматриваются в AkelPad-4.9.8-bin-rus. Структуру файлов я понял, когда посмотрел на них. Там еще вместо запятых стоит десятичная точка, поэтому Excel не понимает, что это числа.

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

[Eugene Lutsenko]

Чтобы решить эту задачу в системе Эйдос, нужно сделать нечто похожее на описанное в статье:

Луценко Е.В. Интеллектуальное управление номенклатурой и объемами реализации в торговой фирме / Е.В. Луценко, В.Е. Коржаков, Д.С. Чичерин // Политематический сетевой электронный научный журнал Кубанского государственного аграрного университета (Научный журнал КубГАУ) [Электронный ресурс]. – Краснодар: КубГАУ, 2010. – №05(059). С. 111 – 139. – Шифр Информрегистра: 0421000012\0094, IDA [article ID]: 0591005008. – Режим доступа: http://ej.kubagro.ru/2010/05/pdf/08.pdf, 1,812 у.п.л.

[Eugene Lutsenko]

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

[Eugene Lutsenko]

В чем проблема с 4990 шкалами? Перед тем, как считать и верифицировать модели надо создать классификационные шкалы и градации и с помощью них закодировать исходные данные и сформировать таким образом обучающую выборку. Сразу в твоем модуле считать просто нечего. В системе Эйдос есть режим для этого: 2.3.2.2. Этот режим предполагает, что исходные данные находятся не в CSV-файле, а в базе данных или Excel-файле. В этом языке программирования, который я использую, в таблице базы данных не может быть больше 1500 (может чуть больше, 1700) полей (колонок). А в этой задаче их 4993. В этом и проблема. До сих пор я с этой проблемой ни разу не сталкивался. При этом ограничения на число признаков (градаций описательных шкал) в системе Эйдос практически нет, т.е. их могут быть сотни тысяч и может быть и миллионы. Но при этом есть ограничение на размер баз данных (не моделей, для которых я его снял): 2Гб. CSV-файлы с числом полей до 1500 я легко преобразую в dbf программно. Их и Excel воспримет и преобразует в xlsx. Система Эйдос в режиме 2.3.2.2 воспринимает и dbf, и xlsx.

[Eugene Lutsenko]

Если баз шкал и градаций и обучающей выборки не будет, то и ничего остального не будет. Надо их записывать.

Но у меня появилась другая мысль. Ты ведь создаешь dbf-файлы. ты делал программу DBFMake.exe.

Вопрос. Можешь ли ты создать dbf-файл с 5000 полей (колонок). Попробуй и пришли мне. А с 50000 или 500000 полей? Я тоже могу создавать dbf-файлы, как ты, не с помощью стандартных средств языка программирования, а прямо как текстовый файл с определенной структурой и расширением dbf