Выучить математику через программирование

Тем не менее, все юзают A* и не заморачиваются.

ну возьми любую гаму, и увидь, насколько тупорылые там боты. Что они со своим A* дальше носа не видят.

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

давай проверим: попросим нарисовать два лабиринта, один ты покажешь мне, а второй покажешь вебкамере своего компьютера. Я на 146% уверен, что ты задолбаешься объяснять своей системе, ЧЕГО же ты от неё хочешь. Особенно если тестовый лабиринт нарисует рандомно выбранный незнакомый человек с улицы.

Компьютеры отлично считают задачи, но тогда, и только тогда, когда сама задача == компьютерная синтетика.

Да и тогда, компьютер решает задачу тупо методом перебора, ибо других ему неведомо. Алгоритм можно составить тогда, и только тогда, когда ТОЧНО известны условия. А такого IRL тупо не бывает.

Но суть в том, что боту, как и тебе, не нужен лучший путь, ему нужен «приемлемый», то есть какой-нибудь, не сильно хуже лучшего. А с этим справляется множество различных алгоритмов и достаточно быстро.

у меня есть киллер фича — я вижу всё поле, а ты со своим A* — только то, куда ты свои * воткнул. И если путь А->B худо бедно A* решает, то вот оптимальный маршрут A->B->C->D — увы. А для меня это даже не требует никаких усилий, я его тупо ВИЖУ. Потому-то это и так дьявольски сложно запрограммировать.

Складывал уравнения, и сокращал неизвестные.

Вообще-то все так и делают, man метод Гаусса.

Ты уже надумываешь того, чего не нужно

задумка такая была, для неё было нужно

оно либо прошло, то есть столкнулось, либо нет,

а в этом случае одно тело может проходить сквозь другое, поэтому просто столкнулось-нестолкнулось не достаточно

кроме того в движках помимо столкнулось-нестолкнулось много чего ещё есть, например, обработка результатов столкновения — имеют значения мягкость, гибкость и твёрдость соприкасающихся тел, например

Во вторых: ты и авторы твоего учебника просто не умеют готовить float'ы. Мой CPU жрёт их в восемь глоток СРАЗУ, и глупо не юзать такую мощь.

Там какбы речь идет о том что при вычислении детерминанта на больших матрицах будут слишком большие ошибки из-за свойств флоатов.

Мнение о тесной связи программирования и математики слишком завышено.

Программирование это прикладная математика. Поэтому мнения о связи этого вообще бред. Это одно и то же.

И где там будет математика?

там бездна матана. Самой разной направленности. Попробуй, погрузись в эту тему, если не веришь...

Там работа с изображениями займет львиную долю, перегоняя из пустого в порожнее пока не получим четкий черный силуэт на белом фоне

А можно поконкретнее про этот чудо алгоритм?

а вся математика будет вида «равно/не равно» да скайлинг вырезанных букв до нужного паттерна, опять таки скайлинг одним методом scale :)

а ничего, что буквы разные, да ещё и повёрнуты на разный угол? Тут давеча тред был, дык народ даже фигурки в тетрисе перевернуть не мог...

Ладно, любой дебил определит букву «О». Теперь дай алгоритм, который находит букву «О» на фотке. 0 и о тоже пойдёт. А вот П и Э — неа. Жду с нетерпением...

Ну у нас в 9 классе помнится бывало скидывались и на пиво и на сигареты, причем бабло все отлично считать умели, при виде бабла даже двоечники вспоминали как поделить, умножить уравнением в уме быстрее чем калькулятор

это точно сигареты? А зачем уравнения? Там пропорции за глаза хватит.

давай проверим: попросим нарисовать два лабиринта, один ты покажешь мне, а второй покажешь вебкамере своего компьютера. Я на 146% уверен, что ты задолбаешься объяснять своей системе, ЧЕГО же ты от неё хочешь. Особенно если тестовый лабиринт нарисует рандомно выбранный незнакомый человек с улицы.

А ещё можно кодить стоя на голове.

