Pull to refresh
63
0.4
Михаил@michael_v89

Программист

Send message
Мне кажется, большинство таких статей и исследований двигаются немного не в том направлении. Для создания ИИ нет большого смысла изучать, чем отличается интеллект шимпанзе от интеллекта человека. Даже не нужно стремиться создать интеллект, близкий к человеческому. Дикие животные вполне самостоятельно живут в лесах, добывают пропитание, причем обучаются этому тоже самостоятельно. Ни одна нейронная сеть на данный момент на такое не способна.

На мой взгляд, в статье много воды, но в ней высказана правильная мысль — у нервных клеток должны быть простые общие принципы обучения и взаимодействия. Никакой жестко заданной программой нельзя заставить электронную собаку научиться понимать новые команды на любом языке и гавкать на чужих. Или даже просто двигаться на четырех лапах и прыгать через препятствия. Когда будут разработаны такие принципы, можно будет говорить, что мы приблизились к пониманию того, как устроен интеллект.
А вы сами то как думаете?

Президент вызывает к себе в кабинет. Ставится задача: президент хочет взорвать пару городов в другой стране. Желательно, полностью.
Что нам нужно?
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%.
1 вариант
function test1()
{
    define('LEFT',  0);
    define('RIGHT', 1);
    
    define('BLUE', '0000FF');
    define('RED',  'FF0000');
    
    $hands = [];
    $hands[LEFT] = [];
    $hands[RIGHT] = [];
    
    $config = [
        LEFT  => [BLUE => 7, RED => 3],
        RIGHT => [BLUE => 5, RED => 8],
    ];
    
    foreach ($config as $hand => $handConfig) {
        foreach ($handConfig as $color => $tabletCount) {
            for ($i = 0; $i < $tabletCount; $i++) {
                $hands[$hand][] = ['color' => $color, 'hand' => $hand];
            }
        }
    }
    
    
    $totalCount = 100000;
    $redTabletCount = 0;
    $rightHandCount = 0;
    for ($i = 0; $i < $totalCount; $i++) {
        $hand = mt_rand(LEFT, RIGHT);
        $tablets = $hands[$hand];
        
        $tablet = $tablets[mt_rand(0, count($tablets) - 1)];
        if ($tablet['color'] == RED) {
            $redTabletCount++;
            
            if ($hand == RIGHT) {
                $rightHandCount++;
            }
        }
    }
    
    echo $rightHandCount.' / '.$redTabletCount.' = '.($rightHandCount * 100 / $redTabletCount).'%';
}


2 вариант
function test2()
{
    define('LEFT',  0);
    define('RIGHT', 1);
    
    define('BLUE', '0000FF');
    define('RED',  'FF0000');
    
    $hands = [];
    $hands[LEFT] = [];
    $hands[RIGHT] = [];
    
    $config = [
        LEFT  => [BLUE => 7, RED => 3],
        RIGHT => [BLUE => 5, RED => 8],
    ];
    
    foreach ($config as $hand => $handConfig) {
        foreach ($handConfig as $color => $tabletCount) {
            for ($i = 0; $i < $tabletCount; $i++) {
                $hands[$hand][] = ['color' => $color, 'hand' => $hand];
            }
        }
    }
    
    
    $totalCount = 100000;
    $redTabletCount = 0;
    $rightHandCount = 0;
    for ($i = 0; $i < $totalCount; $i++) {
        //$hand = mt_rand(LEFT, RIGHT);                         // changed
        $tablets = array_merge($hands[LEFT], $hands[RIGHT]);    // changed
        
        $tablet = $tablets[mt_rand(0, count($tablets) - 1)];
        if ($tablet['color'] == RED) {
            $redTabletCount++;
            
            if ($tablet['hand'] == RIGHT) {                     // changed
                $rightHandCount++;
            }
        }
    }
    
    echo $rightHandCount.' / '.$redTabletCount.' = '.($rightHandCount * 100 / $redTabletCount).'%';
}

Да, и GUI тоже дураки придумали.
Хороший скрин может ответить также на много второстепенных вопросов — браузер, ОС, URL страницы и т.д. Главное, на нем должно быть то, что может помочь в решении проблемы. Мне встречалось примерно такое: «При заходе на страницу такую-то белый экран». И реально скрин белого экрана, просто белый прямоугольник и ничего больше.
А девушка-то в курсе, что она объект применения социнжиниринга?)
слово из мануала по win3.1
Командную

Нашел перебором по словарю словоформ отсюда
Файл надо перевести в кодировку ansi (т.е. windows) и преобразовать первую букву всех слов в прописную
В будущем вряд ли останется разделение, скажем, на JavaScript-программиста, Python-программиста и .NET-программиста — как и разделение между фронтэндом и бэкэндом.

