На данный момент, к сожалению, ни кто пока не придумал способа более менее стабильно генерировать сетками диффы. Есть некоторые подходы, но они работают весьма криво, т.е. дифф едва ли не чаще кривой получается, чем нормальный, и это при условии, что сетка отдельно тюнилась на генерацию диффов - ванильные сетки вроде 4о или соннета этого совсем не умеют и практически гарантированно выдают поломанные диффы в любом нетривиальном случае. Кроме того, при генерации решения дифом в целом качество ответов падает на порядок. Т.е. там где цельным ответом сеть стабильно выдает правильный результат, диффом крайне часто будет генериться мусор. И вот если первый пункт както можно поправить - то второй принципиально нет. Т.е, полная генерация будет всегда на порядок качественнее чем диффом - просто в силу того как работают сетки.
И любая ошибка... В определённый момент чата - вызывает генерацию кода, а не его исправление.
Это кстати штука, которую ии-оптимисты (которые обычно сетками как раз не пользуются, иначе не были бы ии-оптимистами) сильно недооценивают. Тот факт, что приходится ждать генерацию тысяч строк для исправления десятка (еще и без какой-либо гарантии, что оно таки нагенерит что-то вменяемое) - полностью закрывает применение сеток в обширнейших классах юзкейсов (которые зачастую требуют от осознания задачи до получения результата 5-10 сек. - за это время даже промпт не напишешь). ПИ это характерно именно для профессиональных юзкейсов.
НА ТЕКУЩИЙ момент, невозможно без сложной агентной системы программировать с помощью ИИ
Сложные агентные системы как раз для разработчиков не нужны, они нужны людям, которые не умеют программировать. Программистам нужны системы, которые работают, надежно выдавая ожидаемый результат, под максимальным контролем программиста (т.е. с минимальным использованием промптов, желательно - вообще без использования промптов). Я выше как раз указывал на это - для художников или музыкантов такие системы есть, для программистов - не завезли. Все развитие инструментов в отрасли имеет таргетом непрофессиональную разработку.
То есть к научным относятся только те медели/теории/гипотезы по поводу которых у специалистов нет разногласий?
Консенсус ни чего не говорит о научности. Есть множество вполне однозначно научных теорий, которые для которых консесуально принято, что они неверны. Консенсус как раз определяет что верно, а что неверно. И если определение истины требует консенсуса - то это значит, что истина в рамках науки не установлена, потому и приходится проводить голосование.
При этом факт консенсуса вообще всегда выходит за пределы науки, т.к. в рамках науки он просто _не нужен_. Действительно, если у нас есть какой-то чисто научный вопрос - то нам в принципе не требуется проводить какие-то голосования и устанавливать консенсусы. Пример: у нас есть вопрос по равенству классов P и NP, и по этому вопросу существует вполне четкий и однозначный консенсус, что эти классы не равны (т.е. это не доказано, но подавляющее большинство математиков к этому склоняется). Но при этом данный консенсус ни кому особо не интересен - если выйдет какой-то ученый и скажет, что считает, будто они равны, то ни кто его на костер за это не потащит. Это работает исключительно потому, что нам на практике в принципе не особо важно это равенство. Но вот если бы вдруг нам на основании этого равенства требовалось принимать какие-то важные практические решения (как строить мост или куда выделить миллиард долларов) - то вот тогда-то бы сразу этот консенсус вышел в публичную плоскость и тех кто его не принимает выписывали бы из рукопожатых ученых.
Т.е. "научный консенсус" по факту - не научный и не консенсус. Это всегда определенное чисто политическое решение не имеющее отношения к научной деятельности.
Прикол в том, что в этом случае с точки зрения суда обе стороны _равны_ (в отличии от кейса с уголовным делом). Так что суд с 50% вероятностью вполне может вставать на сторону кредитора. Если должника такие риски устраивают- ну окей)
Золотая лихорадка стартовала - время изготавливать и продавать лопаты.
Только почему-то ни кто не хочет. Для художников профессиональные нейросетевые инструменты есть, для музыкантов - есть. Для программистов - не существует.
Те, кто это понимает, и сможет заранее приспособиться и занять новую нишу - выживут.
Пока что не к чему. Вот когда инструменты начнут появляться - да, надо будет учиться их эффективно использовать.
Минутку, но 1-ая версия ChatGPT была запущена только 2 года назад.
Вы путаете конкретный продукт (ChatGPT, релиз 30 ноября 2022) и модель, на которой этот продукт работал (GPT-3, релиз 28 мая 2020, почти 5 лет назад).
И каждый месяц выходят новые модели, которые ставят рекорды в тех или иных тестах.
Рекорды-то они ставят, но это все просто попугаи не имеющие отношения к реальности. По факту же, для наиболее распространенных задач (перевод, суммаризация, рерайтинг) даже о3-mini-high слабо отличается от базовой ванильной трешки пятилетней давности. Единственный реальный прогресс в контексте - но и там, речь о том что просто можно закинуть большего размера промпт, а так даже лучшие модели теряют контекст после 10-20 страниц текста (или 1-2 kloc кода) и надо создавать чат заново.
Что касается принципиальной невозможности LLM рассуждать - это философский вопрос.
Да нету ни какого философского вопроса, сеть выдает один единственный токен и прекращает работу. Один единственный токен - очевидно, не рассуждение. Сбор же токенов в осмысленную цепочку - отдельная операция, с которой работа сетки вообще не связана ни как.
ЗЫ: между gpt-3 и gpt-2, к слову, прошел всего год, и это был реально жесткий прорыв от "нахер не нужно, т.к. невозможно использовать в реальных задачах" до "можно без проблем применять в обширном классе реальных задач". Т.е., объективно, после выхода GPT-3 - за ~впятеро большее время был сделан в разы меньший прогресс. собственно, о том и речь - в плане качества работы моделей почти весь возможный прогресс уже "выбрали", лучше делать просто некуда. Но можно дешевле и эффективнее в применении - вот в этом направлении последние 2-3 года развитие и идет.
Limo позволяет получить тот же перформанс с меньшими затратами, но не увеличить его. Перформанс сетей практически не растет уже последние года 2-3 - т.к. достигнута практически максимальная точность аппроксимации. Выше 100% не поднимешься - и тут ни чего не поможет, ни большее количество данных, ни большее количество параметров, ни более совершенные методы. Это принципиальное ограничение подхода как такового.
>Он будет учиться рассуждениям, "когнитивным шаблонам", как выразились авторы статьи по ссылке
Ллм не может учиться рассуждениям (она в принципе не может рассуждать) или когнитивным шаблонам (т.к. у нее нет когнитивных способностей и в уелом когнитивных процессов или процессов которые хотя бы отдаленно похожи на когнитивные). Модель может учиться более точной аппроксимации функции распределения токенов в обучающей выборке.
В тех случаях когда перекраска кнопки требует больше 5 минут ллм вообще ни чем и ни как пока что помочь не могут, так что так и будет кнопка на следующей неделе
Мне кажется, с появлением рассуждающих LLM уже можно с уверенностью сказать, что понимание установлено.
Ни одна современная ллм не может рассуждать. Рассуждение предполагает последовательность токенов, а модель не может генерить последовательность - она генерит только один токен _и прекращает работу_. Почему-то многие этот очевидный факт забывают, воспринимая весь ответ модели как "цельный ответ". На самом деле это много-много разных независимых ответов, которые ни как не связаны друг с другом.
Это распространенное когнитивное искажение. Если лауреат премии Филдса говорит что дважды два равно пяти - это значит что он кукухой поехал, а не то, что дважды два ВНЕЗАПНО стало равно пяти.
Знаете что-то такое секретное, чего не знает (или не говорит) никто из исследователей. 100% уверены, что демонстрировать человеческие возможности можно, но ведь это обман и вы знаете почему, не так ли?
Эм, 100% ученых как раз говорят, что невозможно. Буквально ни одного не найдете, который бы утверждал иное. Чтобы говорить хотя бы о потенциальной возможности, нужно выполнение хотя бы одного условия:
Сетки должны работать сходным образом с системой, которая демонстрирует человеческие возможности
Она их по факту демонстрирует, просто экспериментально
Не выполняется ни первое (у нейросетей нет ни чего общего с тем, как работает мозг), ни второе (существующие нейросети не показывают даже когнитивных способностей не слишком сообразительной собаки, что уж говорить о человеке?)
Не получится. Мой код _работает правильно_, а ваш - _не_ работает правильно_. Это весьма принципиальная разница.
Я еще раз повторяю - если вы сами занимаетесь велосипедной синхронизацией, то вы уже обосрались. Потому что вы пишите код, в котором можно ошибиться миллионом разных способов. И вы - ошиблись. А у меня код правильный просто потому, что _ошибиться негде_. Вот и ошибок нет.
Он работает правильно.
Нет, не работает. Если быстро поменять несколько юзеров (быстрее, чем они догружаются), то компонент их все выведет подряд, хотя должен вывести только последнего.
Поэтому как раз ваш код не работает.
Так приведите юзкейс, в котором он не работает. Я выше привел юзкейс, в котором не работает ваш.
Вы видите тут эффекты?
Этот раздел иррелевантен эффектам. Там описывается рекомендованный командой реакта универсальный способ полного сброса стейта компонента.
Если вам надо сбрасывать стейт в общем случае (если нет специфичной для вашего кейса причины, по которой так делать нельзя) - вы используете ключи. Либо пишете говнокод с ошибками.
Это стандартное решение, когда речь идет о коде без эффектов.
Нет, это стандартное решение, когда надо сбрасывать стейт при изменении пропса. По линку буквально описан кейс из статьи - даже компонент тот же самый с пропсом - Profile и userId.
Только изучая документацию или исходный код они узнают, что частью публичного интерфейса является так же и инфраструктурное свойство key.
Так написано же: "Note that in this example, only the outer ProfilePage component is exported and visible to other files in the project." (в моем посте это ProfileWrapper). Интерфейс точно такой же, как требуется. Тому, кто использует компонент, ни чего про ключи знать не надо.
По сути, вы убираете из реакта функциональность useEffect, и реализуете ее окольными путями.
useEffect остался там, где был: "useEffect(() => fetchProfile(username).then(setUser), []);" вместе со всей своей функциональностью.
Вы же, вместо того, что бы синхронизировать компонент используя встроенные средства
Наоборот, я как раз предлагаю использовать встроенные средства, предлагаемые фреймворком, вместо того чтобы писать для синхронизации свои велосипеды. В итоге мой код выше работает правильно (и не может не работать, потому что там негде ошибиться), а код автора с велосипедами - _не работает_ правильно (потому что синхронизация стейта - сложная задача, и даже в таких примитивных кейсах делать ее руками - значить обосраться). Не говоря уже о том, что сам код гораздо проще и лучше поддерживается.
Команда реакт не советует так делать.
Это прямая ложь, я выше дал ссылку, где рассматривается буквально наш кейс и команда реакта четко и однозначно говорит "используйте в этом и похожих случаях ключи".
Оно понятное, но оно основано на том, что у вас в компоненте нет никакого состояния
Если бы состояния не было, то нам не надо было бы его обнулять при помощи key. Состояние то у нас есть, просто нам не надо поддерживать "непрерывность" этого состояния при изменении пропса - наоборот, нам надо состояние сбрасывать. И вот в таких случаях, когда надо сбрасывать состояние при изменении пропсов - и надо использовать ключи.
Возможно, наверное, всё приложение создавать в таком стиле "рубки" - но оно будет какое-то странное для React.
Наоборот, это и есть react-way. Напомню, что реакт - это порт внутреннего php-фреймворка, основа его логики - если мы что-то сделали, то пришел новый ответ с сервера, который заново с нуля и полностью отрендерил всю страницу. Реакт изначально сделан так, чтобы эмулировать такое поведение (и чтобы можно было потом с наименьшими болями портировать код с php на js), это основа его архитектуры.
В React все хороводят вокруг "состояния", а в случае key состояния нет вообще.
Все верно, состояние и работа с ним - это сложно и чревато ошибками. Если есть возможность написать код так, чтобы избежать работы с состоянием или положить работу с ним на плечи самого фреймворка - так и надо делать. Чтобы не обосраться со сложным кодом - надо просто не писать сложный код.
Но в реале наверняка надо в key помещать какое-то Id , так как имена в списке могут совпадать.
В каком списке? Это один компонент-панелька, который не выводится в массиве.
Да и что будет если кто-то использует Profile без обёртки ProfileWrapper?
То же самое, что и в том случае, если кто угодно будет использовать любой другой компонент _непредназначенным образом_. В крайнем случае можно импортировать только обертку. Все равно это выглядит гораздо проще. Ну и работает корректнее - тут, как уже отметили, "идеальное" решение автора-то по факту глючное - если быстро протыкать например по 5 разным юзерам, то начнут запросы приходить по очереди и мы увидим как на панельке с задержкой переключается пять юзеров)
Смысл то моего подхода именно в том, чтобы не писать когнитивно сложный код, когда можно его не писать. Тогда и места для ошибки не будет. Нельзя ошибиться в кодле, который не написан) а автор вот решил такой код написать - и посадил ошибку.
В интервью я обязательно спрашиваю: "А что, если проп username может динамически меняться? Например, пользователь кликает по спис
В этих случаях есть стандартное рекомендованное командой реакта решение - использовать ключи. Т.е.:
<Profile key={username} username={username}>
В итоге username внутри компонента меняться не будет. В этом случае нам не надо писать "мусорный" код, вместо этого гарантия корректности будет обеспечена на уровне фреймворка.
Дальше я описываю сценарий: представьте, что в вашем приложении две панели. Слева - список пользователей, справа - . Пользователь начинает быстро кликать то по одному, то по другому пользователю.
Поскольку реакт гарантирует корректность, об этом думать не надо, и ни чего по этому поводу делать не надо. Все будет работать правильно само по себе.
"Да, будет", ведь компонент может быть размонтирован, а асинхронный вызов вернётся. Возникает сценарий, когда React ругается - “Can’t perform a React state update on an unmounted component…”.
Нет, не будет. Это не является какой-либо проблемой. Корректность работы компонента уже гарантирована, и поэтому можно не думать о подобных вещах.
А зачем ссыль на линейную алгебру? Это же диофантов анализ.
Да не, тут нету ни какого диофантова анализа. Чистая линейка - надо показать, что при определенном преобразовании базиса целые координаты при некоторых условиях остаются целыми (с точностью до масштабного коэффициента). Например, если мы в трехмерном пространстве плоскость сориентируем вдоль диагонали единичного куба, то такое преобразование не получится - т.к. при откладывании единичных отрезков вдоль диагонали куба мы ни когда не попадем в узел сетки из единичных кубов. А вот если повернуть трехмерную гиперплоскость в четырехмерном пространстве (или 8-мерную в девятимерном или 15-мерную в 16-мерном и т.д..), то при таком повороте диагональ единичного гиперкуба будет в точности в 2 (3, 4...) раза больше, чем сторона и мы будем попадать в узлы сетки.
Ну еще важным моментом конечно является тот факт, что корень натурального числа - либо натуральное число, либо иррациональное, дробью он быть не может (именно поэтому сколько не откладывай единиц вдоль диагонали - ни когда не попадешь в n * sqrt(2)). Но это уже офк из очевидностей))
При том, что глупо, наверное, ожидать от нейросети решения, которое даже лучшие математики мира не смогли бы получить? Если бы сетка дала ответ 7+7+2+2+1+1 , можно было бы всех ученых сразу нафиг разгонять. Зачем они нужны? Просто даешь сетке любую проблему тысячелетия, и она через пять-десять минут выдает ответ с полными выкладками.
Ну и задачу сразу решили - 20 кубиков выводится очень легко
Ну так попробуйте вывести. Как я уже выше сказал - это, скорее всего, месяцы научной работы. И не вас, а профессионального математика. На всякий случай, я уточню - любой вывод построения из 20 кубиков позволит вам сразу построить и максимальный вариант на 24 с доказательством того, что он - максимальный. При этом не только с равными кубиками, но и с кубиками произвольного размера.
Нет. Не согласен. Это неправильное и неожидаемое поведение
Это правильно и ожидаемое поведение, которому сеть была _намеренно обучена_. Можно обучить сеть так, чтобы она воспринимала промпт максимально буквально - вам ни кто не мешает так сделать. Просто на практике это не нужно, потому ни кто и не делает.
Так оно так и должно работать. Сеть решает задачи путем перебора по последовательностям токенов с эвристикой. Ни чего другого она технически делать не может.
Но использует математический оператор возведения в степень. И при этом все равно меньше факториала 222.
Так в том и прикол, что не использует) На самом деле, там в рассуждениях он перебирает все варианты и останавливается на том, что имеется в виду кейс с арифметическими операциями. Собственно - это правильное и ожидаемое поведение, нейросеть специально тренируют, чтобы она воспринимала вопросы in common sense, а не буквально. Требовать от нее иного - этого как требовать от молотка, чтобы у него был мягкий боек.
Легко. Я ждал ответа в 20 кубиков (7+7+2+2+1+1).
Я не думаю, что в мире существует человек, который сможет за сколько-нибудь адекватное время прийти к результату 20 кубиков без визуализации. Попробуйте сами такой результат вывести - не думаю, что у вас получится, даже когда вы его знаете наперед. Здесь надо, скорее всего, будет полноценную новую теорию придумать для решения. Это месяцы, а то и годы работы.
От сетки в максимуме я бы ожидал 4+4+2+2+1+1. Собственно, там в рассуждениях оно было достаточно близко к этому кейсу.
На данный момент, к сожалению, ни кто пока не придумал способа более менее стабильно генерировать сетками диффы. Есть некоторые подходы, но они работают весьма криво, т.е. дифф едва ли не чаще кривой получается, чем нормальный, и это при условии, что сетка отдельно тюнилась на генерацию диффов - ванильные сетки вроде 4о или соннета этого совсем не умеют и практически гарантированно выдают поломанные диффы в любом нетривиальном случае. Кроме того, при генерации решения дифом в целом качество ответов падает на порядок. Т.е. там где цельным ответом сеть стабильно выдает правильный результат, диффом крайне часто будет генериться мусор. И вот если первый пункт както можно поправить - то второй принципиально нет. Т.е, полная генерация будет всегда на порядок качественнее чем диффом - просто в силу того как работают сетки.
Это кстати штука, которую ии-оптимисты (которые обычно сетками как раз не пользуются, иначе не были бы ии-оптимистами) сильно недооценивают. Тот факт, что приходится ждать генерацию тысяч строк для исправления десятка (еще и без какой-либо гарантии, что оно таки нагенерит что-то вменяемое) - полностью закрывает применение сеток в обширнейших классах юзкейсов (которые зачастую требуют от осознания задачи до получения результата 5-10 сек. - за это время даже промпт не напишешь). ПИ это характерно именно для профессиональных юзкейсов.
@rPman
Сложные агентные системы как раз для разработчиков не нужны, они нужны людям, которые не умеют программировать. Программистам нужны системы, которые работают, надежно выдавая ожидаемый результат, под максимальным контролем программиста (т.е. с минимальным использованием промптов, желательно - вообще без использования промптов). Я выше как раз указывал на это - для художников или музыкантов такие системы есть, для программистов - не завезли. Все развитие инструментов в отрасли имеет таргетом непрофессиональную разработку.
Консенсус ни чего не говорит о научности. Есть множество вполне однозначно научных теорий, которые для которых консесуально принято, что они неверны. Консенсус как раз определяет что верно, а что неверно. И если определение истины требует консенсуса - то это значит, что истина в рамках науки не установлена, потому и приходится проводить голосование.
При этом факт консенсуса вообще всегда выходит за пределы науки, т.к. в рамках науки он просто _не нужен_. Действительно, если у нас есть какой-то чисто научный вопрос - то нам в принципе не требуется проводить какие-то голосования и устанавливать консенсусы. Пример: у нас есть вопрос по равенству классов P и NP, и по этому вопросу существует вполне четкий и однозначный консенсус, что эти классы не равны (т.е. это не доказано, но подавляющее большинство математиков к этому склоняется). Но при этом данный консенсус ни кому особо не интересен - если выйдет какой-то ученый и скажет, что считает, будто они равны, то ни кто его на костер за это не потащит. Это работает исключительно потому, что нам на практике в принципе не особо важно это равенство. Но вот если бы вдруг нам на основании этого равенства требовалось принимать какие-то важные практические решения (как строить мост или куда выделить миллиард долларов) - то вот тогда-то бы сразу этот консенсус вышел в публичную плоскость и тех кто его не принимает выписывали бы из рукопожатых ученых.
Т.е. "научный консенсус" по факту - не научный и не консенсус. Это всегда определенное чисто политическое решение не имеющее отношения к научной деятельности.
@rsashka
Прикол в том, что в этом случае с точки зрения суда обе стороны _равны_ (в отличии от кейса с уголовным делом). Так что суд с 50% вероятностью вполне может вставать на сторону кредитора. Если должника такие риски устраивают- ну окей)
Только почему-то ни кто не хочет. Для художников профессиональные нейросетевые инструменты есть, для музыкантов - есть. Для программистов - не существует.
Пока что не к чему. Вот когда инструменты начнут появляться - да, надо будет учиться их эффективно использовать.
Там сетапы на 4/5/6 игроков и от 2 до 6 комнат. В случае 4 и 5 игроков раунд только 1.
Вы путаете конкретный продукт (ChatGPT, релиз 30 ноября 2022) и модель, на которой этот продукт работал (GPT-3, релиз 28 мая 2020, почти 5 лет назад).
Рекорды-то они ставят, но это все просто попугаи не имеющие отношения к реальности. По факту же, для наиболее распространенных задач (перевод, суммаризация, рерайтинг) даже о3-mini-high слабо отличается от базовой ванильной трешки пятилетней давности. Единственный реальный прогресс в контексте - но и там, речь о том что просто можно закинуть большего размера промпт, а так даже лучшие модели теряют контекст после 10-20 страниц текста (или 1-2 kloc кода) и надо создавать чат заново.
Да нету ни какого философского вопроса, сеть выдает один единственный токен и прекращает работу. Один единственный токен - очевидно, не рассуждение. Сбор же токенов в осмысленную цепочку - отдельная операция, с которой работа сетки вообще не связана ни как.
ЗЫ: между gpt-3 и gpt-2, к слову, прошел всего год, и это был реально жесткий прорыв от "нахер не нужно, т.к. невозможно использовать в реальных задачах" до "можно без проблем применять в обширном классе реальных задач". Т.е., объективно, после выхода GPT-3 - за ~впятеро большее время был сделан в разы меньший прогресс. собственно, о том и речь - в плане качества работы моделей почти весь возможный прогресс уже "выбрали", лучше делать просто некуда. Но можно дешевле и эффективнее в применении - вот в этом направлении последние 2-3 года развитие и идет.
Limo позволяет получить тот же перформанс с меньшими затратами, но не увеличить его. Перформанс сетей практически не растет уже последние года 2-3 - т.к. достигнута практически максимальная точность аппроксимации. Выше 100% не поднимешься - и тут ни чего не поможет, ни большее количество данных, ни большее количество параметров, ни более совершенные методы. Это принципиальное ограничение подхода как такового.
>Он будет учиться рассуждениям, "когнитивным шаблонам", как выразились авторы статьи по ссылке
Ллм не может учиться рассуждениям (она в принципе не может рассуждать) или когнитивным шаблонам (т.к. у нее нет когнитивных способностей и в уелом когнитивных процессов или процессов которые хотя бы отдаленно похожи на когнитивные). Модель может учиться более точной аппроксимации функции распределения токенов в обучающей выборке.
В тех случаях когда перекраска кнопки требует больше 5 минут ллм вообще ни чем и ни как пока что помочь не могут, так что так и будет кнопка на следующей неделе
Ни одна современная ллм не может рассуждать. Рассуждение предполагает последовательность токенов, а модель не может генерить последовательность - она генерит только один токен _и прекращает работу_. Почему-то многие этот очевидный факт забывают, воспринимая весь ответ модели как "цельный ответ". На самом деле это много-много разных независимых ответов, которые ни как не связаны друг с другом.
Это распространенное когнитивное искажение. Если лауреат премии Филдса говорит что дважды два равно пяти - это значит что он кукухой поехал, а не то, что дважды два ВНЕЗАПНО стало равно пяти.
@Hardcoin
Эм, 100% ученых как раз говорят, что невозможно. Буквально ни одного не найдете, который бы утверждал иное. Чтобы говорить хотя бы о потенциальной возможности, нужно выполнение хотя бы одного условия:
Сетки должны работать сходным образом с системой, которая демонстрирует человеческие возможности
Она их по факту демонстрирует, просто экспериментально
Не выполняется ни первое (у нейросетей нет ни чего общего с тем, как работает мозг), ни второе (существующие нейросети не показывают даже когнитивных способностей не слишком сообразительной собаки, что уж говорить о человеке?)
Не получится. Мой код _работает правильно_, а ваш - _не_ работает правильно_. Это весьма принципиальная разница.
Я еще раз повторяю - если вы сами занимаетесь велосипедной синхронизацией, то вы уже обосрались. Потому что вы пишите код, в котором можно ошибиться миллионом разных способов. И вы - ошиблись. А у меня код правильный просто потому, что _ошибиться негде_. Вот и ошибок нет.
Нет, не работает. Если быстро поменять несколько юзеров (быстрее, чем они догружаются), то компонент их все выведет подряд, хотя должен вывести только последнего.
Так приведите юзкейс, в котором он не работает. Я выше привел юзкейс, в котором не работает ваш.
Этот раздел иррелевантен эффектам. Там описывается рекомендованный командой реакта универсальный способ полного сброса стейта компонента.
Если вам надо сбрасывать стейт в общем случае (если нет специфичной для вашего кейса причины, по которой так делать нельзя) - вы используете ключи. Либо пишете говнокод с ошибками.
Нет, это стандартное решение, когда надо сбрасывать стейт при изменении пропса. По линку буквально описан кейс из статьи - даже компонент тот же самый с пропсом - Profile и userId.
Так написано же: "Note that in this example, only the outer
ProfilePagecomponent is exported and visible to other files in the project." (в моем посте это ProfileWrapper). Интерфейс точно такой же, как требуется. Тому, кто использует компонент, ни чего про ключи знать не надо.useEffect остался там, где был: "
useEffect(() => fetchProfile(username).then(setUser), []);" вместе со всей своей функциональностью.Наоборот, я как раз предлагаю использовать встроенные средства, предлагаемые фреймворком, вместо того чтобы писать для синхронизации свои велосипеды. В итоге мой код выше работает правильно (и не может не работать, потому что там негде ошибиться), а код автора с велосипедами - _не работает_ правильно (потому что синхронизация стейта - сложная задача, и даже в таких примитивных кейсах делать ее руками - значить обосраться). Не говоря уже о том, что сам код гораздо проще и лучше поддерживается.
Это прямая ложь, я выше дал ссылку, где рассматривается буквально наш кейс и команда реакта четко и однозначно говорит "используйте в этом и похожих случаях ключи".
@taujavarob
Если бы состояния не было, то нам не надо было бы его обнулять при помощи key. Состояние то у нас есть, просто нам не надо поддерживать "непрерывность" этого состояния при изменении пропса - наоборот, нам надо состояние сбрасывать. И вот в таких случаях, когда надо сбрасывать состояние при изменении пропсов - и надо использовать ключи.
Наоборот, это и есть react-way. Напомню, что реакт - это порт внутреннего php-фреймворка, основа его логики - если мы что-то сделали, то пришел новый ответ с сервера, который заново с нуля и полностью отрендерил всю страницу. Реакт изначально сделан так, чтобы эмулировать такое поведение (и чтобы можно было потом с наименьшими болями портировать код с php на js), это основа его архитектуры.
Все верно, состояние и работа с ним - это сложно и чревато ошибками. Если есть возможность написать код так, чтобы избежать работы с состоянием или положить работу с ним на плечи самого фреймворка - так и надо делать. Чтобы не обосраться со сложным кодом - надо просто не писать сложный код.
Это же _стандартное_ решение, которое явно рекомендовано вот тут:
https://react.dev/learn/you-might-not-need-an-effect "Resetting all state when a prop changes"
В каком списке? Это один компонент-панелька, который не выводится в массиве.
То же самое, что и в том случае, если кто угодно будет использовать любой другой компонент _непредназначенным образом_. В крайнем случае можно импортировать только обертку. Все равно это выглядит гораздо проще. Ну и работает корректнее - тут, как уже отметили, "идеальное" решение автора-то по факту глючное - если быстро протыкать например по 5 разным юзерам, то начнут запросы приходить по очереди и мы увидим как на панельке с задержкой переключается пять юзеров)
Смысл то моего подхода именно в том, чтобы не писать когнитивно сложный код, когда можно его не писать. Тогда и места для ошибки не будет. Нельзя ошибиться в кодле, который не написан) а автор вот решил такой код написать - и посадил ошибку.
В этих случаях есть стандартное рекомендованное командой реакта решение - использовать ключи. Т.е.:
В итоге username внутри компонента меняться не будет. В этом случае нам не надо писать "мусорный" код, вместо этого гарантия корректности будет обеспечена на уровне фреймворка.
Поскольку реакт гарантирует корректность, об этом думать не надо, и ни чего по этому поводу делать не надо. Все будет работать правильно само по себе.
Нет, не будет. Это не является какой-либо проблемой. Корректность работы компонента уже гарантирована, и поэтому можно не думать о подобных вещах.
А теперь правильное идеальное решение:
Чтобы обеспечить тот же интерфейс, который требуется изначально, можно объявить дополнительный компонент:
Код работает корректно, согласно требованиям, ни каких проблем не имеет.
ЗЫ: а при использовании suspense компонент будет и вовсе выглядеть так:
с соответствующей оберткой. И, что характерно - все будет работать как надо. Без ненужных изъебов. KISS.
Да не, тут нету ни какого диофантова анализа. Чистая линейка - надо показать, что при определенном преобразовании базиса целые координаты при некоторых условиях остаются целыми (с точностью до масштабного коэффициента). Например, если мы в трехмерном пространстве плоскость сориентируем вдоль диагонали единичного куба, то такое преобразование не получится - т.к. при откладывании единичных отрезков вдоль диагонали куба мы ни когда не попадем в узел сетки из единичных кубов. А вот если повернуть трехмерную гиперплоскость в четырехмерном пространстве (или 8-мерную в девятимерном или 15-мерную в 16-мерном и т.д..), то при таком повороте диагональ единичного гиперкуба будет в точности в 2 (3, 4...) раза больше, чем сторона и мы будем попадать в узлы сетки.
Ну еще важным моментом конечно является тот факт, что корень натурального числа - либо натуральное число, либо иррациональное, дробью он быть не может (именно поэтому сколько не откладывай единиц вдоль диагонали - ни когда не попадешь в n * sqrt(2)). Но это уже офк из очевидностей))
А что тут даст перебор? Что, собственно, перебирать?
а так, в целом, оно решает:
https://chatgpt.com/share/67a0b32a-8a9c-800c-b7dd-a7f2e2d9675c
При том, что глупо, наверное, ожидать от нейросети решения, которое даже лучшие математики мира не смогли бы получить? Если бы сетка дала ответ 7+7+2+2+1+1 , можно было бы всех ученых сразу нафиг разгонять. Зачем они нужны? Просто даешь сетке любую проблему тысячелетия, и она через пять-десять минут выдает ответ с полными выкладками.
Ну так попробуйте вывести. Как я уже выше сказал - это, скорее всего, месяцы научной работы. И не вас, а профессионального математика. На всякий случай, я уточню - любой вывод построения из 20 кубиков позволит вам сразу построить и максимальный вариант на 24 с доказательством того, что он - максимальный. При этом не только с равными кубиками, но и с кубиками произвольного размера.
Это правильно и ожидаемое поведение, которому сеть была _намеренно обучена_. Можно обучить сеть так, чтобы она воспринимала промпт максимально буквально - вам ни кто не мешает так сделать. Просто на практике это не нужно, потому ни кто и не делает.
Так оно так и должно работать. Сеть решает задачи путем перебора по последовательностям токенов с эвристикой. Ни чего другого она технически делать не может.
Так в том и прикол, что не использует)
На самом деле, там в рассуждениях он перебирает все варианты и останавливается на том, что имеется в виду кейс с арифметическими операциями. Собственно - это правильное и ожидаемое поведение, нейросеть специально тренируют, чтобы она воспринимала вопросы in common sense, а не буквально. Требовать от нее иного - этого как требовать от молотка, чтобы у него был мягкий боек.
Я не думаю, что в мире существует человек, который сможет за сколько-нибудь адекватное время прийти к результату 20 кубиков без визуализации. Попробуйте сами такой результат вывести - не думаю, что у вас получится, даже когда вы его знаете наперед. Здесь надо, скорее всего, будет полноценную новую теорию придумать для решения. Это месяцы, а то и годы работы.
От сетки в максимуме я бы ожидал 4+4+2+2+1+1. Собственно, там в рассуждениях оно было достаточно близко к этому кейсу.
а вот с рассуждениями:
https://pastebin.com/C08f27kD
бтв, попробуйте сами решить задачу стереометрически - т.е. в рамках чистой математики, не пользуясь визуализацией)
2^22 не использует ни каких символов кроме трех двое так то)) (если 22 расположить как верхний индекс, что условием задачи не запрещается).
Эм, а какое к различимости имеет отношение разрешение? С точки зрения глаза же размер пикселя все равно одинаковый.