All streams
Search
Write a publication
Pull to refresh
4
0
Send message

Сначала вы утверждали, что в Си нельзя добиться порядка арифметических операций в a*(b*c), и что скобки это логическая конструкция.

Не пишите конструкции в которых больше одного вызова функции в утверждении, если важен порядок их вызова.

Скобки задают отношение "вычислено до" на "дереве" вычисления, о чем я вам практически в самом начале и написал. И в вашем примере происходит вычисление result_a*(result_b*result_c), именно в соответствии с этим отношением, как и задает выражение скобок. Где здесь противоречие?

А порядок обхода этого дерева, если расставить все скобки не имеет значения, так как это данность современных процессорных архитектур, где арифметические операции условно "атомарны" и зависят лишь от входных аргументов. (что там было во времена мэйнфреймов, на которых гоняли фортран и адаптировали его синтаксис под их железо, мне не ведомо)

О господи, ну нельзя так.

вот выхлоп:

       call    a()
        mov     ebx, eax
        call    b()
        mov     r12d, eax
        call    c()
        imul    eax, r12d
        imul    eax, ebx
        mov     DWORD PTR [rbp-20], eax

Объясняю, что там происходит:

1) вызов a()

2) вызов b()

3) вызов c()

4) умножение результата b() на результат c()

5) домножение на результат a()

Про неупорядоченность в Си "дерева" вычислений со скобками, это просто какая-то мифология из мира фортран, возможно тридцати летней выдержки, когда стандарта еще особо и не было.

Не очень понимаю, какие могут быть побочные эффекты у арифметических операций в том же Си, чтобы это на что-то влияло.

Расстановка скобок однозначно задает и гарантирует, об этом было собственно написано в этой ссылке https://stackoverflow.com/a/52788550 с приведением пункта стандарта. И это было проверено мною ни однократно в "живой природе", ни одного отклонения от этого поведения зафиксировано не было.

PS: если не верите, можете сходить на какой ни буть godbolt, врубить максимальную оптимизацию -O3, и увидеть как меняется порядок вычислений в зависимости от скобок.

Какая разница в каком порядке обходить дерево, если для подвыражений выполняется отношение "получен результат до". Или вы думаете что обход дерева: ((a1*b1) + (a2*b2)) + (a3*b3))

в порядке:

r1=a1*b1, r2=a2*b2, r3=a3*b3, r4=r1+r2, r5=r4+r3, output r5

и

r3=a3*b3, r2=a2*b2, r1=a1*b1, r4=r1+r2, r5=r4+r3, output r5

будет иметь разный результат? Процессоры так не работают, арифметические операции по определению дают одинаковый результат, для одинаковых входных данных(и иногда плюс минус состояния).

Нет, скобки в Си однозначно задают "дерево" и порядок вычислений в нем. https://stackoverflow.com/a/17403097

https://stackoverflow.com/a/52788550

Большинство все таки пишет численно стабильные алгоритмы. А так насколько я понимаю в C достаточно скобок набросать, чтобы был нужный порядок.

Еще те кто пишут на фортране свято верят, что по скорости они уделывают C/С++, как бог черепаху, и что вся настоящая быстрая математика написана на фортране. Хотя к примеру в тех же численных библиотеках питона, а конкретнее реализации BLAS(OpenBLAS/MKL/ATLAS), его уже давно закопали.

Самая реальная средне срочная перспектива, что за деиндустриализацией, прийдет деинтелектуализация. А захват власти сверх разумным ИИ пока просто детская страшилка.

Поздно опомнились, начинать надо было с Т9. (/sarcasm)

Какой смысл писать обертки, уже над кросс-платформенными обертками, которыми является стандартная библиотека C/C++? Вроде того же fopen ? Молчу уж про то, что 95% оставшегося платформенно зависимого функционала покрывается, в каком ни буть Boost или Qt или еще какой-то менее известной фрэймворке/библиотеке. Иногда конечно бывает смысл написать обертку над каким-то точечным функционалам. Но то что описано в статье это просто пропагандирование NIH синдрома.

Возможно конечно, автор просто хочет, показать какие-то реальные примеры. Но что вот так делать в общем случаи не надо, хорошо бы написать красными буквами.

