Ну, человеку с ником GrowByLEDs свет понятно зачем нужен :-) Сельским хозяйством человек увлекается, ему спектр важен. А меня всегда интересовал вопрос энергопотерь в люминофоре. Зачем делают белый свет облучением люминофора? Ведь энергоэффективнее объединить RGB светодиоды? Для с\х, понятное дело, не годится, но для обычного освещения вполне.
Вот я тоже так понял, но как тогда понимать вот это: pjreddie.com/darknet/imagenet/#extraction
Йоло приводит список других моделей, которые могут быть воспроизведены в Йоло: Model Top-1 Top-5 Ops GPU CPU Cfg Weights
AlexNet 57.0 80.3 2.27 Bn 1.5 ms 0.3 s cfg 285 MB
Darknet Reference 61.1 83.0 0.81 Bn 1.5 ms 0.16 s cfg 28 MB
VGG-16 70.5 90.0 30.94 Bn 10.7 ms 4.9 s cfg 528 MB
Extraction 72.5 90.8 8.52 Bn 6.4 ms 0.95 s cfg 90 MB
Darknet19 72.9 91.2 5.58 Bn 6.0 ms 0.66 s cfg 80 MB
Darknet19 448x448 76.4 93.5 22.33 Bn 11.0 ms 2.8 s cfg 80 MB
Resnet 50 75.8 92.9 10 Bn 7.0 ms ?? s cfg 87 MB
Resnet 152 77.6 93.8 29.4 Bn ?? ms ?? s cfg 220 MB
Densenet 201 77.0 93.7 10.9 Bn ?? ms ?? s cfg 66 MB
Если Йоло сама по себе модель, то как она может выступать в роли других моделей (AlexNet, Extraction, Resnet 50, etc.) Если я в Йоло подгружу веса и конфигурацию AlexNet — что я получу в итоге — YOLO или AlexNet?
До конца так и не понял — Ёла это что? Это архитектура сети (типа AlexNet, LeNet, GoogleNet, ResNet?), которую можно воспроизвести на любом нейросетевом движке — хоть на Keras, хоть на Matlab? Или это алгоритм, который предобрабатывает изображение, прежде чем подать его на вход сети любой архитектуры?
Очень интересно. Тоже присматриваюсь к Ёлке. Отпугивало как раз то, что они базируются на этом странном фреймворке — DarkNet, который, похоже, остановился в своём развитии. То, что вы перенесли Ёлку на TensorFlow добавляет оптимизма — он точно будет развиваться.
Поигрался с моделью и подведу итог.
1. Спасибо за пример и библиотеку mpl_toolkits.basemap — буду пользоваться
2. По части упорядочения характеристик (feature engineering) решение спорное
— не убраны характеристики с единичной корреляцией, не несущие никакой дополнительной информации, лишь перегружающие и без того огромный набор данных
— оставлены многочисленные дублирующие признаки — если есть координаты, то все прочие географичесие признаки — адрес, код кантона (не понял что это в США), имя кантона, код города, имя города, штат, номер сайта, имя сайта… — не несут никакой дополнительной информации, лишь перегружают набор данных
— созданы избыточные временные признаки — времена года и сезон, которые также не несут никакой дополнительной информации, лишь перегружают набор данных
— выделение каждого года в отдельный признак (+26 измерений в и без того распухшем пространстве!) не только сделали набор данных крайне тяжёлым, но это ещё и вредно. Т.к. в этом случае модель не видит, что 2007 год следует за 2006, для неё это просто независимые координаты, т.е. утрачена часть информации, которая безусловно была бы использована моделью.
Для анализа данных, может, и полезно, но для вычислений вредно. Итого, исчерпав всю память мой ноут сдох, поэтому повторить эксперимент не удалось.
Ну и последнее, я бы использовал для данной задачи нейронную сеть, а не линейную регрессию.
Не претендую на истину в конечной инстанции, в порядке обмена мнениями.
Ещё раз спасибо.
Ещё не понял идею с добавлением аж пяти характеристик — сезон и 4 времени года. Не достаточно ли было просто ввести номер месяца?
Аналогично — зачем каждый год заводить как отдельную характеристику? Почему не ограничиться одной колонкой — номер_года?
Я имел в виду, что преобразование адреса в координатты могло бы дать дополнитеьную ценную характеристику, которая показала бы зависимости между близко лежащими точками замеров. А так этот int в общем-то смысловой нагрузки не несёт.
Ещё соображение — 2 параметра имеют корреляцию 1 (observation-count и observation_percent) — один можно выкинуть без потери качества, нет?
Кроме того, имея координаты можно за ненадобностью выкинуть несколько геогрфических характеристик — штат, город, сounty
data['county_name'] = data['county_name'].factorize()[0] — зачем дважды повторяется?
Как я понимаю, судя по вот этой строчке
data['address'] = data['address'].factorize()[0]
модель никак не учитывает географическую близость или удалённость измерений?
Аудиофилы, которые платят (и убеждают других платить) лошадиные бабки за провода из какой-то особой «бескислородной» меди и уверящие, что слышат разницу — не сильно отличаются от свидетелей частоты 432Гц
Йоло приводит список других моделей, которые могут быть воспроизведены в Йоло:
Model Top-1 Top-5 Ops GPU CPU Cfg WeightsAlexNet 57.0 80.3 2.27 Bn 1.5 ms 0.3 s cfg 285 MB
Darknet Reference 61.1 83.0 0.81 Bn 1.5 ms 0.16 s cfg 28 MB
VGG-16 70.5 90.0 30.94 Bn 10.7 ms 4.9 s cfg 528 MB
Extraction 72.5 90.8 8.52 Bn 6.4 ms 0.95 s cfg 90 MB
Darknet19 72.9 91.2 5.58 Bn 6.0 ms 0.66 s cfg 80 MB
Darknet19 448x448 76.4 93.5 22.33 Bn 11.0 ms 2.8 s cfg 80 MB
Resnet 50 75.8 92.9 10 Bn 7.0 ms ?? s cfg 87 MB
Resnet 152 77.6 93.8 29.4 Bn ?? ms ?? s cfg 220 MB
Densenet 201 77.0 93.7 10.9 Bn ?? ms ?? s cfg 66 MB
Если Йоло сама по себе модель, то как она может выступать в роли других моделей (AlexNet, Extraction, Resnet 50, etc.) Если я в Йоло подгружу веса и конфигурацию AlexNet — что я получу в итоге — YOLO или AlexNet?
Клещи — это не флора, это фауна!
1. Спасибо за пример и библиотеку mpl_toolkits.basemap — буду пользоваться
2. По части упорядочения характеристик (feature engineering) решение спорное
— не убраны характеристики с единичной корреляцией, не несущие никакой дополнительной информации, лишь перегружающие и без того огромный набор данных
— оставлены многочисленные дублирующие признаки — если есть координаты, то все прочие географичесие признаки — адрес, код кантона (не понял что это в США), имя кантона, код города, имя города, штат, номер сайта, имя сайта… — не несут никакой дополнительной информации, лишь перегружают набор данных
— созданы избыточные временные признаки — времена года и сезон, которые также не несут никакой дополнительной информации, лишь перегружают набор данных
— выделение каждого года в отдельный признак (+26 измерений в и без того распухшем пространстве!) не только сделали набор данных крайне тяжёлым, но это ещё и вредно. Т.к. в этом случае модель не видит, что 2007 год следует за 2006, для неё это просто независимые координаты, т.е. утрачена часть информации, которая безусловно была бы использована моделью.
Для анализа данных, может, и полезно, но для вычислений вредно. Итого, исчерпав всю память мой ноут сдох, поэтому повторить эксперимент не удалось.
Ну и последнее, я бы использовал для данной задачи нейронную сеть, а не линейную регрессию.
Не претендую на истину в конечной инстанции, в порядке обмена мнениями.
Ещё раз спасибо.
Аналогично — зачем каждый год заводить как отдельную характеристику? Почему не ограничиться одной колонкой — номер_года?
Ещё соображение — 2 параметра имеют корреляцию 1 (observation-count и observation_percent) — один можно выкинуть без потери качества, нет?
Кроме того, имея координаты можно за ненадобностью выкинуть несколько геогрфических характеристик — штат, город, сounty
Как я понимаю, судя по вот этой строчке
data['address'] = data['address'].factorize()[0]
модель никак не учитывает географическую близость или удалённость измерений?