Нет, серьёзно. Почему такое невозможно? Написать нейронку, пустить её сначала в стандартную либу писать хеллоуворлды и калькуляторы а потом наращивать мощности постепенно. В чём подводные? Если вопрос в трудности реализации так давайте объединимся ради общей цели. Недостаточно программных средств? Нужно скомпенсировать или придумать что-то новое.
Тебе сюда:
> Почему такое невозможно?
Кто сказал?
> потом наращивать мощности постепенно
Вот только сложность задачи обучения возрастает не линейно, а чуть ли не экспоненциально.
> давайте объединимся ради общей цели
Мало кто работает ради прекрасного далёка, все хотят решать более насущные задачи и зарабатывать себе денежки прямо сейчас.
>Тебе сюда: (OP)
В пизду, один хер мой пост затеряется среди тонны других и в лучшем случае получит пару тупых ответов.
>Кто сказал?
Вопрос риторический.
>Вот только сложность задачи обучения возрастает не линейно, а чуть ли не экспоненциально.
Как нивелировать? Повышение мощностей поможет?
>Мало кто работает ради прекрасного далёка, все хотят решать более насущные задачи и зарабатывать себе денежки прямо сейчас.
Значит это пока меньшая из моих проблем
Напомнило один интересный коммент пользователя с хабра, на который недавно натыкался не совсем про нейронки, но про автогенерацию программ в общем
>«Мечта любого программиста — запрограммировать сам процесс программирования». Я когда-то разрабатывал такую штуку, которая позволяла компьютеру оптимизировать код программ (у меня там был поддержан ассемблер х86, байткод JVM и ассемблер пиксельных шейдеров) с помощью генетического алгоритма. Оно работало, и даже находило такие оптимизации, до которых лично я бы не додумался, находя как некоторые нюансы работы отдельных инструкций, так и просто преобразуя и упрощая математические формулы.
https://m.habr.com/ru/post/303486/comments/
Вот и я склоняюсь, что если у кого и появится такая задача, то всё пойдёт по геналгоритмам, т.к. другой концепции по-моему ещё не придумано
>«Мечта любого программиста — запрограммировать сам процесс программирования». Я когда-то разрабатывал такую штуку, которая позволяла компьютеру оптимизировать код программ (у меня там был поддержан ассемблер х86, байткод JVM и ассемблер пиксельных шейдеров) с помощью генетического алгоритма. Оно работало, и даже находило такие оптимизации, до которых лично я бы не додумался, находя как некоторые нюансы работы отдельных инструкций, так и просто преобразуя и упрощая математические формулы.
https://m.habr.com/ru/post/303486/comments/
Вот и я склоняюсь, что если у кого и появится такая задача, то всё пойдёт по геналгоритмам, т.к. другой концепции по-моему ещё не придумано
В машинном обучении ты совершаешь поиск в многомерном пространстве. В случае программы, это будет пространство возможных команд в каждой ячейке твоей машины тьюринга. Это очень сильно многомерное пространство, а такие пространства отстойны тем, что искать в них слишком тяжело.
Полный перебор не работает двум причинам. Первая очевидная - очень долго. С удлиннением числа команд требуется все больше вариантов перебора. При чем сложность растет так быстро, что даже на разумной длины программах тебе не хватит вычислительной мощности планеты.
Вторая - а как отличить корректную программу от некорректной. Даже софт, написанный людьми, содержит баги, тестами все не покроешь.
Можно каким-то образом ограничивать пространство поиска, например, генетическим алгоритмом. Но там требуются ограничения - чтобы вокруг "правильного" алгоритма существовало дохуя неправильных, но работающих примерно. Задача коммивояжера сработает, потому что там есть много квазиоптимальных решений. Написание хелловорда - возможно, тоже, ведь можно вывести сначала print, а потом перебирать разного рода принты, то есть print "yoba" лучше чем exit, а print "hello" еще лучше. Но калькулятор - не.
Ну и генетические алгоритмы вообще не решают вторую проблему. Твоя программа будет запоминать тестовые данные, а не реально что-то вычислять.
Нейронки же обучаются градиентным спуском, таким образом вместо экспоненциальной сложности у нас полином малой степени (смотря как считать), который немного нас приближает к решению. Но
1. Вместо универсальных алгоритмов у тебя есть только дифференцируемые функции. То есть тебе нужно запроектировать класс функций, который при входных данных должен выдать вычисления, как будто это машина тьюринга. Это непросто
2. Градиентный спуск застревает в локальных минимумах, поэтому нужна большая оверпараметризация и хитрые способы избегать локальных минимумов. Это отдельный большой разговор
В итоге что-то работает (NMT и т. д.), но работает хуже труда программистов, требует много процессорной мощности, и практической ценности не имеет, не в этом десятилетии точно
Полный перебор не работает двум причинам. Первая очевидная - очень долго. С удлиннением числа команд требуется все больше вариантов перебора. При чем сложность растет так быстро, что даже на разумной длины программах тебе не хватит вычислительной мощности планеты.
Вторая - а как отличить корректную программу от некорректной. Даже софт, написанный людьми, содержит баги, тестами все не покроешь.
Можно каким-то образом ограничивать пространство поиска, например, генетическим алгоритмом. Но там требуются ограничения - чтобы вокруг "правильного" алгоритма существовало дохуя неправильных, но работающих примерно. Задача коммивояжера сработает, потому что там есть много квазиоптимальных решений. Написание хелловорда - возможно, тоже, ведь можно вывести сначала print, а потом перебирать разного рода принты, то есть print "yoba" лучше чем exit, а print "hello" еще лучше. Но калькулятор - не.
Ну и генетические алгоритмы вообще не решают вторую проблему. Твоя программа будет запоминать тестовые данные, а не реально что-то вычислять.
Нейронки же обучаются градиентным спуском, таким образом вместо экспоненциальной сложности у нас полином малой степени (смотря как считать), который немного нас приближает к решению. Но
1. Вместо универсальных алгоритмов у тебя есть только дифференцируемые функции. То есть тебе нужно запроектировать класс функций, который при входных данных должен выдать вычисления, как будто это машина тьюринга. Это непросто
2. Градиентный спуск застревает в локальных минимумах, поэтому нужна большая оверпараметризация и хитрые способы избегать локальных минимумов. Это отдельный большой разговор
В итоге что-то работает (NMT и т. д.), но работает хуже труда программистов, требует много процессорной мощности, и практической ценности не имеет, не в этом десятилетии точно
ох уж этот заветный самофорс...
О чём ты?
Интересная идея.
