Есть такое веб приложение для записей, нацеленное на владение собственными данными и синхронизацию — Laverna. Так вот в нем для синхронизации можно пользоваться дропбоксом, у которого есть JS API для изменения файлов. Также laverna шифрует ключом на основе пароля все данные прямо в браузере, так что на сервере никто подменить данные не сможет не превратив их в тыкву. Посмотрите, может даст идеи для развития.
Спасибо за ответ. Но в таком случае, эта первичная фильтрация должна быть или очень мягкой, или знать что «и грянет гром википедиа» подходит под запрос «рассказ в котором раздавили бабочку» (а тут даже совпадающих слов нет), иначе до вашего алгоритма документ не дойдет. Если не секрет, то сколько документов в среднем доходит до описаного в статье алгоритма?
А как это работает в поиске? Вы вычисляете скалярное произведение выхода сети для запроса со всеми документами? Если так, то насколько быстро это работает, ведь документов очень много.
Есть еще игры от Paradox: Europa Universalis и Crusader Kings, там много-много разных красивых карт есть, из вашего списка больше всего похожи на Chronas.
На ограниченном временном промежутке (1444-1820 для EU4, есть моды от сообщества для расширения этого периода) есть исторические данные по территориям/правителям/религии. К сожалению исторические события/люди/битвы там есть очень ограниченно и только во время игры.
Кстати, в SMP системе шедулер ничем не отличается от однопроцессорного.
Я не знаю деталей, но мне кажется там есть немало нюансов связанных с накладными расходами на перенос треда с одного ядра на другое, и на правильное балансирование тредов между процессорами. Еще есть вопрос какое ядро/ядра должны заниматься планированием. Например у нас 2 ядра и есть один очень требовательный к cpu тред, а все остальные idle. В таком случае, возможно, лучше запускать планировщик на втором ядре, а первому просто подсовывать результат и по прерыванию он без всяких проверок будет выполнять тот тред который ему сказали.
Недавно наткнулся на интересную статью о багах в планировщике Linux, авторы которой обещают в среднем до 20% улучшения производительности при определенных задачах.
Спасибо, видел предыдущую статью, ничего толком не понял, в этой намного лучше объяснили. Но меня несколько смутили ваши выводы, в частности:
Нам становится не нужен метод обратного распространения ошибки, для обучения сети.
Разве для этого нам не прийдется для каждой особи, на каждой итерации, считать ответ сети для всей обучающей выборки, для того чтобы определить значение фитнес функции?
А также мы больше не нуждаемся в обучающей выборке.
Непонятно как без обучающей выборки можно оценивать результирующий алгоритм.
На ограниченном временном промежутке (1444-1820 для EU4, есть моды от сообщества для расширения этого периода) есть исторические данные по территориям/правителям/религии. К сожалению исторические события/люди/битвы там есть очень ограниченно и только во время игры.
Я не знаю деталей, но мне кажется там есть немало нюансов связанных с накладными расходами на перенос треда с одного ядра на другое, и на правильное балансирование тредов между процессорами. Еще есть вопрос какое ядро/ядра должны заниматься планированием. Например у нас 2 ядра и есть один очень требовательный к cpu тред, а все остальные idle. В таком случае, возможно, лучше запускать планировщик на втором ядре, а первому просто подсовывать результат и по прерыванию он без всяких проверок будет выполнять тот тред который ему сказали.
Недавно наткнулся на интересную статью о багах в планировщике Linux, авторы которой обещают в среднем до 20% улучшения производительности при определенных задачах.
Нам становится не нужен метод обратного распространения ошибки, для обучения сети.
Разве для этого нам не прийдется для каждой особи, на каждой итерации, считать ответ сети для всей обучающей выборки, для того чтобы определить значение фитнес функции?
А также мы больше не нуждаемся в обучающей выборке.
Непонятно как без обучающей выборки можно оценивать результирующий алгоритм.