Если бы все было так просто то adversarial attack, не были бы похожи на еле заметный/мутный шум. Всякие простые фокусы, приводят к тому, что точка вываливается из "аттрактора" реальных лиц и там сколько свети или не свети, все равно близкого расстояния не получится.

В первом приближении рыночный ценовой процесс это процесс на котором невозможно заработать, то есть случайное блуждание. (в общем случаи более сложно, это может быть случайное блуждание с не стационарной волатильностью)

Все началось с того, что было указано, что на рынках имеются долгосрочные многолетние тренды, связанные с общим ростом экономики и рынка. Простейшая модель, которая их описывает это смещенное(с ненулевым мат. ожиданием приращений) случайное блуждание.

Дальше. Если вы хотите заработать на рынке, то вам нужна модель, которая предсказывает что-то лучше чем случайное блуждание. Соответственно, бремя построения модели(как и зарабатывания денег на ней) ложится на вас. Естественно, случайное блуждание это первое простейшее приближение, и у реальных цен есть множество отклонений от него(неэффективностей) на которых теоретически можно заработать. Проблема лишь в том, что многие люди воспринимают эту теоретическую возможность, как то что "у них то точно получится обыграть рынок" не проводя достоверных исследований, с довольно плачевным результатом.

Вся суть нейросеток, что их нельзя упростить до почти линейного преобразования.

Но вообще вопрос не в этом, базовая предпосылка использования эмббедингов это то, что похожие входные множества(в данном случаи похожие лица) отображаются в близкие вектора эмбеддингов. Можно долго размышлять, почему так происходит на практике, но если тренировать нейросетку, а потом отсечь ей голову, это будет так. Если эта предпосылка не выполняется, то полученная модель либо будет совсем мусором, либо существенно хуже любой "нормальной".

Очевидно, когда работают с изображениями делают базовую нормализацию, чтобы выровнять контраст и т.д. И так же очевидно, чтобы модель работала, обучающая и рабочая выборка, должны быть из плюс-минус одного распределения. (то есть какой-то значимый перекос в обучающих/реальных данных это априори плохо)

Теперь если вернуться к вопросу сравнения эмбеддингов. Да можно сделать еще одну настройку, в виде бинарного классификатора который будет принимать на входе два эмбеддинга(один запроса и другой из базы) и выдавать вердикт эквивалентны они или нет. (сравнение с порогом, полученным из данных, именно таким тривиальным классификатором и является) Чтобы на практике кто-то так делал, я лично не видел, думаю по целой совокупности причин, начиная что результат скорее всего получается не сильно лучше наивного расстояния, а возможно и хуже, и кончая тем что это дает линейную сложность, соответственно уже несколько миллионов лиц считать не так весело.

Я ж вам сказал, что это легко определяется на размеченных данных, которые используются во время обучения, абстрактно этот вопрос не имеет смысла. Часто в качестве метрики используется косинусное расстояние, которое более менее нормализовано. Но вопрос о пороге все равно в конечном итоге определяется из данных.

Это как раз тот случай, не знаю что уж вы там знаете, и при чем тут сыпать терминами. Почитайте любые вменяемые результаты и исследования по данному вопросу, это стандартный и полностю рабочий подход.

В таком тоне вести диалог не вижу смысла.

Это собственная реализация. И если дефолтный std::string хранит char без привязки к кодировки, то QString это всегда UTF-16 внутри.

Порог очевидно выбирается, на основе данных для обучения, в соответствии с нужным отношением true positive/false positive. Именно исходя из этого можно определить 42 это много или мало.

https://towardsdatascience.com/understanding-auc-roc-curve-68b2303cc9c5

В общем, достаточно сравнения с порогом, либо выдачи топ 5-10 с дальнейшей обработкой.

Есть такая инициатива https://theopenroadproject.org/ где из опенсоурсного "говна и палок" собрали минимально рабочий тулчейн.

Information

Rating
Does not participate
Registered
Activity

Specialization

Software Developer, Application Developer
Senior
C++
C++ STL
Linux
Python
Machine learning
Applied math
Algorithms and data structures
Code Optimization