Мне кажется, большинство таких статей и исследований двигаются немного не в том направлении. Для создания ИИ нет большого смысла изучать, чем отличается интеллект шимпанзе от интеллекта человека. Даже не нужно стремиться создать интеллект, близкий к человеческому. Дикие животные вполне самостоятельно живут в лесах, добывают пропитание, причем обучаются этому тоже самостоятельно. Ни одна нейронная сеть на данный момент на такое не способна.
На мой взгляд, в статье много воды, но в ней высказана правильная мысль — у нервных клеток должны быть простые общие принципы обучения и взаимодействия. Никакой жестко заданной программой нельзя заставить электронную собаку научиться понимать новые команды на любом языке и гавкать на чужих. Или даже просто двигаться на четырех лапах и прыгать через препятствия. Когда будут разработаны такие принципы, можно будет говорить, что мы приблизились к пониманию того, как устроен интеллект.
Президент вызывает к себе в кабинет. Ставится задача: президент хочет взорвать пару городов в другой стране. Желательно, полностью.
Что нам нужно?
1. Бомбардировщик, работающий в скрытом режиме.
2. Грузовой отсек из расчета максимум 1 бомба на каждый город.
3. Пилот, не занятый в других полетах.
4. Полученный взрыв должен быть хорошо заметен и нанести много повреждений.
Таким образом, мы приходим к единственному варианту — атомная бомба.
…
Технические детали реализации.
…
Даем президенту код от красной кнопки, объясняем принцип работы, и пусть сидит играется.
Решение работает хорошо, города разрушены до основания, жители мира о человеке, отдавшем приказ, знать не знают (но догадываются). Президент доволен.
Если серьезно, я не знаю, стал ли бы я в какой-либо ситуации делать такую программу по требованию начальства. Но писать об этом я бы точно не стал.
Мне как-то пришла в голову похожая, но немного другая мысль. Написание кода автоматически с помощью перебора вариантов. Например, задаем для функции вход и выход, как в юнит-тестах. Объявленные классы, методы, переменные, и операторы языка — единицы перебора. После завершения перебора выбираем наиболее подходящий вариант. В принципе, это возможно, только наверно много времени будет занимать.
Есть проект CLDR и основанная на нем библиотека ICU. В ней есть средства для форматирования дат, чисел, форм множественного числа, и других вещей, которые зависят от локализации.
Насколько я понимаю, последовательные GUID-ы тоже не на единицу отличаются, если рассматривать его как 128-битное число? Как вы сказали, 32 бита брать необязательно, можно те же 128. Если даже раздавать всем клиентам по 1000 каждый раз, то получится примерно 2^118 вариантов. Если база большая, к примеру расположена на 4 машинах, то можно реализовать такую же схему, как с клиентами — генератор последовательности на каждой машине получает свой большой диапазон у мастер-генератора (назовем его так): [1 — 1000000], [1000001 — 2000000],… Как вы считаете, такая схема реальна, или не стоит заморачиваться? В общем-то, основная причина, по которой я спрашиваю — поиск по целочисленному ключу теоретически должен быть быстрее поиска по GUID (что имеет значение при отказе от join-ов).
Возможно, вопрос немного глупый, но что если бы можно было генерировать автоинкремент на клиенте? К примеру, при подключении к БД программа резервирует себе некоторый набор id-шников — [1001-1100] — и расходует при создании новых записей. По окончании запрашивает снова — [1601-1700]. Какие недостатки будут у такой системы?
Ну вообще-то говорится. Если первый(нулевой) элемент выхода сети больше, чем левый двигатель, то увеличить тягу левого двигателя. Это очень точно и очень конкретно. Это явно связывает первый элемент с левым двигателем. Вам так не кажется? Если нет, то почему?
Как уже сказали, у вас решение принимается не с помощью нейросети, а напрямую в коде. Ради интереса убрал всю работу с нейросетью. Заменил блок принятия решения
Скрытый текст
//thinking
//если я тот кто ближе слабее попробовать съесть, если нет драпать
if (nearlife!=null )
{
if (nearlife.borncount > borncount)
{
double[][] SenseData = { new double[] { 0, 0, 0, 0 } };
trainingSet = new BasicMLDataSet(Input, SenseData);
}
else
{
double[][] SenseData = { new double[] { 1, 1, 1, 1 } };
trainingSet = new BasicMLDataSet(Input, SenseData);
}
IMLData output = network.Compute(trainingSet[0].Ideal);
if (output[0] > pL) { pL += 0.001; } else { pL -= 0.001; }
if (output[1] > pR) { pR += 0.001; } else { pR -= 0.001; }
if (output[2] > pB) { pB += 0.001; } else { pB -= 0.001; }
if (output[3] > pT) { pT += 0.001; } else { pT -= 0.001; }
}
на этот
Скрытый текст
//thinking
//если я тот кто ближе слабее попробовать съесть, если нет драпать
if (nearlife != null)
{
double speedXDelta = Math.Abs(sB - sT); if (speedXDelta > 0.001) speedXDelta = 0.001;
double speedYDelta = Math.Abs(sB - sT); if (speedYDelta > 0.001) speedYDelta = 0.001;
if (nearlife.borncount > this.borncount)
{
// убегаем
// уменьшаем скорость на ближней стороне, увеличиваем на дальней
if (sT < sB) { pT -= speedYDelta; pB += speedYDelta; }
else if (sB < sT) { pB -= speedYDelta; pT += speedYDelta; }
if (sL < sR) { pL -= speedXDelta; pR += speedXDelta; }
else if (sR < sL) { pR -= speedXDelta; pL += speedXDelta; }
}
else
{
// догоняем
// увеличиваем скорость на ближней стороне, уменьшаем на дальней
if (sT < sB) { pT += speedYDelta; pB -= speedYDelta; }
else if (sB < sT) { pB += speedYDelta; pT -= speedYDelta; }
if (sL < sR) { pL += speedXDelta; pR -= speedXDelta; }
else if (sR < sL) { pR += speedXDelta; pL -= speedXDelta; }
}
}
Ничего не изменилось.
Я бы даже сказал, они стали двигаться более логично. Размножение отключено. Переход на другую сторону экрана пришлось заменить отражением от края, иначе клетки начинают метаться туда-сюда.
кстати, у вас в коде много ошибок
Навскидку:
Метка ret1 находится до цикла, в некоторых случаях происходит зацикливание. Насколько я понял, из-за удаления элементов при параллельном доступе.
ret1:
...
foreach (Life life in World) {
...
goto ret1;
}
Неправильно переходит на другую сторону экрана, значение получается больше 1. Оно потом исправляется, но переход в эту сторону не работает.
if (x < 0)
{
x = 1 - x;
}
Левый двигатель тянет вправо, в сторону увеличения x.
Нижний двигатель либо тянет вверх, либо неправильно определяется нижняя граница. Я считал в экранных координатах, где координата y вниз, у себя исправил границу.
x += pL - pR;
y += pB - pT;
...
sB += Math.Pow(GetDist(x, nearlife.x, y - 0.05, nearlife.y), 2) / 10;
Формулировка задачи допускает 2 толкования:
— Морфеус предлагает сначала выбрать руку, затем таблетку из нее
— Морфеус сводит руки вместе, таблетка выбирается из 2 рук сразу, но некоторым образом можно узнать, в какой руке была эта таблетка.
Аналогия автора с фруктами правильная, она относится ко второму варианту. Еще можно по-другому: представим, что в правой руке таблетки более темные. Какая вероятность вытащить темно-красную таблетку из всей кучи?
Теорема Байеса применяется в первом варианте.
Набросал на PHP оба варианта, различие в 3 строчках. Первый выдает 67%, второй 72%.
Да, и GUI тоже дураки придумали.
Хороший скрин может ответить также на много второстепенных вопросов — браузер, ОС, URL страницы и т.д. Главное, на нем должно быть то, что может помочь в решении проблемы. Мне встречалось примерно такое: «При заходе на страницу такую-то белый экран». И реально скрин белого экрана, просто белый прямоугольник и ничего больше.
В будущем вряд ли останется разделение, скажем, на JavaScript-программиста, Python-программиста и .NET-программиста — как и разделение между фронтэндом и бэкэндом.
Ну разве что javascript, python и .net вытеснятся одним универсальным супер-языком. Разделение на фронтенд и бэкенд разработку применительно к веб появилось не так давно, и пока они только отдаляются друг от друга. По крайней мере, лет 8-10 назад вакансию «фронтенд-разработчик» мало где можно было встретить. Даже если писать бэкенд на node.js, все равно там другие задачи, и поэтому другая специализация.
Встречаются люди, которые программируют на JavaScript, и на вопрос, как работает протокол TCP, они отвечают, что это слишком низкоуровневое и они не хотят с таким разбираться. Вот это страшно: исходя из моего опыта, понимание базовых принципов, которые лежат под тем, что ты используешь, очень важно.
Зачем останавливаться на 4 уровне OSI, и почему именно на нем? Давайте будем напрямую из браузера с сетевой картой работать. Уровни абстракции для того и нужны, чтобы не вдаваться в детали реализации. Все знать невозможно, и даже общее представление обо всем иметь невозможно.
Но, когда вы, например, выбираете, как запустить своё приложение в вебе, тут же возникает вопрос процессов против потоков
За несколько лет веб-программирования у меня ни разу не возник такой вопрос. Либо это был хостинг, либо настройкой занимались другие (более опытные) люди. Да, чтобы достичь уровня и зарплаты этих других людей, это надо знать, но для веб-программирования как такового это не нужно. И уж тем более это не свидетельствует о конце эры айтишников.
Возможность сделать свой сайт с неплохим динамическим контентом, просто подвигав ползунки и покидав кнопочки, появится у любого человека.
Несмотря на наличие кучи генераторов сайтов или wordpress/joomla, программирование пока никуда не делось. И не денется. Потому что, чем сложнее система, тем больше потребуется таких ползунков и кнопочек для ее представления. Настолько много, что это будет аналог языка программирования.
Если есть запас времени, лучше посвятить его тому, как работает то, чем вы собираетесь пользоваться, — начиная от курса физики и математики.
Как может помочь в изучении SPDY знание умножения матриц? А знание процессов, происходящих в атоме? Такие общие фразы в целом правильные, но они не дают ответ на основной вопрос — как найти границу, стоит ли изучать дальше, или уже можно начать изучать что-то другое.
Они не просто пользуются автомобилем и включают передачи, а понимают, как автомобиль работает. Когда эта штука становится чем-то вроде электромобиля, им сделать этот переход намного проще.
Вообще-то, абстрактной девочке-блондинке, которая умеет переключать передачи, но не понимает, как работает автомобиль, будет проще. Единственное отличие, которое она заметит — это что больше не надо ездить на заправку, а надо воткнуть провод из машины в розетку в гараже.
Вообще, мне кажется, главное — это не знания, и даже не умение учиться. Главное — это умение разбираться. Умение строить предположения и проверять их. Недостаточно просто прочитать документацию к новому фреймворку, сделать несколько примеров и запомнить основные возможности. Надо проанализировать информацию, определить взаимосвязи, подумать, как это может быть реализовано внутри, и на что такая реализация может повлиять.
По поводу протоколов TCP/IP и других подобных вопросов. Года 3-4 назад я мог в сетевом дампе разобрать начало IP-кадра, узнать значения флагов, и предположить, какие данные придут дальше. Сейчас я практически ничего из этого не помню, просто потому что этим не занимаюсь. Основы основами, но если человек хороший фронтенд/бэкенд разработчик, то совсем необязательно, что он знает тонкости смежных областей.
А ко мне начали приходить с вопросами тестировщики (первый раз в жизни!). Они нашли отличия между требованиями и реализацией (вот так сюрприз!)
Предполагаю, что программисты тоже нашли отличия между требованиями и реализацией, потому как реализация это их работа. Или вернее, у них были вопросы, как именно реализовать конкретное требование. И они могли сообщить об этом гораздо раньше. Но они никому ничего не сказали, потому что:
— Их никто не спрашивал
— Это добавит им работы (за то же время и за те же деньги)
— Как скажут, так и переделаем (можно сделать и так и так без особых усилий)
По моему опыту, чаще встречается первый вариант, реже второй, иногда третий. Да, потом вопросы решаются; программистам говорят «надо сделать вот так»; просто реализация затягивается и время уходит. А можно было сразу спросить программистов (или архитекторов, если они есть)
Ну так все-таки, какое решение формализованной задачи — можно обернуть или нет? Из бумаги-то я кубик сложил, а вот правильно ли это с математической точки зрения.
На мой взгляд, в статье много воды, но в ней высказана правильная мысль — у нервных клеток должны быть простые общие принципы обучения и взаимодействия. Никакой жестко заданной программой нельзя заставить электронную собаку научиться понимать новые команды на любом языке и гавкать на чужих. Или даже просто двигаться на четырех лапах и прыгать через препятствия. Когда будут разработаны такие принципы, можно будет говорить, что мы приблизились к пониманию того, как устроен интеллект.
Если серьезно, я не знаю, стал ли бы я в какой-либо ситуации делать такую программу по требованию начальства. Но писать об этом я бы точно не стал.
на этот
Ничего не изменилось.
Я бы даже сказал, они стали двигаться более логично. Размножение отключено. Переход на другую сторону экрана пришлось заменить отражением от края, иначе клетки начинают метаться туда-сюда.
Метка ret1 находится до цикла, в некоторых случаях происходит зацикливание. Насколько я понял, из-за удаления элементов при параллельном доступе.
Неправильно переходит на другую сторону экрана, значение получается больше 1. Оно потом исправляется, но переход в эту сторону не работает.
Левый двигатель тянет вправо, в сторону увеличения x.
Нижний двигатель либо тянет вверх, либо неправильно определяется нижняя граница. Я считал в экранных координатах, где координата y вниз, у себя исправил границу.
— Морфеус предлагает сначала выбрать руку, затем таблетку из нее
— Морфеус сводит руки вместе, таблетка выбирается из 2 рук сразу, но некоторым образом можно узнать, в какой руке была эта таблетка.
Аналогия автора с фруктами правильная, она относится ко второму варианту. Еще можно по-другому: представим, что в правой руке таблетки более темные. Какая вероятность вытащить темно-красную таблетку из всей кучи?
Теорема Байеса применяется в первом варианте.
Набросал на PHP оба варианта, различие в 3 строчках. Первый выдает 67%, второй 72%.
Хороший скрин может ответить также на много второстепенных вопросов — браузер, ОС, URL страницы и т.д. Главное, на нем должно быть то, что может помочь в решении проблемы. Мне встречалось примерно такое: «При заходе на страницу такую-то белый экран». И реально скрин белого экрана, просто белый прямоугольник и ничего больше.
Нашел перебором по словарю словоформ отсюда
Файл надо перевести в кодировку ansi (т.е. windows) и преобразовать первую букву всех слов в прописную
Ну разве что javascript, python и .net вытеснятся одним универсальным супер-языком. Разделение на фронтенд и бэкенд разработку применительно к веб появилось не так давно, и пока они только отдаляются друг от друга. По крайней мере, лет 8-10 назад вакансию «фронтенд-разработчик» мало где можно было встретить. Даже если писать бэкенд на node.js, все равно там другие задачи, и поэтому другая специализация.
Зачем останавливаться на 4 уровне OSI, и почему именно на нем? Давайте будем напрямую из браузера с сетевой картой работать. Уровни абстракции для того и нужны, чтобы не вдаваться в детали реализации. Все знать невозможно, и даже общее представление обо всем иметь невозможно.
За несколько лет веб-программирования у меня ни разу не возник такой вопрос. Либо это был хостинг, либо настройкой занимались другие (более опытные) люди. Да, чтобы достичь уровня и зарплаты этих других людей, это надо знать, но для веб-программирования как такового это не нужно. И уж тем более это не свидетельствует о конце эры айтишников.
Несмотря на наличие кучи генераторов сайтов или wordpress/joomla, программирование пока никуда не делось. И не денется. Потому что, чем сложнее система, тем больше потребуется таких ползунков и кнопочек для ее представления. Настолько много, что это будет аналог языка программирования.
Как может помочь в изучении SPDY знание умножения матриц? А знание процессов, происходящих в атоме? Такие общие фразы в целом правильные, но они не дают ответ на основной вопрос — как найти границу, стоит ли изучать дальше, или уже можно начать изучать что-то другое.
Вообще-то, абстрактной девочке-блондинке, которая умеет переключать передачи, но не понимает, как работает автомобиль, будет проще. Единственное отличие, которое она заметит — это что больше не надо ездить на заправку, а надо воткнуть провод из машины в розетку в гараже.
Вообще, мне кажется, главное — это не знания, и даже не умение учиться. Главное — это умение разбираться. Умение строить предположения и проверять их. Недостаточно просто прочитать документацию к новому фреймворку, сделать несколько примеров и запомнить основные возможности. Надо проанализировать информацию, определить взаимосвязи, подумать, как это может быть реализовано внутри, и на что такая реализация может повлиять.
Предполагаю, что программисты тоже нашли отличия между требованиями и реализацией, потому как реализация это их работа. Или вернее, у них были вопросы, как именно реализовать конкретное требование. И они могли сообщить об этом гораздо раньше. Но они никому ничего не сказали, потому что:
— Их никто не спрашивал
— Это добавит им работы (за то же время и за те же деньги)
— Как скажут, так и переделаем (можно сделать и так и так без особых усилий)
По моему опыту, чаще встречается первый вариант, реже второй, иногда третий. Да, потом вопросы решаются; программистам говорят «надо сделать вот так»; просто реализация затягивается и время уходит. А можно было сразу спросить программистов (или архитекторов, если они есть)