на него места нужно больше, а вот на паре где-то в лаборатории такое чудо выглядит довольно неприметно и компактно улаживается под столом в случае шухера…
Ссылка это самое первое что попалось под руку в Гугле.
Там такого барахла хватает не спорю, но это первое что мне показалось похожее на тему. Если очень интересно могу дать конкретно книгу по МайндХаку где это всё написано. Динамические цепи они такие динамичиские =)
Идеей алгоритма динамических цепей является самооптимизация на основе ген. алгоритма и подальшей модификации фитнес функции через neuro-fuzzy logic.
Сам себе швец и жнец и учитель. На основе динамической цепи можно
спокойно строить такой же (а может и более) динамический апарат нейронной сети.
Вот собственно этим я и занимаюсь. Просто в моём случае не используется конкретная модель развития сети (или модель персептрона), сеть сугобо комплексного характера в зависимости от задач которые она призвана решать.
Развитие происходит очень скачкообразно: сначало кажется что это полный рандом, а потом как прорвёт (ресурсов ест намного меньше чем простая сеть).
2 klakhman класный послужной список, а я ещё только учусь…
Ах да совсем забыл про сохранение образов. В зависимости от организации функциональной и образной памяти можно явно ускорить процесы обучения в разы,
именно поэтому я перестал их различать и стараюсь впихнуть в общий критерий и модель.
Ну по-поводу мифа 1. POC г03етко
И это не первый случай, самым первым был какой-то писатель — ему прямо в язык впихнули провода =) (да да терминафтары DeusEx и аnti_trollmode негодуют)
Миф 2. Я же сказал что в 80% случаев возможно востановление (возможно и не полное)
а вот отрезать кусок который отвечает за востановление «всего» довольно сложно,
так как много резать придётся и в правой и в левой доле,
в мозгах нет разницы между сохранением критериев оценки образа и способами его обработки, способы обработки являются непосредственно инкапсулироваными в абстрактный образ.
Генетические алгоритмы имеют непосредственное отношение к процесам обучения и формированию абстрактных образов. Дело в том что мозг явно не использует шум нейронной сети для формирования творческого начала, шум в даном случае это рандомная последовательность переборки образов (возможно и несовместимых) которые используются в неком подобии генетического алгоритма для формирования новых образов как и способов решения практических задач. Вот почему в системах обучения крыс и роботов есть различия в обратной связи с уже накопленной информацией
(хабротопик тут).
Сейчас я занимаюсь вопросом создания динамической нейросети, наподобие мозгов, с нуля.
Уже многое реализовано, потрачено где-то 2-3 года, на основе этого всего я пишу самооптимизрующийся язык програмирования. Результаты довольно неплохие, а исходники и иследования закрыты. =) всё будет OpenSource только когда выйду с альфы, исходники самого языка будут максимально закрыты до первой стабильной продукции.
хм… Комрады и донат приветствуются.
По поводу апаратной части могу сказать одно: прототипы уже есть, фины или шведы, кароч северные варвары, уже создавали проц. на чисто генетических алгоритмах и neurofuzzy logic'е. Правдо им обрезали поставки Удмурдских Ежей в связи с чем они не смогли дальше использовать иглы Удмурдского Ежа для рисования на silicon'овых камнях (литографии)
Я вот только не пойму если они хотят отказоустойчивости пускай используют голографическую модель, никто вроде её не развивал в таком ракурсе, насколько мне известно.
Попробую объяснить что я имею в виду.
Не знаю как оно в жизни называется, я очень частично знаком с темой нейронных сетей
(с алгоритмической точки зрения), но вот если отрезать кусок мозгов то это не означает что:
[Миф 1] Мозг станет менее функционален (хм зависит от размера самого куска).
Мозг очень эластичная весч, вот я где-то читал, в какой-то буржуйской книге, что американцы слепому в нерв языка камеру вставляли, и ничего мозги приспосабливались, правда изображение чёрно-белое было только.
antitroll_mode on
если кому интересно можете погуглить…
[Миф 2] Мозг потеряет кусок памяти при нарезке и подальшем приготовлении.
Дело в том что информация храниться не конкретно «где-то» в мозгу, а по чётким и нечётким критериям во всей коре (иль глубже, я не биолог), которые могут быть востановлены друг от друга в 80% случаев потери. Все эти критерии одновременно учавствуют в процесе обучения формируя так называемую динамическию петлю, или мего-генератор популяции для чего-то вроде ген. алгоритма.
Так вот основываясь на этих понятиях уже можно отталкиваться и творить что-то новое, а не формировать макросистему на основе микросистемы (в даной задаче очень избыточно), на основе «статических, негибких» моделей сетей, которые не предполагают самомодификаций…
Оптические нейронные сети на голографических кореляторах уже есть. Часто первой аналогией являются класические модели Хопфилда и Коско, но это всё не то что нужно, ибо по самой задумке модель должна менять свою структуру.
я бы прикручивал genetic fuzzy systems к определению связей и их деструкции так бы было проще…
в журналах ieee уже в 2009 об этом писали. MIT использовали сеть подобного рода (она была нечёткая, а не частотная) для интерполяции полиномиальныхъ алгоритмов — задача синтеза логарифмического алгоритма с существующих полиномиальных… ну кароч я долго могу продолжать. Почитайте тётю Рутковскую Нейронные сети генетические алгоритмы и нечеткие системы + журналы ieeе как реальные реализации этой гадости в продакшине да они самообучающиеся и полны Матана =)
если что — пишите. Я в принципе сейчас тоже формирую систему самообучающихся сетей на основе «самодатамайнинга» и ген. алгоритмов. хочу повторить успех MIT.
По-поводу смысла… лутше смотреть поглубже и вспомнить о том что говорила Эшлинг в начале мультфильма про саму книгу и чем именно ей пришлось пожертвовать ради кристала-«глаза».
Книга не могла защитить абатство, но она могла дать надежду и поддержать людей в самый трудный час.
Вчера слил этот мульт с рутрекера — посмотрел, офигел, и понял что я почти не умею рисовать.
Качество выполнения самого мультфильма превосходное. Сюжет довольно неплохой — «советский» с моралью. Хоть что-то что можно показать ребёнку и не думать про насилие, пошлость и т.д. чем собственно пропахлись америкоские мульты. Люди забыли что мультики — для детей, и они должны дублировать сказку что бы учить морали, я уже молчу про эстетическое образование. С этой точки зрения, качество мультфильма где каждый кадр можно смотреть по пол часа… (тролям — почти каждый кадр) Это не в какое сравнение не вписывается ни с америкосами, ни с японцами, а у них, кстати, самое главное — создать искуственный мир полон приключений, а не воспитывать мораль.
У кого есть дети — этот мультфильм как раз для них, а не для вас =) родителей.
Я бы даже сказал что идеология Сt является частным случаем Лямбда и Pi функционального подхода. Помните старый, добрый Erlang?- Там всё есть процес и всё есть рекурсия,
самое класное что все переменные read only. Эти факторы избавляют данный подход от всех побочных эфектов распределённых систем, типо приоритетов, data race conditions и тому подобных.
Но кто отменял этот подход относительно С++? (ну разве что относительно переменных =) )
Я думаю что подобное движение только в пользу культуре програмирования, которая, по-моему в данный момент немного отошла на задний план.
Лично я использую openCL + openMP
Иногда для меня очень важна скорость и подключение внешних библиотек типа CUDA и TBB не самое оптимальное решения подобных задач.
А в чём отличие OpenMP от Intel TBB?..
Просто Intel Ct является набором абстракций функционального програмирования для реализации отсутствия побочных еффектов. Jit нужен для того что-бы подогнать код под конкретный GPU или CPU камень. Если Intel TBB это человеческий OpenMP для процессора СРU, то Intel Ct относится как к GPU так и к CPU.
Я думаю что тенденция Intel Ct повторится как и с Intel TBB:
1) Заработают денег — сделают ОпенСорсной
2) Не заработают денег — тоже сделают ОпенСорсной
Так что нам, товарищи, как бы и все карты в руки…
Опять новая всежрущая библиотека распределенного програмирования, или очередной загруженый баян? Поживём — увидим.
Да видимо что про iproute на хабре инфы маловато
вот только это и вообщем-то всё.
Что выбрать HTB или CBQ? — это старый холивар.
С другой стороны пользоваться одним htbinit'ом или cbqinit'ом можно.
Но настоящую гибкость даёт чистый iproute. Правда инфа про него слижком уж замысловата.
Вспомним один только lartc
Думаю стоит преобразить даный утиль в хаброформат, ибо для /dev/habruman он не совсем съедобный.
Много чего думаем… Лично я занимаюсь разработкой ОСей. Особенно шедулеров и протоколов.
Хочу купить Marvell Armad'у 1000 и проJtag'нуть её.
Про многоядерные решения в телефонах… Ну это ещё нада подождать.
Хотя тактико-технические характеристики современных фонов вполне позволяют поставить туда эдакий многоголовый ARM. Ну опять-же всё дело в ОСях и бюджете.
Сколько это будет стоить?
И как это всё будет портироваться?
Нужно же похвастаться несуществующей гравицапой Пепелаца,
которая будет зделана тогда, не понятно когда.
Это простой маркетинговый ход для PRа wm7 И всё.
Вы действительно верите, что переключения контекстов и синхронизация убьют производительность гигагерцового процессора на телефоне?
Если бы не считал и не дизасамблировал, то не верил бы.
Про far jmp вообще не понял, в чем сложность занесения в регистр счетчика команд целого числа?
Сложность только в количестве тактов которое потребуется для этой самой записи и перехода.
В больших циклах с ветвлениями, если это планарный способ организации многозадачности, есть 3Кг этих самых джампов, а с страницы на страницу перепрыгивать ими слишком болезненно, иногда даже лутше задавать это через векторы прерывания.
Уважаемые пользователи, многозадачность вам не нужна, иначе миллиардную цифру в числе «пи» вы сможете получить на 2 минуты позже пользователей iPhone.
Многозадачность нужна только с нормальным шедуллером и таск менеджером которые ориентированы на конкретную платформу.
Лично как по мне производительная многозадачность это миф.
1) Мало кто помнит закон Амдала — закон про то что на четырёхядерном процессоре вы получите прирост меньший чем четыре раза (я точно не помню формулы, но по-моему 3,5 раза).
А при бесконечном числе ядер этот прирост будет стремится к 1. =)
2)Системы основаные на прерываниях, так называемые матричные шедуллеры имеют плохую аппаратную поддержку. Прерывания в этом случае «едят» многовато процессорных тактов. Даже куча простых jmp'ов могут сильно влиять на производительность, и далеко не каждый компилятор это всё оптимизирует. Я уже не говорю про кэширование процессора read-ahead. То-есть запустили две программы — это не означает что один общий 1ГГц поделится на 500МГц, тут огромную роль играют шедуллеры, task менеджеры, и прочая ересь которая ест до 10-30% производительности.
3) Если это телефон — то это RISC процессор аля ARM. В его случае вообще нежелательно делать много far jmp'ов, и темболее вызовов прерываний, ибо они едят от 5-ти до 10 тактов проца.
4) Системы с планарными шедулерами и таск менеджерами есть в ОСях типа QNX, это такие которые на ядерных електростанциях стоят.
Системы с генетическими нечёткими шедулерами…
Ом… в природе их нет — они есть на калькуляторе, и у меня в блокноте =)
Так что как видете есть два «основных» способа решения многозадачности это планарный и матричный. Если мелкософт будет реалировать это всё дело в «золотой середине» — это будет довольно интересное решение. У меня остаёться лишь единственное сомнение, по-поводу хорошей апаратной поддержки для АRM'ов. А так удачи мелкомягким.
ну + под cygwin GCC 4.4.3… утопично как то… Вы так ну думаете?
cygwin + MinGW всегда будут отставать от актуальной версии GCC
и вот почему под недоОсью его нет и не будет.
Всё эти ошибки зависят от компилятора…
Не хочу юзать холивар. Но GCC гораздо «оптимистичнее» использовать в плане 64-битных разработок.
Проблем явно меньше. И они не такие «весёлые». Плохо только что под недоОсь его нет =)
Надеюсь что и не будет.
Ну давайте минусуйте… минусуйте…
Типо я не прав?..
Там такого барахла хватает не спорю, но это первое что мне показалось похожее на тему. Если очень интересно могу дать конкретно книгу по МайндХаку где это всё написано. Динамические цепи они такие динамичиские =)
Идеей алгоритма динамических цепей является самооптимизация на основе ген. алгоритма и подальшей модификации фитнес функции через neuro-fuzzy logic.
Сам себе швец и жнец и учитель. На основе динамической цепи можно
спокойно строить такой же (а может и более) динамический апарат нейронной сети.
Вот собственно этим я и занимаюсь. Просто в моём случае не используется конкретная модель развития сети (или модель персептрона), сеть сугобо комплексного характера в зависимости от задач которые она призвана решать.
Развитие происходит очень скачкообразно: сначало кажется что это полный рандом, а потом как прорвёт (ресурсов ест намного меньше чем простая сеть).
2 klakhman класный послужной список, а я ещё только учусь…
Ах да совсем забыл про сохранение образов. В зависимости от организации функциональной и образной памяти можно явно ускорить процесы обучения в разы,
именно поэтому я перестал их различать и стараюсь впихнуть в общий критерий и модель.
И это не первый случай, самым первым был какой-то писатель — ему прямо в язык впихнули провода =) (да да терминафтары DeusEx и аnti_trollmode негодуют)
Миф 2. Я же сказал что в 80% случаев возможно востановление (возможно и не полное)
а вот отрезать кусок который отвечает за востановление «всего» довольно сложно,
так как много резать придётся и в правой и в левой доле,
в мозгах нет разницы между сохранением критериев оценки образа и способами его обработки, способы обработки являются непосредственно инкапсулироваными в абстрактный образ.
Генетические алгоритмы имеют непосредственное отношение к процесам обучения и формированию абстрактных образов. Дело в том что мозг явно не использует шум нейронной сети для формирования творческого начала, шум в даном случае это рандомная последовательность переборки образов (возможно и несовместимых) которые используются в неком подобии генетического алгоритма для формирования новых образов как и способов решения практических задач. Вот почему в системах обучения крыс и роботов есть различия в обратной связи с уже накопленной информацией
(хабротопик тут).
Сейчас я занимаюсь вопросом создания динамической нейросети, наподобие мозгов, с нуля.
Уже многое реализовано, потрачено где-то 2-3 года, на основе этого всего я пишу самооптимизрующийся язык програмирования. Результаты довольно неплохие, а исходники и иследования закрыты. =) всё будет OpenSource только когда выйду с альфы, исходники самого языка будут максимально закрыты до первой стабильной продукции.
хм… Комрады и донат приветствуются.
По поводу апаратной части могу сказать одно: прототипы уже есть, фины или шведы, кароч северные варвары, уже создавали проц. на чисто генетических алгоритмах и neurofuzzy logic'е. Правдо им обрезали поставки Удмурдских Ежей в связи с чем они не смогли дальше использовать иглы Удмурдского Ежа для рисования на silicon'овых камнях (литографии)
P.S. Для slowpoke'ов Удмурдский Еж это У.Е.
Попробую объяснить что я имею в виду.
Не знаю как оно в жизни называется, я очень частично знаком с темой нейронных сетей
(с алгоритмической точки зрения), но вот если отрезать кусок мозгов то это не означает что:
[Миф 1] Мозг станет менее функционален (хм зависит от размера самого куска).
Мозг очень эластичная весч, вот я где-то читал, в какой-то буржуйской книге, что американцы слепому в нерв языка камеру вставляли, и ничего мозги приспосабливались, правда изображение чёрно-белое было только.
antitroll_mode on
если кому интересно можете погуглить…
[Миф 2] Мозг потеряет кусок памяти при нарезке и подальшем приготовлении.
Дело в том что информация храниться не конкретно «где-то» в мозгу, а по чётким и нечётким критериям во всей коре (иль глубже, я не биолог), которые могут быть востановлены друг от друга в 80% случаев потери. Все эти критерии одновременно учавствуют в процесе обучения формируя так называемую динамическию петлю, или мего-генератор популяции для чего-то вроде ген. алгоритма.
Так вот основываясь на этих понятиях уже можно отталкиваться и творить что-то новое, а не формировать макросистему на основе микросистемы (в даной задаче очень избыточно), на основе «статических, негибких» моделей сетей, которые не предполагают самомодификаций…
Оптические нейронные сети на голографических кореляторах уже есть. Часто первой аналогией являются класические модели Хопфилда и Коско, но это всё не то что нужно, ибо по самой задумке модель должна менять свою структуру.
в журналах ieee уже в 2009 об этом писали. MIT использовали сеть подобного рода (она была нечёткая, а не частотная) для интерполяции полиномиальныхъ алгоритмов — задача синтеза логарифмического алгоритма с существующих полиномиальных… ну кароч я долго могу продолжать. Почитайте тётю Рутковскую Нейронные сети генетические алгоритмы и нечеткие системы + журналы ieeе как реальные реализации этой гадости в продакшине да они самообучающиеся и полны Матана =)
если что — пишите. Я в принципе сейчас тоже формирую систему самообучающихся сетей на основе «самодатамайнинга» и ген. алгоритмов. хочу повторить успех MIT.
Книга не могла защитить абатство, но она могла дать надежду и поддержать людей в самый трудный час.
Качество выполнения самого мультфильма превосходное. Сюжет довольно неплохой — «советский» с моралью. Хоть что-то что можно показать ребёнку и не думать про насилие, пошлость и т.д. чем собственно пропахлись америкоские мульты. Люди забыли что мультики — для детей, и они должны дублировать сказку что бы учить морали, я уже молчу про эстетическое образование. С этой точки зрения, качество мультфильма где каждый кадр можно смотреть по пол часа… (тролям — почти каждый кадр) Это не в какое сравнение не вписывается ни с америкосами, ни с японцами, а у них, кстати, самое главное — создать искуственный мир полон приключений, а не воспитывать мораль.
У кого есть дети — этот мультфильм как раз для них, а не для вас =) родителей.
самое класное что все переменные read only. Эти факторы избавляют данный подход от всех побочных эфектов распределённых систем, типо приоритетов, data race conditions и тому подобных.
Но кто отменял этот подход относительно С++? (ну разве что относительно переменных =) )
Я думаю что подобное движение только в пользу культуре програмирования, которая, по-моему в данный момент немного отошла на задний план.
Лично я использую openCL + openMP
Иногда для меня очень важна скорость и подключение внешних библиотек типа CUDA и TBB не самое оптимальное решения подобных задач.
Просто Intel Ct является набором абстракций функционального програмирования для реализации отсутствия побочных еффектов. Jit нужен для того что-бы подогнать код под конкретный GPU или CPU камень. Если Intel TBB это человеческий OpenMP для процессора СРU, то Intel Ct относится как к GPU так и к CPU.
Я думаю что тенденция Intel Ct повторится как и с Intel TBB:
1) Заработают денег — сделают ОпенСорсной
2) Не заработают денег — тоже сделают ОпенСорсной
Так что нам, товарищи, как бы и все карты в руки…
Опять новая всежрущая библиотека распределенного програмирования, или очередной загруженый баян? Поживём — увидим.
вот только это и вообщем-то всё.
Что выбрать HTB или CBQ? — это старый холивар.
С другой стороны пользоваться одним htbinit'ом или cbqinit'ом можно.
Но настоящую гибкость даёт чистый iproute. Правда инфа про него слижком уж замысловата.
Вспомним один только lartc
Думаю стоит преобразить даный утиль в хаброформат, ибо для /dev/habruman он не совсем съедобный.
Хочу купить Marvell Armad'у 1000 и проJtag'нуть её.
Про многоядерные решения в телефонах… Ну это ещё нада подождать.
Хотя тактико-технические характеристики современных фонов вполне позволяют поставить туда эдакий многоголовый ARM. Ну опять-же всё дело в ОСях и бюджете.
Сколько это будет стоить?
И как это всё будет портироваться?
которая будет зделана тогда, не понятно когда.
Это простой маркетинговый ход для PRа wm7 И всё.
Если бы не считал и не дизасамблировал, то не верил бы.
Про far jmp вообще не понял, в чем сложность занесения в регистр счетчика команд целого числа?
Сложность только в количестве тактов которое потребуется для этой самой записи и перехода.
В больших циклах с ветвлениями, если это планарный способ организации многозадачности, есть 3Кг этих самых джампов, а с страницы на страницу перепрыгивать ими слишком болезненно, иногда даже лутше задавать это через векторы прерывания.
Уважаемые пользователи, многозадачность вам не нужна, иначе миллиардную цифру в числе «пи» вы сможете получить на 2 минуты позже пользователей iPhone.
Многозадачность нужна только с нормальным шедуллером и таск менеджером которые ориентированы на конкретную платформу.
1) Мало кто помнит закон Амдала — закон про то что на четырёхядерном процессоре вы получите прирост меньший чем четыре раза (я точно не помню формулы, но по-моему 3,5 раза).
А при бесконечном числе ядер этот прирост будет стремится к 1. =)
2)Системы основаные на прерываниях, так называемые матричные шедуллеры имеют плохую аппаратную поддержку. Прерывания в этом случае «едят» многовато процессорных тактов. Даже куча простых jmp'ов могут сильно влиять на производительность, и далеко не каждый компилятор это всё оптимизирует. Я уже не говорю про кэширование процессора read-ahead. То-есть запустили две программы — это не означает что один общий 1ГГц поделится на 500МГц, тут огромную роль играют шедуллеры, task менеджеры, и прочая ересь которая ест до 10-30% производительности.
3) Если это телефон — то это RISC процессор аля ARM. В его случае вообще нежелательно делать много far jmp'ов, и темболее вызовов прерываний, ибо они едят от 5-ти до 10 тактов проца.
4) Системы с планарными шедулерами и таск менеджерами есть в ОСях типа QNX, это такие которые на ядерных електростанциях стоят.
Системы с генетическими нечёткими шедулерами…
Ом… в природе их нет — они есть на калькуляторе, и у меня в блокноте =)
Так что как видете есть два «основных» способа решения многозадачности это планарный и матричный. Если мелкософт будет реалировать это всё дело в «золотой середине» — это будет довольно интересное решение. У меня остаёться лишь единственное сомнение, по-поводу хорошей апаратной поддержки для АRM'ов. А так удачи мелкомягким.
cygwin + MinGW всегда будут отставать от актуальной версии GCC
и вот почему под недоОсью его нет и не будет.
и за компилятор я єто не считаю
Не хочу юзать холивар. Но GCC гораздо «оптимистичнее» использовать в плане 64-битных разработок.
Проблем явно меньше. И они не такие «весёлые». Плохо только что под недоОсь его нет =)
Надеюсь что и не будет.
Ну давайте минусуйте… минусуйте…
Типо я не прав?..