я его тупо ВИЖУ

Это не значит, что твой мозг не производит соответствующие вычисления.

ну возьми любую гаму, и увидь, насколько тупорылые там боты.

Не проблема определения кратчайшего пути.

Да и тогда, компьютер решает задачу тупо методом перебора, ибо других ему неведомо.

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

А вот П и Э — неа. Жду с нетерпением...

Смотря какой формат в этой капче, и насколько искарежены буквы, я бы это решал скажем простым перцептроном с матрицей в 64x64 пикселя, соответственно буквы с капчи пришлось бы подгонять в этот размер. Это что касаемо простых капч, а если это чудо вроде гугловской, то я бы ее ломал с помощью antigate.com идите вы нафиг со своими нейросетями, я на психа не похож :)

А можно поконкретнее про этот чудо алгоритм?

В простых случаях достаточно обесцвечивания, и повышения порога /контраста. Что-то похожее я делал в распознавании и отслеживании предмета вебкамерой: Делаем «графический планшет» из веб-камеры и старой мыши

Получим бота который будет шпилить игрока исключительно сзади (привет геям), + менять тактику опять таки получая внешние условия и учитывая их. Только где тут математика

если твой бот будет тупо шпилить всех сзади, все будут постоянно оглядываться. Боту надо статистику собирать. И не только собирать, но и уметь её правильно обрабатывать. А статистика — один из сложнейших разделов матана. Ты это не ценишь, потому-что оно дадено всем бесплатно, даже зверям. И ты даже не задумываешься, насколько это на само деле сложно...

Алгоритм поиска пути давно написан на любом языке к большинству движков, только копипасти.

угу. И получится у тебя очередная никому не нужная поделка, в которую играть будет неинтересно даже тебе. И да, в играх проще — всегда есть Великий Китайский Рандом. А вот в реальных программах управления — увы. Если твой ОБЧР начнёт прикольно биться головой апстену, это не оценят...

Ну, если программирование и математика - одно и то же, то предлагаю с помощью программирования доказать, что

$\sum_{n=0}^\infty \frac{(-1)^n}{n} = \ln 2$

если твой бот будет тупо шпилить всех сзади

Я там и писал, + смена тактики но вы это предпочли не увидеть. Насчет статистики согласен, но если сильно заморачиваться, можно и ее написать, игровой мир не столь обширен, и все возможные действия в этом мире известны, следовательно можно написать алгоритм скрупулезно собирающий статистику в нужной нам структуре и умеющий ее применять. Это тоже самое, что написать программу собирающею и применяющею статистику из мира в котором возможны только два действия, это легко, для игрового мира куда сложнее ибо не два возможных действия, но тоже вполне возможно.

Школопроблемы. В старших классах тебе объяснят, что математика не ограничивается арифметикой и геометрией.

Вообще-то все так и делают, man метод Гаусса.

никто так не делает. Ну и да, я тоже делал не так, ибо там надо в треугольную матрицу преобразовать, а у меня — это невозможно(точнее, в этом и цель — найти систему, которая преобразуется в треугольную). Ну и кроме того, математика другая, и обычные формулы работают не совсем так, или совсем не так.

Школопроблемы. В старших классах тебе объяснят, что математика не ограничивается арифметикой и геометрией.

Ну что, засветился, школоло? Проучись ты дальше школы, тебе бы объяснили, что приведенный ряд - это мат. анализ.

Там какбы речь идет о том что при вычислении детерминанта на больших матрицах будут слишком большие ошибки из-за свойств флоатов.

ну я знаю. Используй два флоата (или даже массив флоатов), если тебе нужно не терять числа высших порядков малости. Детерминант по своей сути — разность произведений. И эта разность должна быть разложена на части. Т.е. если ты считаешь X*y - X*z, где X очень большое, а y-z маленькое, то во float'ах получается ноль. Кто тебе мешает посчитать X*(y-z)? Алгоритм? Ты программист или где? Измени алгоритм, это твоя работа. Я по опыту знаю, что самая красивая формула == самый плохой алгоритм (обратное неверно).

