«Гений» и «идиот» это то же характеристики человека. Для меня, ИИ это чисто поиск корреляций и последущее их применение — математика, статистика, прогнозирование.
Любопытный момент, что ожидание от ИИ опасности, это исключительно животный рефлекс возникший в ходе эволюционной борьбы за выживание. И ровно так же ожидание, что ИИ будет ожидать опасность от человека, это наше предположение, что этот ИИ будет подобен людям — т.е. просто эмуляция и копирование человеческого поведения. Без многих милионов полоколений борящихся за выживание, эти опасения просто не будут иметь смысла. Любые опасения не будут иметь смысл.
Соответственно, если кто-то видит угрозу от самого ИИ (а не от людей им заправляющим), значит этот кто-то думает, что этот ИИ просто-напросто копия человеческих рефлексов, не зависимо от того, чем является разумность или личность. Это же касается ожиданий любых других проявлений человеческого поведения в ИИ.
А если исключить все ожидания человеческой рефлексности от ИИ, то там остается только ожидание полезности от ИИ, для всех или для какой-либо группы людей.
Скорость потребления соответствует логистическому распределению. И пока ресурсов в избытке, то скорость потребления растет темпами близкими к экспоненциальному. А потом бац, и экспонента скушала весь избыток ресурсов. Поэтому это утверждение одновременно и истинно и ложно. Но в эпоху ИИ будет экспоненциальный рост ресурсов. И любопотный вопрос, которая из экспонент победит? Пусть математики гадают.
Разум есть. Но этот разум, это просто один из механизмов человеческого восприятия. И лично я не вижу смысла притягивать этот механизм к реализации ИИ. Разные люди могут видеть разные определения в термине ИИ. Если рассматривать ИИ как эмуляцию поведения человека, тогда там имеет место быть разуму. Если рассматривать ИИ как помощника для человека для реализации его задач, то разум в этом случае это лишняя сущность.
Везде пишут про GPT, но некоторые вещи можно и даже лучше делать без GPT. Периодически пишут, что GPT умеет делать новые программы, но программисты почему-то все еще нужны, и их не вытеснили генераторы программ на GPT. Ни разу не видел, что бы NLP на базе GPT могла вычислить простое сложение написанное на разговорном языке: «Сколько будет НЕКОЕ ЧИСЛО прибавить ДРУГОЕ ЧИСЛО?». Я конечно понимаю, что этому легко научить сетку, но этому легко научить, если этому ее специально учить. Но на все правила не сделать специальных подборок, а по произвольным подборкам, они такому не научиваются.
Если Вы про макросы, то значит Вы не то увидели, что я хотел показать. Классический std::sort не принимает никаких указателей на поля. Я показал, какой должна быть функция сортировки, что бы туда можно было перечислить поля, без описания всего компаратора. В больших количествах сортировок по множеству полей, это очень утомительно прописывать, легко запутаться, что является источником ошибок.
Так же привел три варианта организации передачи полей: макросом, просто лямбдой, и как позже подсказали, генератор лямбд memberAccessor, как раз на указателях на поля. Выбирайте любой, какой больше нравится.
Если Вы про что-то другое, то напишите полный пример. Незабудьте его проверить на компилируемость, а то, то что выше, не похоже на компилируемое.
И на что будет ссылаться R& в случае не найденности? А если пользователь метода хочет использовать копирование для результата? Ссылки не переопределяются, и следовательно операторы копирования или перемещения работать не будут.
В любом случае, возврат ссылки будет не стабильным и не красивым для этого случая. Общеприменимая практика это возврат итератора.
Проблема не в макросах, проблема в головах. Одни любят придумать шаткие и сложнопонимаемые макросы — болезнь унаследованная от С. Другие видят эту болезнь в каждом макросе, и даже типовые #ifndef в хеадерах заменяют на #pragma once.
Одни могут и перочинным ножичком себя покалечить. Другие могут ходить с ружьем десятки лет, и не отстреливать себе ногу, но получая прибыль от этого большую, чем если бы ходили с перочинным ножиком.
Нужно возвращать итератор, т.е. тип decltype(list.begin()), и в случае не найденности list.end(). Если конечно не хотим копировать всю структуру строки в результат.
Или указатель на элемент списка, т.е. тип decltype(&*list.begin()), и в случае не найденности nullptr.
Именно. И тогда после того как сформирован tuple, отпадает необходимость отсылаться к частному типу из vector. И тогда возможность построения универсальных алгоритмов на этом существенно возрастает.
Этот вариант не совсем подходит под универсальные, он под фиксированное количество полей. Но его можно поменять на вариадичный, нужно будет сделать функцию сравнения вариадичной, и вызывать ее из такой findFirst. Непосредственно здесь ошибочка, возврат ссылки на локальное значение в случае не найденности.
Так я и говорю, покажите как именно этот вариант примените хотя бы к std::sort, сколько это дополнительных строк возьмет. Ну или может на бустовских каких-нибудь функциях. Как вы будете суммировать такую колонку, и т.д. У меня же то же, не запрещается использовать свои лямбды без макросов, о чем я и писал.
Будет интересно посмотреть на обвес, когда вы попробуете написать поиск по двум колонкам.
Вот мой вариант, без макросов. А у вас как будет? Весь код не обязательно, только сам поиск, и объявления дополнительных функций, если таковые нужны. Но если доп.функции отсылаются к типу Row, то это прицеп раздувающий код, а не либу.
Зачем здесь прилепили getMemberRef это не понятно.
А вот если бы показали, как суммировать, сортировать, поиск значения. Как это все раздувается и обвешивается дополнительными конструкциями, и код становится ради кода, а не ради результата.
Соответственно, если кто-то видит угрозу от самого ИИ (а не от людей им заправляющим), значит этот кто-то думает, что этот ИИ просто-напросто копия человеческих рефлексов, не зависимо от того, чем является разумность или личность. Это же касается ожиданий любых других проявлений человеческого поведения в ИИ.
А если исключить все ожидания человеческой рефлексности от ИИ, то там остается только ожидание полезности от ИИ, для всех или для какой-либо группы людей.
Это не отменяет того, что я до этого написал.
Так же привел три варианта организации передачи полей: макросом, просто лямбдой, и как позже подсказали, генератор лямбд memberAccessor, как раз на указателях на поля. Выбирайте любой, какой больше нравится.
Если Вы про что-то другое, то напишите полный пример. Незабудьте его проверить на компилируемость, а то, то что выше, не похоже на компилируемое.
В любом случае, возврат ссылки будет не стабильным и не красивым для этого случая. Общеприменимая практика это возврат итератора.
Одни могут и перочинным ножичком себя покалечить. Другие могут ходить с ружьем десятки лет, и не отстреливать себе ногу, но получая прибыль от этого большую, чем если бы ходили с перочинным ножиком.
Или указатель на элемент списка, т.е. тип decltype(&*list.begin()), и в случае не найденности nullptr.
Будет интересно посмотреть на обвес, когда вы попробуете написать поиск по двум колонкам.
Вот мой вариант, без макросов. А у вас как будет? Весь код не обязательно, только сам поиск, и объявления дополнительных функций, если таковые нужны. Но если доп.функции отсылаются к типу Row, то это прицеп раздувающий код, а не либу.
Зачем здесь прилепили getMemberRef это не понятно.
А вот если бы показали, как суммировать, сортировать, поиск значения. Как это все раздувается и обвешивается дополнительными конструкциями, и код становится ради кода, а не ради результата.