Основная проблема у это GPT-X, что там все не правильно сделали.
Для примера, человек не в силах в разумные сроки прочитать терабайт текста, но тем не менее многие задачи решает умнее чем эта сетка.
Чтобы учить сетку, в ней гоняют один и тот же текст много раз, пока эти знания вградиетиваются в нее. Человеку достаточно прочитать текст один раз, что бы это понять и использовать, но у него проблема с памятью.
В общем, сетка берет количеством, и ей даже терабайтов мало. А человек учится качеством, по крайней мере относительно сеток. Значит принципы обучения у человека несколько иные, чем у нейронной сетки.
Вот кажется, что человек дает ответы гораздо правильнее и реже ошибаются. Но мало кто думает, что человек чаще отвечает лишь тогда, когда знает ответ.
А этого чат-бота вынуждают отвечать, даже тогда, когда он не знает ответа. И если человека поставить в такую же ситуацию, то он будет давать ответы не лучше... Вспоминаем, какую чушь может нести человек на экзаменах, когда не знает предмета, или на собеседованиях, когда идет на место, в котором плохо разбирается. Как пытается связать не связываемые слова, что бы ответ был похож на правильный.
Часто упоминают, что чат-бот дает много ошибочных ответов. Но при этом забывают сравнить, а сколько не правильных ответов дает человек. На программистких форумах часто новички говорят чушь, да с опытом иногда промахиваются.
Когда говорят, что этот чат-бот не понимает, что такое правильный ответ, то так же забывают задуматься, а почему когда человек дает не правильный ответ, у него так же не возникает мысли, что его ответ не правилен.
Проблема не в том, что оно не может сейчас отвечать на вопросы. Проблема будет когда она сможет отвечать на вопросы и решать их лучше чем человек. Это лишь вопрос времени и качества алгоритмов выискивающих закономерности и их комбинаций. Что тогда останется делать человеку? Эволюционировать в овощ снабженный пищеварительным трактом? Или менять свой мозг на электронный процессор, оставив от органики опять же пищеварительный тракт? Да и этот тракт это то же лишняя деталь.
В интсрументе разработки у 1С очень много мелочей, которые неудобны своим количеством таковых. Они не сильно препятствуют разработке, скорее ее замедляют. Исправить их было бы легко, если бы на то было желание. Контора 1С предпочитает добавить какое-нибудь новое свойство, но не исправляет прежние. Там в конфигураторе то там, то сям криво нажимаются кнопки, сортировки работают выбиваясь из общей схемы или не работают, поиски самые тормозные какие я где-либо видел, и т.д., и т.п… Контора 1С не стремится сделать свой продукт хотя бы на чуть-чуть удобней в мелочах которые сделать легко. Они шевелиться будут только если появится конкурентный продукт. Сделать таковой не слишком сложно, но существенной прибыли на этом не получишь, потому что монополию от 1С перешагнуть будет сложно. Поэтому никто этим не занимается, кроме фанатов. Поэтому платформа 1С будет оставаться скучной.
Будет интересно прочитать следующую статью. Но тем не менее.
У меня отец был крановщиком, и жаловался на те же проблемы, на которые жалуются программисты — глаза и голова. А мониторов тогда в кранах не было точно. Это может болеть от зрительного напряжения, от избыточной и резкой освещености, от переизбытка кофе и сладкого или алкоголя, от переизбытка эмоций, от возраста. И любое из выше перечисленного усиливается забитостью и ослабленностью сосудов. А у некоторых эти вещи болят вообще без видимой связи с другими проблемами.
Врач условно говорит: я не знаю причин, и выяснение причины это долгий и дорогой процесс, и пациент на это может не пойдет, а по пути еще и не договаривать будет. А следствие известно, так что пока не знаем причины, будем лечить следствие. Если конечно врачу не просто пофиг и он в принципе может лечить. Ну и плюс они перестраховываются.
Вы же говорите, я изучаю проблему болячки от спектра света, я ее знаю и понимаю, значит у всех у кого болит, должно болеть именно от мною изученной темы. И всем нужно лечить именно эту причину.
В некоторых случаях действительно проще самому искать и перебирать возможные причины, если это доступный процесс — по средствам, по условиям и по доступности понимания процессов. А не дожидаться ответа от врача.
Глаза устают не только от типа освещения, но и просто от любой работы где нужно внимательно смотреть. Врачи рекомендуют разминки, зарядки для глаз, массаж для глаз. 5-10 минут аккуратно поразминать пальцами.
Я потихоньку занимаюсь разработкой алгоритмов поиска закономерностей в текстах без нейронок. Что я могу сказать: там есть структуры. Для изображений там должны быть алгоритмы отчасти похожи.
Алгоритмы такие работают очень быстро относительно нейронок. Эффективность выделения структур такими алгоритмами, логически рассуждая, выше чем у нейронок, просто потому, что точные алгоритмы всегда эффективней нейронок, если таковые сумели сделать. Это как расчет корелляции или МНК, производится за один проход и находится лучший вариант, вместо много-итерационного подхода у нейронок.
Проблема таких алгоритмов в том, что структура закономерности может быть любой конфигурации, а точный алгоритм работает лишь под определенную заложенную заранее структуру. Соответственно нужно создать достаточно много вариантов сканирования закономерностей.
Люди не любят читать сложности, особенно если это не связано с их текущей деятельностью. Но любят читать зрелищное, для впечатлений. Или злободневное. Поэтому существенно позновательное не набирает рейтинга.
Программировать не сложно. Сложно делать это лучше чем другие. Чем дальше хочешь забраться, чем больше хочешь получать за это или от этого, тем сложнее.
Если обновление выходило в 2014 году и в разделе Issue вереница не отвеченных сообщений до текущей даты, все реже и реже, и последние уже писались без надежды на ответ.
Потому что иначе оно делается так как решат разработчики компилятора. Ничем не запрещается им ее не инлайнить. С чего Вы взяли, что все лямбды обязательно инлайны? Я вот на 99% уверен, что при компиляции в отладочном режиме лямбды не инлайнятся. Опять же, зависит от компилятора.
Для уникального типа компилятор может решать инлайнить лямбду или нет.
Он может это решать для любого типа, если это не ограничено стандартом или какими-либо проблемами реализации.
А вот и нет. Нету там указателя на код, в том-то и фокус!
Лямбда замечательно организовывается в любые рекурсии. Не хвостовую рекурсию никак не заинлайнишь. Хотя указателя на код здесь не нужен, он вкомпиливается в код, а не в структуру. Если бы разработчикам компилятора было нужно по другому, им это стандарт не запрещает. Но указатель на код все равно есть, и это свойство используется в std::function.
struct Node {
Node* less = nullptr;
Node* more = nullptr;
};
Node* root = ...;
std::function<int(Node*)> countNodes = [&](Node* node) -> int {
int result = 1;
if (node->less) result += countNodes(node->less);
if (node->more) result += countNodes(node->more);
return result;
};
std::cout << "countNodes" << countNodes(root) << std::endl;
В том-то и дело, что в С++ лямбды не являются указателями. Они по значению передаются.
Лямбды могут передаваться и по значению, и по ссылке, ровно так же как и прочие типы. Например вот так это сделается по ссылке:
void sort(auto begin, auto end, const auto& compare)
Но фактически это все равно будет ровно так, как решит оптимизатор компилятора, при условии что его решение не противоречит какому-либо утверждению в стандарте. В каком стандарте Вы видели, что лямбда должна обязательно инлайниться? Я такого не видел, хотя специально не высматривал.
Соответсвенно, вызов:
void sort(auto begin, auto end, auto compare)
Будет вести себя как при передаче по значению, для любого типа компаратора.
Лямбда на техническом уровне представляет структуру, с сохраненными в ней указателем на код и значениями замыкания (и это кажется было в стандарте). В случае передачи ее по ссылке, передается ссылка на эту техническую структуру. В случае передачи по значению — каждый раз она копируется.
И от этих значений, вероятно, можно брать указатели, которые будут одинаковыми до вызова и внутри вызова, в случае если передаче по ссылке. И разными при передачи по значению — согласно стандарту.
И если не будет ни одного обращения к лямбде взятия от нее указателя, то оптимизатор будет поступать с ней так, как ему захочется в обоих случаях.
Я по прежнему не понимаю, в чем проблемность типов описанных синтаксисом, что они принципиально отличаются от типов compile time.
Не совсем понятно, что такое косвенный и прямой вызовы относительно лямбд?
И не понятно, чем существенно отличается указатель на уникальный тип, который нельзя объявить синтаксисом, от прочих описываемых синтаксисом указателей. И то и другое 8 байт. И если действия соответствующие нужному вызову могут быть логично описаны правилами, то последующая компиляция это уже весьма конечный и определенный вопрос реализации компилятора.
Инлайнить ли функции и лямбды, компиляторы уже давно определяют это самостоятельно в зависимости от контекста. Например, лямбду можно вызывать рекурсионно, используя std::function. В этом случае, она никак не инлайн и внутри std::function сохраняется как указатель.
Вопрос, почему так изначально заложили? Почему нужно использовать костыль типа std::function, вместо того, что бы лямбды имели сразу подобные сигнатуры. Для этого были какие-то ограничения? Тип указателя на функцию замечательно работает и имеет определяемую сигнатуру независимо от значения. Чем не устроил тип указателя на лямбды по подобной же схеме? В момент появления стандарта про лямбды, до этого не было лямбд или чего-либо подобного, поэтому ограничений по обратной совместимости быть не должно было. Зачем было так все портить?
Да и сейчас, почему бы не сделать, что в указатель на функцию, можно было бы разместить указатель на лямбду? Что этому мешает, и какие против этого причины?
Все языки программирования имеют свои собственные форматы вызова функций, если только обратное не закладывалось заранее в этот язык. И эти форматы оптимальны пока используются в рамках этого языка. А между разными языками вызовы прорабатываются отдельно и создаются отдельные стандарты и форматы.
Ваш пример не оптимален для С++, поскольку не удобно поддерживать различные параметры вызова. std::function это шаблонная структура, как раз предком которой могла бы быть структура подобная Вашей.
И Ваш пример не будет универсальным для вызовов сторонними языками, т.к. как они каждый специфичен.
При этом использование std::function действительно чуть медленнее, но не существенно. Основные тормоза буду, если будет void a(std::function<void()> fn), особенно при рекурсиях, т.к. объект std::function будет каждый раз конструироваться, и в довесок занимать лишние ~32 байта в стеке, против 8 байт, если передается по ссылке.
Основная проблема у это GPT-X, что там все не правильно сделали.
Для примера, человек не в силах в разумные сроки прочитать терабайт текста, но тем не менее многие задачи решает умнее чем эта сетка.
Чтобы учить сетку, в ней гоняют один и тот же текст много раз, пока эти знания вградиетиваются в нее. Человеку достаточно прочитать текст один раз, что бы это понять и использовать, но у него проблема с памятью.
В общем, сетка берет количеством, и ей даже терабайтов мало. А человек учится качеством, по крайней мере относительно сеток. Значит принципы обучения у человека несколько иные, чем у нейронной сетки.
У нас космические шатлы взрываются из-за ошибок в программах, при всем обилии тестов для их кода...
Вот кажется, что человек дает ответы гораздо правильнее и реже ошибаются. Но мало кто думает, что человек чаще отвечает лишь тогда, когда знает ответ.
А этого чат-бота вынуждают отвечать, даже тогда, когда он не знает ответа. И если человека поставить в такую же ситуацию, то он будет давать ответы не лучше... Вспоминаем, какую чушь может нести человек на экзаменах, когда не знает предмета, или на собеседованиях, когда идет на место, в котором плохо разбирается. Как пытается связать не связываемые слова, что бы ответ был похож на правильный.
Часто упоминают, что чат-бот дает много ошибочных ответов. Но при этом забывают сравнить, а сколько не правильных ответов дает человек. На программистких форумах часто новички говорят чушь, да с опытом иногда промахиваются.
Когда говорят, что этот чат-бот не понимает, что такое правильный ответ, то так же забывают задуматься, а почему когда человек дает не правильный ответ, у него так же не возникает мысли, что его ответ не правилен.
Проблема не в том, что оно не может сейчас отвечать на вопросы. Проблема будет когда она сможет отвечать на вопросы и решать их лучше чем человек. Это лишь вопрос времени и качества алгоритмов выискивающих закономерности и их комбинаций. Что тогда останется делать человеку? Эволюционировать в овощ снабженный пищеварительным трактом? Или менять свой мозг на электронный процессор, оставив от органики опять же пищеварительный тракт? Да и этот тракт это то же лишняя деталь.
У меня отец был крановщиком, и жаловался на те же проблемы, на которые жалуются программисты — глаза и голова. А мониторов тогда в кранах не было точно. Это может болеть от зрительного напряжения, от избыточной и резкой освещености, от переизбытка кофе и сладкого или алкоголя, от переизбытка эмоций, от возраста. И любое из выше перечисленного усиливается забитостью и ослабленностью сосудов. А у некоторых эти вещи болят вообще без видимой связи с другими проблемами.
Врач условно говорит: я не знаю причин, и выяснение причины это долгий и дорогой процесс, и пациент на это может не пойдет, а по пути еще и не договаривать будет. А следствие известно, так что пока не знаем причины, будем лечить следствие. Если конечно врачу не просто пофиг и он в принципе может лечить. Ну и плюс они перестраховываются.
Вы же говорите, я изучаю проблему болячки от спектра света, я ее знаю и понимаю, значит у всех у кого болит, должно болеть именно от мною изученной темы. И всем нужно лечить именно эту причину.
В некоторых случаях действительно проще самому искать и перебирать возможные причины, если это доступный процесс — по средствам, по условиям и по доступности понимания процессов. А не дожидаться ответа от врача.
Алгоритмы такие работают очень быстро относительно нейронок. Эффективность выделения структур такими алгоритмами, логически рассуждая, выше чем у нейронок, просто потому, что точные алгоритмы всегда эффективней нейронок, если таковые сумели сделать. Это как расчет корелляции или МНК, производится за один проход и находится лучший вариант, вместо много-итерационного подхода у нейронок.
Проблема таких алгоритмов в том, что структура закономерности может быть любой конфигурации, а точный алгоритм работает лишь под определенную заложенную заранее структуру. Соответственно нужно создать достаточно много вариантов сканирования закономерностей.
Если обновление выходило в 2014 году и в разделе Issue вереница не отвеченных сообщений до текущей даты, все реже и реже, и последние уже писались без надежды на ответ.
Потому что иначе оно делается так как решат разработчики компилятора. Ничем не запрещается им ее не инлайнить. С чего Вы взяли, что все лямбды обязательно инлайны? Я вот на 99% уверен, что при компиляции в отладочном режиме лямбды не инлайнятся. Опять же, зависит от компилятора.
Он может это решать для любого типа, если это не ограничено стандартом или какими-либо проблемами реализации.
Лямбда замечательно организовывается в любые рекурсии. Не хвостовую рекурсию никак не заинлайнишь. Хотя указателя на код здесь не нужен, он вкомпиливается в код, а не в структуру. Если бы разработчикам компилятора было нужно по другому, им это стандарт не запрещает. Но указатель на код все равно есть, и это свойство используется в std::function.
Лямбды могут передаваться и по значению, и по ссылке, ровно так же как и прочие типы. Например вот так это сделается по ссылке:
Но фактически это все равно будет ровно так, как решит оптимизатор компилятора, при условии что его решение не противоречит какому-либо утверждению в стандарте. В каком стандарте Вы видели, что лямбда должна обязательно инлайниться? Я такого не видел, хотя специально не высматривал.
Соответсвенно, вызов:
Будет вести себя как при передаче по значению, для любого типа компаратора.
Лямбда на техническом уровне представляет структуру, с сохраненными в ней указателем на код и значениями замыкания (и это кажется было в стандарте). В случае передачи ее по ссылке, передается ссылка на эту техническую структуру. В случае передачи по значению — каждый раз она копируется.
И от этих значений, вероятно, можно брать указатели, которые будут одинаковыми до вызова и внутри вызова, в случае если передаче по ссылке. И разными при передачи по значению — согласно стандарту.
И если не будет ни одного обращения к лямбде взятия от нее указателя, то оптимизатор будет поступать с ней так, как ему захочется в обоих случаях.
Я по прежнему не понимаю, в чем проблемность типов описанных синтаксисом, что они принципиально отличаются от типов compile time.
Не совсем понятно, что такое косвенный и прямой вызовы относительно лямбд?
И не понятно, чем существенно отличается указатель на уникальный тип, который нельзя объявить синтаксисом, от прочих описываемых синтаксисом указателей. И то и другое 8 байт. И если действия соответствующие нужному вызову могут быть логично описаны правилами, то последующая компиляция это уже весьма конечный и определенный вопрос реализации компилятора.
Инлайнить ли функции и лямбды, компиляторы уже давно определяют это самостоятельно в зависимости от контекста. Например, лямбду можно вызывать рекурсионно, используя std::function. В этом случае, она никак не инлайн и внутри std::function сохраняется как указатель.
Вопрос, почему так изначально заложили? Почему нужно использовать костыль типа std::function, вместо того, что бы лямбды имели сразу подобные сигнатуры. Для этого были какие-то ограничения? Тип указателя на функцию замечательно работает и имеет определяемую сигнатуру независимо от значения. Чем не устроил тип указателя на лямбды по подобной же схеме? В момент появления стандарта про лямбды, до этого не было лямбд или чего-либо подобного, поэтому ограничений по обратной совместимости быть не должно было. Зачем было так все портить?
Да и сейчас, почему бы не сделать, что в указатель на функцию, можно было бы разместить указатель на лямбду? Что этому мешает, и какие против этого причины?
Все языки программирования имеют свои собственные форматы вызова функций, если только обратное не закладывалось заранее в этот язык. И эти форматы оптимальны пока используются в рамках этого языка. А между разными языками вызовы прорабатываются отдельно и создаются отдельные стандарты и форматы.
Ваш пример не оптимален для С++, поскольку не удобно поддерживать различные параметры вызова. std::function это шаблонная структура, как раз предком которой могла бы быть структура подобная Вашей.
И Ваш пример не будет универсальным для вызовов сторонними языками, т.к. как они каждый специфичен.
Там нужно типа такого:
При этом использование std::function действительно чуть медленнее, но не существенно. Основные тормоза буду, если будет
void a(std::function<void()> fn), особенно при рекурсиях, т.к. объект std::function будет каждый раз конструироваться, и в довесок занимать лишние ~32 байта в стеке, против 8 байт, если передается по ссылке.