Ну разве что javascript, python и .net вытеснятся одним универсальным супер-языком. Разделение на фронтенд и бэкенд разработку применительно к веб появилось не так давно, и пока они только отдаляются друг от друга. По крайней мере, лет 8-10 назад вакансию «фронтенд-разработчик» мало где можно было встретить. Даже если писать бэкенд на node.js, все равно там другие задачи, и поэтому другая специализация.

Встречаются люди, которые программируют на JavaScript, и на вопрос, как работает протокол TCP, они отвечают, что это слишком низкоуровневое и они не хотят с таким разбираться. Вот это страшно: исходя из моего опыта, понимание базовых принципов, которые лежат под тем, что ты используешь, очень важно.

Зачем останавливаться на 4 уровне OSI, и почему именно на нем? Давайте будем напрямую из браузера с сетевой картой работать. Уровни абстракции для того и нужны, чтобы не вдаваться в детали реализации. Все знать невозможно, и даже общее представление обо всем иметь невозможно.

Но, когда вы, например, выбираете, как запустить своё приложение в вебе, тут же возникает вопрос процессов против потоков

За несколько лет веб-программирования у меня ни разу не возник такой вопрос. Либо это был хостинг, либо настройкой занимались другие (более опытные) люди. Да, чтобы достичь уровня и зарплаты этих других людей, это надо знать, но для веб-программирования как такового это не нужно. И уж тем более это не свидетельствует о конце эры айтишников.

Возможность сделать свой сайт с неплохим динамическим контентом, просто подвигав ползунки и покидав кнопочки, появится у любого человека.

Несмотря на наличие кучи генераторов сайтов или wordpress/joomla, программирование пока никуда не делось. И не денется. Потому что, чем сложнее система, тем больше потребуется таких ползунков и кнопочек для ее представления. Настолько много, что это будет аналог языка программирования.

Если есть запас времени, лучше посвятить его тому, как работает то, чем вы собираетесь пользоваться, — начиная от курса физики и математики.

Как может помочь в изучении SPDY знание умножения матриц? А знание процессов, происходящих в атоме? Такие общие фразы в целом правильные, но они не дают ответ на основной вопрос — как найти границу, стоит ли изучать дальше, или уже можно начать изучать что-то другое.

Они не просто пользуются автомобилем и включают передачи, а понимают, как автомобиль работает. Когда эта штука становится чем-то вроде электромобиля, им сделать этот переход намного проще.

Вообще-то, абстрактной девочке-блондинке, которая умеет переключать передачи, но не понимает, как работает автомобиль, будет проще. Единственное отличие, которое она заметит — это что больше не надо ездить на заправку, а надо воткнуть провод из машины в розетку в гараже.

Вообще, мне кажется, главное — это не знания, и даже не умение учиться. Главное — это умение разбираться. Умение строить предположения и проверять их. Недостаточно просто прочитать документацию к новому фреймворку, сделать несколько примеров и запомнить основные возможности. Надо проанализировать информацию, определить взаимосвязи, подумать, как это может быть реализовано внутри, и на что такая реализация может повлиять.
По поводу протоколов TCP/IP и других подобных вопросов. Года 3-4 назад я мог в сетевом дампе разобрать начало IP-кадра, узнать значения флагов, и предположить, какие данные придут дальше. Сейчас я практически ничего из этого не помню, просто потому что этим не занимаюсь. Основы основами, но если человек хороший фронтенд/бэкенд разработчик, то совсем необязательно, что он знает тонкости смежных областей.
А ко мне начали приходить с вопросами тестировщики (первый раз в жизни!). Они нашли отличия между требованиями и реализацией (вот так сюрприз!)

Предполагаю, что программисты тоже нашли отличия между требованиями и реализацией, потому как реализация это их работа. Или вернее, у них были вопросы, как именно реализовать конкретное требование. И они могли сообщить об этом гораздо раньше. Но они никому ничего не сказали, потому что:
— Их никто не спрашивал
— Это добавит им работы (за то же время и за те же деньги)
— Как скажут, так и переделаем (можно сделать и так и так без особых усилий)

По моему опыту, чаще встречается первый вариант, реже второй, иногда третий. Да, потом вопросы решаются; программистам говорят «надо сделать вот так»; просто реализация затягивается и время уходит. А можно было сразу спросить программистов (или архитекторов, если они есть)
Ну так все-таки, какое решение формализованной задачи — можно обернуть или нет? Из бумаги-то я кубик сложил, а вот правильно ли это с математической точки зрения.

Information

Rating
2,355-th
Location
Россия
Registered
Activity