Это не проблема. У нас ведь условие два числа.


Привет чатжпт

первый способ, т.к. он рациональнее





https://ru.wikipedia.org/wiki/%D0%A1%D1 ... 0%BE%D0%B5 это определение

мы получим ошибку переполнения и остановку вычислений.

Оперативная память условно бесконечна, а потому сейчас в большинстве софта переменные объявляются с большим запасом.
А вот алгоритм с 3 операциями вместо 2 будет выполняться в 1.5 раза медленнее. И если в таком духе писать весь код, то и вся программа будет тормозным куском. Если бы второй метод еще был без деления (самая неудобная операция для компа), но оно есть и там и там.

пусть даны a и b, причем b > а.
найдем разницу с = b - а
поделим пополам с / 2
и прибавим к меньшему
а + с/2
вспомним что с = b - a и подставим в это вот.
a + (b - a) / 2
приведем дроби к общему знаменателю 2a / 2 + (b - a) / 2
сумма дробей это сумма их числителей (2a + b - a) / 2
и получаем на выходе (а + b) / 2

вроде уровень третьего класса? или когда там алгебра начинается?

Какого типа надо объявить переменную чтобы в нее вошло число 12 618 446 744 073 709 551 615, если в языке есть только такие https://learn.microsoft.com/ru-ru/cpp/c ... w=msvc-170 ?

Если существует подозрение, что размера переменных не хватит, то используют библиотеку GMP, как вариант.

Касательно исходного вопроса даже чат-бот считает, что среднее арифметическое находят сложением и делением. Конкретно он сделал accumulate массиву чисел и поделил на его размер.


Добавлено спустя 5 минут 49 секунд:
Кстати по твоей же ссылке видно, что int является алиасом для int32. Меньший размер фактически вымер, его нет смысла использовать почти никогда. Объявлять все подряд минимум как 32 бита / 4 байта это стандартная практика примерно так с конца прошлого века наверное. Именно об этом я и писал ранее. Для 150 + 180 из примера такого типа достаточно с запасом.

Это не так и причина в другом: дело в OS и разрядности компиляторов. Во времена DOS было int = int16. Меньшие типы активно используются, но надо понимать их ограничения. Это к вопросу о вычислении среднего значения, нельзя просто так брать и складывать числа без проверки на переполнения типов данных. Например, существует проблема 2038 года https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC%D0%B0_2038_%D0%B3%D0%BE%D0%B4%D0%B0 тоже связанная с переполнением.


150 и 180 просто пример для byte. Для int(беззнакового 32bit, который uint32) всё сломается на 2 500 000 000 + 2 800 000 000. Так что надо смотреть шире, проблема не в конкретных значениях а в принципах представления чисел. А так простой int ещё и знаковый, и результат 1 500 000 000 + 1 800 000 000 вообще отрицательный будет.

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

Кто может помочь зарегистрировать новую учетку на linkedin? Чего только не пробовал, капчу нереально пройти.

Наверное, именно поэтому основное нововведение RTX 50 это FP4? Который как раз маленький и сделан для этих самых быстрых вычислений на GPU.

Одно не отменяет другое. FP4 появился как следующий виток экономии памяти. Как только смогут нарастить память в достаточном объеме от FP4 откажутся. Но заметь, что вычисление идет разом над всей матрицей. Байтики не перекладывают. Т.е. это современный алгоритм, только со ниженной точностью. А раньше мурыжили бы последовательно одно 32 битное число на 8 битном железе.

Ну эта гонка вечная... Помнится знаменитое: "640 Кб должно быть достаточно для каждого" (с). Так что памяти будет всегда не хватать, и всегда будут придумывать какие-то способы это обойти.

Если это не микроконтроллеры какие-то, то понимая их ограничения надо просто не использовать их.
А что и как часто используется я могу наблюдать когда пихаю чужой exe в отладчик. 99.5% переменных там из типов на 4 байта.


У этой проблемы те же самые корни. Кто-то просто не подумав толком еще во времена когда 640 16 кб "хватало всем" выдумал все это.


Проблема в том, что надо знать и предвидеть "use cases" своего приложения/кода. Тогда вопросов по типам данных будет меньше.


Это не значит, что там резко стали использовать переменные 4 бита. Используется квантизация, что по сути автоматический процесс. И главное отличие в том, что ALU видеокарты (конкретно 50 серии) физически способны делать в 2 раза больше операций над 4 битами по сравнению с 8. У центральных процессоров такого нет, скорее наблюдается движение в обратную сторону - AVX все большей разрядности за то же число циклов с каждым новым поколением.

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


Как раз - нет. AVX (Advanced Vector Extensions) - это тоже векторные вычисления в CPU, суть там та же что и в GPU за 1 команду провести вычисления над несколькими числами. А разрядность это количество чисел в этом самом векторе. Т.е. увеличивая разрядность AVX увеличивают не точность, а количество параллельных операций над числами.

Можно конечно на это по-разному смотреть.
В железе именно что стало шире. Zen 4 мог за раз прожевать 256, а 512 пролезало половинками. Zen 5 может 512 за раз (т.е. у него 512-разрядный операционный автомат aka datapath). Как оно там со стороны софта выглядит, и какой смысл туда его разработчик вкладывает - вопрос уже другой. Если на те же порты/считалки скормить 128 4-битных чисел без объединения их в коде/компилятором в одну операцию, то процессор это выполнит скорее всего в 128 раз медленнее. Если у него декодер не увидит и не сделает нужных манипуляций, что он может уметь, а может и не уметь, и вообще на него лучше не перекладывать такую работу.
А видеокарта с поддержкой FP4 от подобного производительность как минимум не потеряет.

Помните страничную видеопамять у Вектор 06Ц и четырёх битное кодирование цвета, а эти 4 бита нужно было записать в одинаковые ячейки со сдвигом 8 кБ, а потом это считывалось и на цапе из 155РУ2 и резистивной матрице это всё можно было закодировать в 16 цветов (0 - 15 или 0Н - FH)из 256 цветовой палитры, при некоторых значениях оператора COLOR можно было получить инверсный текст.