А ещё можно кодить стоя на голове.

при чём тут это? В жизни задачи всегда такие. Хочешь — делай вдоль, и посмотри, есть-ли за последней страницей твоей никчёмной жизни странички с ответами на все вопросы...

я его тупо ВИЖУ

Это не значит, что твой мозг не производит соответствующие вычисления.

расскажи — какие именно, и по каким алгоритмам.

Не проблема определения кратчайшего пути.

проблема, и до сих пор не решённая.

Да и тогда, компьютер решает задачу тупо методом перебора, ибо других ему неведомо.

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

твой ничем не хуже. Ты лучше расскажи, как, чёрт возьми, он это делает?

Смотря какой формат в этой капче

учись читать: это ФОТОГРАФИЯ. Формат JPEG, доволен?

соответственно буквы с капчи пришлось бы подгонять в этот размер.

ты их сначала НАЙДИ! Фотка есть, но координат букв там почему-то нет...

идите вы нафиг со своими нейросетями, я на психа не похож

ну это ты...

В простых случаях достаточно обесцвечивания, и повышения порога /контраста. Что-то похожее я делал в распознавании и отслеживании предмета вебкамерой: Делаем «графический планшет» из веб-камеры и старой мыши

мда... Ты явно совсем не в теме...

Кстати hint: ты зря обесцвечиваешь — цвета очень хорошо облегчают распознавание. Круглое от квадратного комп отличает хреновастенько жуя мегафлопсы тоннами. А вот зелёный от синего — легко. Потому зелёный квадрат на фоне синего круга можно вытянуть просто потому, что он зелёный. А если его обесцветить — будет беда...

Когда досчитаете бесконечный ряд, можем возвратиться к разговору.

можешь как-нить по-человечески записать, а я посчитаю. Скорее всего даже обойдусь без вышки. Мне похожая формула IRL попадалась.

Я там и писал, + смена тактики но вы это предпочли не увидеть.

да ладно! Именно про это и мой пост: для тебя это «несущественно», ибо ты в уме это делаешь как дышишь, а вот попробуй это всё запрограммировать...

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

это тебе только кажется. Сложность вычислений растёт как факториал. Даже такая тривиально простая игра как шахматы, дьявольски сложна для компьютера. А в играх фигурок несколько больше, и правила несколько сложнее. Да и мощностей тёмно-синих под рукой нет...

Ну что, засветился, школоло? Проучись ты дальше школы, тебе бы объяснили, что приведенный ряд - это мат. анализ.

ты тоже поучись, и узнаешь, что это не только матанализ. Такие задачи можно решать и иначе.

Ты лучше расскажи, как, чёрт возьми, он это делает?

Это магия. *картинка с Леонардом*

можешь как-нить по-человечески записать, а я посчитаю. Скорее всего даже обойдусь без вышки. Мне похожая формула IRL попадалась.

А что там считать-то? По-человечески это будет по этой ссылке. x=1 только подставить.

ты тоже поучись, и узнаешь, что это не только матанализ. Такие задачи можно решать и иначе.

Решать - да. Но чтобы доказать, без понятия предела никуда. А это мат. анализ. Или тебе определения Коши и Гейне предела где-то еще давали?

Это магия

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

А что там считать-то?

ха! Считать этот ряд очень интересно и увлекательно. Между прочим, эта задачка намного сложнее, чем твои пределы. Да-да: посчитай-ка такой ряд с помощью float и современного компа. Будь уверен, тебе для этого понадобятся намного более глубокие знания в математике, чем для того, что-бы нагуглить то, что он равен ln(2). С доказательством.

Решать - да. Но чтобы доказать, без понятия предела никуда. А это мат. анализ. Или тебе определения Коши и Гейне предела где-то еще давали?

там хитрость в том, что для самого решения никакого анализа не нужно. Анализ нужен для _поиска_ решения. И для доказательства его корректности с учётом кривизны реальных вычислителей.

