Совместимость есть, версии компиляторов самые свежие стабильные релизы (апрель-май 2017 года). Процессоры разные и видимо пока для них стабильные версии компиляторов немного разнятся.
Насчет тензорных операций — учтем в следующем гайде по оптимизации, там много интересного о чем можно написать ввиду принципиально разных архитектур, а вот насчет биткоинов точно не к нам.
Вот в этой статье мы приводили некоторые сравнения Интела и Эльбрус-4С, когда займемся оптимизацией для 8С, напишем про него. Наша компания создаёт системы машинного зрения и распознавания которые могут быстро и качественно работать на Эльбрусах, Интеллах, АРМах и даже SPARCах.
Тут не ошибки, на момент тестирования это были стабильные версии, харакетристики процессора — http://mcst.ru/vosmiyadernyj-mikroprocessor-s-arkhitekturoj-elbrus
Мы предоставляем различные варианты лицензий и ценовых политик в зависимости от ваших предпочтений. Пожалуйста, напишите нам на sales@smartengines.biz или позвоните по телефону +7 (495) 649 82 60 — мы будем рады проконсультировать вас по любым вопросам, связанным с нашими продуктами.
Библиотека распознавания документов (и паспорта РФ в том числе) — наш коммерческий продукт, который мы распространяем в виде SDK для различных платформ. Независимый сервис/API для сегментации строк документов мы делать не планировали, а про API для распознавания строк мы думаем.
Мы распознаем документы и в зонах визуального контроля выделяем фото, если оно есть, функцию чтения чипа документов по NFC для телефонов на Android добавим после MWC, после распознавания это уже техническая работа.
Для расшифровки данных чипа необходимо считать или ввести руками данные содержащиеся в машиночитаемой строке (MRZ) или в зоне визуального контроля (VIZ), иначе было бы возможно дистанционно считать персональные данные. Кроме того, документов с чипом не так уж и много, например, в паспорте РФ и правах их нет.
Например, панорамирование позволяет снимать длинные чеки из магазина и получать качественное изображение, которое потом нормально распознается, а голограммы нужны в системах самообслуживания банков и других финтехов, что позволит им проверять подлинность документов на мобильных устройствах.
PS ошибки поправили, спасибо!
1) Мы не пользуемся словарями и не разбираем слова, частично потребность в этом покрывается масками * и? в ядрах ключевых слов. Это обусловлено сильной ограниченностью корпуса слов, используемых в деловых документов.
2) полностью на Ваш вопрос о «тамите» мы не ответим, было множество причин создать свой парсер. Однако легко понять, что сам парсер, описанный в статье, можно свести к проверке истинности ДНФ (или даже СДНФ) над ключевыми словами, т.е. что парсер очень прост, а причины относительного успеха его применения объясняются технологией подготовки правил, адекватных встречающимся деловым документам.
3) Ждём Вашу статью!
«0.01 — это немало, однако, это характеристика результата, основанного на описанном простом алгоритме классификации и на несовершенном OCR Tesseract. Применение более совершенного движка распознавания например, указанного Вами, позволит уменьшить эту характеристику.
У разных компиляторов различный набор настроек оптимизации и эти настройки могут быть по-разному реализованы, поэтому выставить полностью идентичный набор параметров затруднительно. Так, дефолтные значения флагов lcc предполагают довольно сильные ограничения floating-point оптимизаций. Флаг -ffast-math (отличается от -ffast-math в gcc) включает некоторые оптимизации, например, подстановку операций вместо вызова библиотечных функций. И только с флагами -ffast и -ffast-math задействуется полный набор floating-point оптимизаций, которые могут приводить к значительным изменениям результатов вычислений.
В данных примерах для MSVC были использованы fp:/precise (не полностью соответствующий -ffast-math, но также дающий некоторые оптимизации floating-point арифметики), общий уровень оптимизации /O2 (максимизирует скорость работы) и включено использование интринсиков. Таким образом, мы постарались достичь максимального соответствия в параметрах оптимизации компиляторов.
PS ошибки поправили, спасибо!
2) полностью на Ваш вопрос о «тамите» мы не ответим, было множество причин создать свой парсер. Однако легко понять, что сам парсер, описанный в статье, можно свести к проверке истинности ДНФ (или даже СДНФ) над ключевыми словами, т.е. что парсер очень прост, а причины относительного успеха его применения объясняются технологией подготовки правил, адекватных встречающимся деловым документам.
3) Ждём Вашу статью!
В данных примерах для MSVC были использованы fp:/precise (не полностью соответствующий -ffast-math, но также дающий некоторые оптимизации floating-point арифметики), общий уровень оптимизации /O2 (максимизирует скорость работы) и включено использование интринсиков. Таким образом, мы постарались достичь максимального соответствия в параметрах оптимизации компиляторов.