Впрочем, конкретно в этом случае нет ничего сложного, просто надо считать с конца, начиная с 8388608го члена формулы, тогда ты получишь весьма точный результат.

Вот смотри:

#include <stdio.h>


int main()
{
	int n0 = 8388608;
	float s = 0;
	float x;
	int n;
	for(n = n0; n >= 1; n--)
	{
		x = 1.0/n;
		n&1 ? (s += x) : (s -= x);
	}
	printf("%.8f\n", s);
	return 0;
}

что-бы вычислить константу 8388608, мне потребовался обычный калькулятор, и знание арифметики (это 2^23, причём 23 это число мантиссы float'а).

Да, без знания высшей математики я вряд-ли бы догадался считать таким хитрым способом...

да, мой старенький нетбук с атомом вместо процессора тратит на это real 0m0.544s

Да-да: посчитай-ка такой ряд с помощью float и современного компа. Будь уверен, тебе для этого понадобятся намного более глубокие знания в математике, чем для того, что-бы нагуглить то, что он равен ln(2).

Ну все, ты мне доказал, что программирование важнее, а математика - для нищебродов, у которых нет денег на современный комп. Я специально выбирал плохо сходящийся ряд для оппонента, чтобы процесс расчета отнял побольше времени. Но разве не в этом мое преимущество, что задачу, на которую тебе нужны мощности современного компьютера, я решаю в уме? А ведь это семечки, и как ты заметил, решение можно нагуглить. А если что посерьезней взять, рассчитаешь на компьютере? Например, доказать, что объем гипертетраэдра составляет 1/N! от объема гиперпараллелепипеда, где N - количество измерений. Жду решения.

И еще одна лажа в твоем решении - это отсутствие параметров. Слабо доказать формулу в общем виде для произвольного x (|x|<1)?

Ну все, ты мне доказал, что программирование важнее, а математика - для нищебродов, у которых нет денег на современный комп.

не ешь больше этих грибов. Я тебе пытался доказать, что если ты не знаешь математики, твоя работа: http://lurkmore.so/images/2/2b/За_еду.jpg

Я специально выбирал плохо сходящийся ряд для оппонента, чтобы процесс расчета отнял побольше времени.

время не имеет значения. Важен результат. И ты его НЕ достигнешь, если просто обернёшь формулу в <любимый ЯП>. И тебе ничто не поможет, не скорость сишечки (которая даст неверный результат), не бесконечная точность LISP'а(ты просто не дождёшься своего «бесконечно точного» результата). А время — это количественно, это не принципиально в данном случае. Ты сильно ошибаешься, если думаешь, что я не смогу достигнуть результата так быстро, как это только вообще возможно в данном вычислителе. Но ты просил посчитать. Я посчитал. Просто тупо сложил.

Но разве не в этом мое преимущество, что задачу, на которую тебе нужны мощности современного компьютера, я решаю в уме?

уж поверь мне, я эту задачу тоже в уме решаю. Мой калькулятор не умеет двоичные логарифмы, а мне они очень часто нужны. Часто лень давить на кнопки, и быстрее помножить в уме.

А ведь это семечки, и как ты заметил, решение можно нагуглить. А если что посерьезней взять, рассчитаешь на компьютере? Например, доказать, что объем гипертетраэдра составляет 1/N! от объема гиперпараллелепипеда, где N - количество измерений. Жду решения.

это наверное тоже можно нагуглить. Но не в том дело: знакопеременные ряды очень важны на практике (моей), куда приткнуть твой гиперпараллелепипед — мне как-то сходу не догадаться... Да и я вообще не представляю, как доказывать геометрию в компьютере. Просто не сталкивался никогда. Слышал, что народ успешно решал такое, но как именно — не интересовался. Там вроде не очень сложно, нужно просто придумать, как хранить все эти фигуры, и как описать операции с ними. ВНЕЗАПНО: правила-то одни и те же... Но вот я, к стыду своему, даже объём обычного тетраэдра сходу не скажу... За то отлично знаю, как его считать. Количество измерений не имеет значения, правила одни. Вот пусть комп и считает.

И еще одна лажа в твоем решении - это отсутствие параметров. Слабо доказать формулу в общем виде для произвольного x (|x|<1)?

ну мне очевидно, что x==1 это предельный случай, мало того, удивительно, что ряд вообще сходится при таком x. Очевидно, что при маленьком x он будет сходится быстрее, ибо x^n намного быстрее уменьшается с ростом n. Потому для не слишком больших x можно считать как обычно, ибо ряд (в данном случае степенной) сойдётся очень быстро, для float быстрее, чем за 23 шага для x=1/2. Потому, для x>1/2 считать так не нужно. К примеру что-бы посчитать ln(2) можно посчитать -ln(1/2), за 23 шага, а не за 8 миллионов. Достаточно школьного курса, что-бы догадаться, что твоего быстро сходящегося ряда для |x|<=1/2 достаточно для вычисления логарифма ЛЮБОГО x (из ОДЗ конечно).

Моё «решение» служит лишь иллюстрацией того факта, что грамотный кодинг позволяет вычислить огромное количество операций, и при этом погрешность будет в заданных пределах, а обычно даже лучше (как у меня).

PS: кстати IRL так логарифм и считают(в большинстве архитектур). Формула очень удобна, т.к. гарантированно сходится за 20 с небольшим шагов, при этом там только 40 с небольшим умножений(число умножений часто можно понизить до 20, если считать |x|<1/4, если я не ошибаюсь. Давно не занимался такой низкоуровневой ерундой).

За такое и штраф могут выписать.

У нас могут. Даже не смотря на то, что библиотеку ликвидировали, а завод порвали при попытке поделить :) Теперь там корпуса стоят голые, можно снимать сцены перестрелок между крышующими группировками и честными ментами.

PS: кстати IRL так логарифм и считают(в большинстве архитектур).

Ты же прекрасно понимаешь, что нет. Это очень плохой ряд, который дает значение ln(1+x) только при |x|<1. Да еще ужасно сходится при x=1. Если отойти именно от этого ряда, то да, так и считают, раскладывая в какой-нибудь ряд, но не ln(1+x), а ln((1+x)/(1-x)).

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

Батти совсем плохим стал, у него метод Гауса ни в каком учебнике не делают. Его даже в LAPACK'е не реализовали. И даже в LINPACK'е - бенчмарке top500 он никак не присутствует.

обычные методы работают хуже этого школьного

Угорел.

Вообще говоря надо доказывать, что ряд сойдётся. Тривиальным говнокодом на сях этого добиться не удастся.

Это очень плохой ряд, который дает значение ln(1+x) только при |x|<1. Да еще ужасно сходится при x=1.

facepalm...

Если отойти именно от этого ряда, то да, так и считают, раскладывая в какой-нибудь ряд, но не ln(1+x), а ln((1+x)/(1-x)).

это ты так шутишь, или всё настолько запущено? ln((1+x)/(1-x)) === ln(1+x) - ln(1-x). Те же яйца только в профиль.

Ряд сходится, и сходится отлично. Только x надо брать <1/2. Если хочешь больше разных x'ов, то пересчитай аргумент и/или результат. Вот тебе шпора: http://ru.wikipedia.org/wiki/Логарифм#.D0.9E.D1.81.D0.BD.D0.BE.D0.B2.D0.BD.D0...

ну например: берём x == -1/2, и считаем быстренько(23 хода) ln(1-1/2)==ln(1/2)=-.69314718. Ловким движением руки меняем минус на плюс, и вуаля! Готов твой ln(2), для вычисления которого мне потребовалось 8 миллионов итераций! Что тут сложного?

Это очень плохой ряд, который дает значение ln(1+x) только при |x|<1. Да еще ужасно сходится при x=1.

facepalm...

Если отойти именно от этого ряда, то да, так и считают, раскладывая в какой-нибудь ряд, но не ln(1+x), а ln((1+x)/(1-x)).

это ты так шутишь, или всё настолько запущено? ln((1+x)/(1-x)) === ln(1+x) - ln(1-x). Те же яйца только в профиль.

Ряд сходится, и сходится отлично. Только x надо брать <1/2. Если хочешь больше разных x'ов, то пересчитай аргумент и/или результат. Вот тебе шпора: http://ru.wikipedia.org/wiki/Логарифм#.D0.9E.D1.81.D0.BD.D0.BE.D0.B2.D0.BD.D0...

ну например: берём x == -1/2, и считаем быстренько(23 хода) ln(1-1/2)==ln(1/2)=-.69314718. Ловким движением руки меняем минус на плюс, и вуаля! Готов твой ln(2), для вычисления которого мне потребовалось 8 миллионов итераций! Что тут сложного?

это ты так шутишь, или всё настолько запущено? ln((1+x)/(1-x)) === ln(1+x) - ln(1-x). Те же яйца только в профиль.

Ты о ряде или о чем? Чего на пол-пути остановился, где продолжение? А продолжить можно так

ln((1+x)/(1-x))=2(x+(x^3)/3+(x^5)/5 + ...)

Как видишь, ряд превратился из знакопеременного (для x>0) в ряд с одним знаком. Как следствие - члены ряда меньше. Ты там говорил про x=-1/2, да? А теперь здесь возьми x=1/3, чтобы получить ln(2). Да еще отмечу, что сократились четные члены, поэтому фактически нужно брать x^2. Ну и как тебе, 1/9 против 1/2? Хотя да, без говнокода на сишечке ты в уме не представишь, какой ряд сходится быстрее.

Т.е. если ты считаешь X*y - X*z, где X очень большое, а y-z маленькое, то во float'ах получается ноль. Кто тебе мешает посчитать X*(y-z)?

Ну и придется в итоге делить не на ноль, а на 1e-16 например. Достижение же.

Как видишь, ряд превратился из знакопеременного (для x>0) в ряд с одним знаком.

я это и так вижу. У нас ведь степенной знакопеременный ряд. Когда ты умножаешь аргумент на -1, получаешь знакопостоянный, ибо только нечётные степени меняют свой знак. Когда ты вычитаешь из знакопеременного знакопостоянный(такой-же), то просто вычёркиваешь все члены с одинаковым знаком (-). Очевидно, что в итоге получается ряд, где все степени нечётные и (+).

Хотя да, без говнокода на сишечке ты в уме не представишь, какой ряд сходится быстрее.

если-бы я этого не представлял, то я-бы не смог написать этот код. Ты, кстати, зря остановился, считай дальше. Что-бы снизить число итераций не до 10и, а до одной (: Хотя не надо, это давно сделано задолго до нашего рождения...

Просто это всё равно тот же самый ряд.

Ну и придется в итоге делить не на ноль, а на 1e-16 например. Достижение же.

да, достижение. Например (10^-15)/(10^-16)=10.0. Чем ты недоволен? Вполне себе годный результат. Марьивановна тебе 5 поставит.

Можно, конечно. Напиши wget, скачай им много-много литературы по математике — профит!

Нет. Вообще разные вещи.

Легкого пути в математику нету.

Программирование это прикладная математика

Бред.

Скорее, наоборот - зная математику, лучше будешь программировать. Ибо второе есть ответвление первого. Я, к примеру, после изучения теории чисел стал слету писать мозговыносящие функции вроде проверки числа на степень двойки, поиска байта с заданным значением в массиве байт и т.д.

Однако, не всем кодерам (не говорю «программистам») это нужно.

Программирование это прикладная математика

Бред.

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

нет.

Что бы ты об этом не думал, но программирование действительно прикладная часть дискретной математики. Когда я познакомился с ней (а мне по образованию в ПТУ вроде как и не положено) я лучше стал понимать не только программирование, но вообще всё. По сути «всё» это и есть прикладная математика. Кто этого не понял, не знает либо что такое математика, либо что такое всё.