Обсуждение:Округление

Эта статья имеет рейтинг C-класса по шкале оценки контента Википедии . Она представляет интерес для следующих WikiProjects :

Математика Средний приоритет Эта статья находится в рамках WikiProject Mathematics , совместных усилий по улучшению освещения математики в Википедии. Если вы хотите принять участие, посетите страницу проекта, где вы можете присоединиться к обсуждению и увидеть список открытых задач.Математика Википедия:WikiProject Mathematics Шаблон:WikiProject Mathematics математика Середина Данная статья имеет средний уровень приоритетности по шкале приоритетов проекта . Информатика Низкая важность Эта статья находится в рамках WikiProject Computer science , совместных усилий по улучшению охвата статей, связанных с Computer science, в Wikipedia. Если вы хотите принять участие, посетите страницу проекта, где вы можете присоединиться к обсуждению и увидеть список открытых задач.Computer scienceWikipedia:WikiProject Computer scienceTemplate:WikiProject Computer scienceComputer science Low This article has been rated as Low-importance on the project's importance scale. Things you can help WikiProject Computer science with: Here are some tasks awaiting attention: Article requests : Requested articles/Applied arts and sciences/Computer science, computing, and Internet Cleanup : Computer science articles needing attention Computer science articles needing expert attention Copyedit : Computing Expand : Computer science Infobox : Computer science articles without infoboxes Maintain : Timeline of computing 2020–present Photo : Find pictures for the biographies of computer scientists (see List of computer scientists) Computing articles needing images Stubs : Computer science stubs Unreferenced : WikiProject Computer science/Unreferenced BLPs Project-related : Tag all relevant articles in Category:Computer science and sub-categories with {{WikiProject Computer science}}

Эта страница в основном избыточна со Значащими цифрами#Округление , но я считаю, что это написано лучше, поэтому заслуживает объединения, а не удаления. ~ Irrel 17:33, 28 сентября 2005 (UTC) [ ответить ]

Пожалуйста, сдерживайте себя. Это очень разные темы. И эта страница не очень хорошо описывает округление. -- Cat5nap 05:46, 3 октября 2005 (UTC) [ ответить ]

Обсуждение на Talk:Significant figures#Merge в подавляющем большинстве против предлагаемого объединения Rounding с Significant figures . Я предлагаю удалить теги. Если что, я бы рассмотрел объединение с Truncation . Jimp 13Oct05

• Ну, это было решено примерно так, как я и предполагал (хотя слияние пошло в другую сторону). Независимо от этого, я не думаю, что размещение шаблона "слияние?" показывает отсутствие сдержанности, поскольку это просто запрос на ввод. На самом деле, сделать слияние, без обсуждения -- вот это было бы необузданно. ~ Irrel 20:20, 13 мая 2006 (UTC) [ ответить ]

"но если за пятеркой ничего не следует, нечетные последние сообщаемые цифры уменьшаются на единицу" Не следует ли увеличить это ? 68.227.80.79 05:44, 13 ноября 2005 (UTC) [ ответить ]

Да. Спасибо, что заметили это! -- Jitse Niesen ( обсуждение ) 12:21, 13 ноября 2005 (UTC) [ ответить ]

Надеюсь, что пересмотренная версия статьи тоже правильно это поняла. -- Хорхе Столфи ( обсуждение ) 05:52, 1 августа 2009 (UTC) [ ответить ]

У меня возник вопрос о том, все ли в мире округляют одинаково. В США есть два распространенных метода. Первый не требует особых пояснений и даже запрограммирован в таких программах, как MS Excel. Другой иногда называют научным округлением или округлением до четных 5. Я спрашиваю, потому что сталкиваюсь со многими иностранными профессионалами, которые округляют по-другому, поэтому я не знаю, не практикуются ли они или их учили по-другому. С философской точки зрения, на самом деле имело бы смысл округлять до значимых цифр простым усечением, потому что все, что находится за пределами цифры «наилучшего предположения», считается шумом и не должно влиять на сообщаемое значение. Однажды я спросил себя, какой из двух методов округления, используемых в США, является лучшим. Я подошел к вопросу, предположив, что шумовые цифры случайны и могут появляться с равной вероятностью. Если у меня есть набор значений со всеми возможными шумовыми цифрами и я вычисляю среднее значение и стандартное отклонение, а затем повторяю расчет среднего значения и стандартного отклонения после округления всех значений, то лучший метод не будет отклоняться от истинного среднего значения и стандартного отклонения. Оказалось, что метод округления до четных 5 на самом деле дал более точное среднее значение, но самый популярный метод округления дал более точное стандартное отклонение. Я не знаю, будет ли что-либо из этого интересно для этого урока по округлению, но подумал, что упомяну об этом. Джон Лич (обсуждение) 21:52, 6 июля 2020 (UTC) [ ответить ]

Как обрабатываются отрицательные числа? Согласно статье round(-1.5) = -2, что неверно, верно? round(-1.5) = -1 Я полагаю.

Существует множество различных реализаций. — Omegatron 19:59, 30 июня 2006 (UTC) [ ответить ]

Существует множество реализаций, и лишь немногие из них рассматриваются в этой статье. Вот внешняя статья, которая охватывает эту область [1]. Надеюсь, у кого-то будет время включить информацию из этой статьи, не занимаясь copyvio. - Harmil 15:55, 14 июля 2006 (UTC) [ ответить ]

Отрицательные числа должны быть надлежащим образом учтены в текущей версии. -- Хорхе Столфи ( обсуждение ) 05:52, 1 августа 2009 (UTC) [ ответить ]

Округление ВСЕХ чисел требует округления абсолютного значения числа, а затем замены исходного знака (+ или -). Вышеприведенный ответ - "-2", а не "-1". Если число, предшествующее "5", НЕЧЕТНОЕ, то сделайте его ЧЕТНЫМ, добавив "1". Если число, предшествующее "5", ЧЕТНОЕ, то оставьте его в покое. Так как в системе счисления равное количество НЕЧЕТНЫХ и ЧЕТНЫХ чисел.

Пример: «1,6 - 1,6 = 0», «1,6 + (-1,6) = 0», округление до единиц дает «2,0 + (-2,0) = 0», так как |-1,6| равно 1,6, округление дает нам «2,0».Пример: «1,4 - 1,4 = 0», «1,4 + (-1,4) = 0», округление до единиц дает «1,0 + (-1,0) = 0», так как |-1,4| равно 1,4, округление дает нам «1,0».Пример: «1,5 - 1,5 = 0», «1,5 + (-1,5) = 0», округление до единиц дает «2,0 + (-2,0) = 0», так как |-1,5| равно 1,5, округление дает нам «2,0».Пример: «2,5 - 2,5 = 0», «2,5 + (-2,5) = 0», округление до единиц дает «2,0 + (-2,0) = 0», так как |-2,5| равно 2,5, округление дает нам «2,0».

Округление числа никогда не может дать значение «0,0».

Округление зависит от типа округления. Округление до четного обычно объясняется как округление до ближайшего четного числа без упоминания абсолютных чисел или сложения или чего-то подобного. Числа 0,5 и -0,5 будут округляться до 0,0 при использовании округления до четного, я не знаю, почему вы так говорите.. Dmcq ( talk ) 19:29, 9 сентября 2009 (UTC) [ ответить ]

Не знаю, хорошая ли это идея — объединять с функцией floor , но они связаны. Некое подобие «генеалогического древа» функций округления:

• Пол
• Потолок
• Полукруглый
  • Половина округления вверх
    • Где вверху +∞
    • Где вверх далеко от нуля
  • Округление наполовину вниз
    • Где вниз - −∞
    • Где вниз, там к нулю
  • Полукруглый ровный
  • Полукруглый нечетный

Из раздела «Метод округления до четного» в этой статье, на данный момент:

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

А? Разве традиционное округление не предполагает равную долю округлений вверх и вниз? При традиционном округлении числа от 0 до <5 округляются до 0, а числа от 5 до <10 округляются до 10, если 10 — это увеличение следующей по величине цифры округляемого числа. Разница (<10 - 5) равна разнице (<5 - 0), не так ли? Я что-то упускаю? 4.242.147.47 21:13, 19 сентября 2006 (UTC) [ ответить ]

В четырех случаях (1, 2, 3 и 4) значение округляется в меньшую сторону. В пяти случаях (5,6,7,8,9) значение округляется в большую сторону. В одном случае (0) значение остается неизменным. Возможно, это то, что вы упустили. 194.109.22.149 15:14, 28 сентября 2006 (UTC) [ ответить ]

Но «неизмененное» не совсем верно, поскольку после 0 могут быть и другие цифры. Например, округленное до одного десятичного знака число 2,304 округляется до 2,3; оно не остается неизменным при традиционной схеме округления, а округляется в меньшую сторону, таким образом, существует пять случаев округления в меньшую сторону и пять случаев округления в большую сторону.

Если мы рассмотрим округление всех 0,00, 0,01, ..., 1,00 (101 числа) до ближайшего, то получим 50 нулей и 51 единицу. Общая сумма округления вниз составит , а сумма округления вверх составит . Таким образом, средняя ошибка составит . Важно отметить, что этот дисбаланс останется, даже если мы исключим 1 (где вы получите 50 чисел в каждую сторону), а средняя ошибка увеличится (точно до половины последней указанной цифры; это не совпадение). Это смещение; поскольку оно зависит не от детализации округления, а от данных, его легко пропустить. -- Tardis 07:10, 31 октября 2006 (UTC) [ ответить ]${\displaystyle -0.01+-0.02+...=\sum _{i=1}^{49}-i/100=-12.25}$${\displaystyle 0.50+0.49+...=\sum _{i=1}^{50}i/100=12.75}$${\displaystyle {\frac {-12.25+12.75}{101}}=0.0049505}$

Число 1,00 не должно появляться в этом расчете. Нас интересует округление интервала [0,00, 1,00) — то есть всех чисел >= 0,00 и < 1,00 (строго меньше 1). Как только число 1,00 удаляется из приведенного выше абзаца, дисбаланс исчезает (вопреки тому, что написано выше). На самом деле, при обычном округлении дисбаланса нет — интервал [0, 0,5) имеет ту же длину, что и интервал [0,5, 1).

Но, как и 1.00, 0.00 также не округляется. Поэтому интервалы будут (0, 0.5) и [0.5, 1) ; это приводит к смещению вверх. — Предыдущий комментарий без знака был добавлен 85.144.113.76 ( talk ) 00:06, 20 января 2007 (UTC).[ отвечать ]

Если вы посмотрите на расчет немного внимательнее, вы увидите, что он суммирует разницу между округляемым числом и результатом округления. В обоих случаях 0,00 и 1,00 это 0, поэтому неважно, включаете ли вы их в суммирование или нет.

Tardis сказал: "Это смещение; поскольку оно зависит не от гранулярности округления, а от данных, его легко упустить". Это важный момент. Если данные квантованы (гранулированы), то ошибка связана с размером квантования. Но для любого физического процесса задействованные числа обычно не квантуются, поэтому смещения вообще нет. Если вы повторите расчет выше с гранулярностью округления 0,1, но гранулярностью данных 0,0001 (скажем), то вы увидите это в действии. Таким образом, вывод заключается в том, что если округляемый вами набор данных не имеет квантования, вы должны использовать округление "0,5 идет вверх", а не банковское округление. 137.222.40.78 (обсуждение) 13:18, 23 мая 2008 (UTC) [ ответить ]

Если ваши данные "не квантуются" (включая дискретные вероятностные накопления), то вы можете округлить 0,5 до 23, если хотите. Этого почти никогда не происходит, так какая разница, что вы с этим делаете? В реальном мире этот предел никогда не достигается. -- Tardis ( обсуждение ) 11:11, 9 ноября 2008 (UTC) [ ответить ]

Я тоже только что думал об этой проблеме, но убежден, что существует дисбаланс в округлении от 0,5 до 1. Рассмотрим десять значений 0,0, 0,1, 0,2 ... 0,9, 1,0. Каждое из них охватывает диапазон 0,1. 0,0 охватывает диапазон от -0,05 до 0,05. 0,1 охватывает диапазон от 0,05 до 0,15. 1,0 охватывает диапазон от 0,95 до 1,05. Если вы хотите округлить до целых значений, у вас есть 0 и 1. 0 охватывает диапазон от -0,5 до 0,5, а 1 охватывает диапазон от 0,5 до 1,5. Таким образом, от 0,0 до 0,4 явно преобразуются в 0, а от 0,6 до 1,0 явно преобразуются в 1. Диапазон 0,5 идеально делится на две части диапазонами, которые охватывают 0 и 1. Преобразование 0,5 в 0 так же допустимо, как и преобразование в 1. Единственный способ решить, что лучше, — изучить контекст; я не вижу четкого правильного выбора для всех случаев, поскольку любое направление подразумевает компромиссы. 72.48.98.66 (обсуждение) 12:27, 20 июня 2010 (UTC) [ ответить ]

Да, поэтому используется округление до четных, это означает, что половина из них округляется вверх, а половина вниз. Округление до четных используется вместо округления до нечетных, поэтому вы с меньшей вероятностью получите нечетные цифры, в частности 5 в конце в последующих вычислениях, что означает, что вы делаете меньше округлений в целом. Dmcq ( talk ) 12:50, 20 июня 2010 (UTC) [ ответить ]

Чтобы высказать свое мнение по этому небольшому спору, округление 0,5 вверх приводит к более равномерному распределению значений в десятичной системе в целом. Если вы разделите числа на наборы по 10, где n представляет все, кроме младшей цифры, n0-n9 — это 10 чисел, а следующее число является частью следующего набора (n10, что означает, что 1 «переносится»). Поскольку обсуждаемое округление касается десятичной системы счисления, вы должны следовать делениям этой системы. Другими словами, округление можно рассматривать как операцию над всеми возможными значениями младшей цифры числа (и рассматривать рекурсивно для расширения), что означает, что должны быть изменены только значения для младших цифр, как только вы изменяете число в любом другом месте, вы вводите новый набор (и должны были бы ввести полный набор для согласованности). Итак, 5 чисел вниз 0-4, 5 чисел вверх 5-9 (обратите внимание, что есть только один «0»). Я бы представил себе, что система округления до четного вытекает из проблемы, что "0" не округляется. Поэтому при работе с наборами данных, где точные значения по какой-то причине исключены или менее вероятны, чем значения, которые должны быть округлены, часть баланса должна быть смещена. Основная причина, по которой я кричу, заключается в том, что, похоже, "асимметричный" в статье относительно округления 0,5 вверх используется неправильно, поэтому это следует либо процитировать, либо удалить. -mwhipple — Предыдущий неподписанный комментарий, добавленный 98.229.243.133 ( обсуждение ) 18:13, 1 октября 2010 (UTC) [ ответить ]

И если немного расширить сказанное выше, то метод округления до четного, вероятно, более уместен, когда имеешь дело с менее определенными множествами (т. е. есть плохо определенный, неизвестный или иным образом проблемный минимум или максимум). —Предыдущий комментарий без знака, добавленный 98.229.243.133 ( обсуждение ) 18:22, 1 октября 2010 (UTC)[ отвечать ]

Ох... и округление до четного числа было бы удобным способом компенсировать проблемы округления, вызванные проблемами с представлением чисел с плавающей точкой в ​​компьютерах. —Предыдущий комментарий без знака добавлен 98.229.243.133 ( обсуждение ) 19:07, 1 октября 2010 (UTC) [ ответить ]

Проигнорируйте большую часть вышесказанного, за исключением части о неправильном использовании асимметричности. Я был слишком занят системой счисления, что упустил из виду значения. Округление изменяет значения, и поэтому значимый набор — это неточные числа (и накопленное изменение). Аргумент ниже немного вырван из контекста (хотя и подчеркивает некоторые из моих плохих формулировок) — Предыдущий неподписанный комментарий, добавленный 98.229.243.133 ( обсуждение ) 22:31, 1 октября 2010 (UTC)[ отвечать ]

Числа считаются округленными до точности и охватывают диапазон немного ниже, а также выше точного числа. Так что 0,5 означает все в диапазоне от 0,45 до 0,55, это не означает от 0,5 до 0,6. Ваш первоначальный аргумент о 0,0 .. 0,9 неверен, те, что от -0,05 до 0,05 должны округляться до 0,0, это не округление от 0,0 до 0,1 до 0,0 Dmcq ( talk ) 19:28, 1 октября 2010 (UTC) [ ответить ]

Я поражен, что любой серьезный ученый может утверждать, что между целыми числами в десятичной системе есть либо числа x+1, либо x-1. При полной дискретности существует равное количество чисел, которые идут к меньшему целому числу, как и к большему целому числу. 2,0, 2,1, 2,2, 2,3 и 2,4 идут к 2, 2,5, 2,6, 2,7, 2,8 и 2,9 идут к 3, 5 каждое. То же самое было бы верно от 1,0 до 1,9, а затем от 3,0 до 3,9. Каждое целое число будет иметь 10 чисел, которые могут привести к такому округлению. Правило разрешения конфликтов глупо, и, как инженеры знают уже много лет, неверно. Если вы хотите получить истинный ответ, вы никогда не анализируете округленные числа! Вы должны использовать фактические значения, чтобы выйти за пределы как минимум одной значимой цифры того, что вы пытаетесь проанализировать. Это сбивает с толку, без необходимости, детей в сегодняшних школах. Вернитесь к тому, что мы знали годами, и может быть доказано, что это правильно. И никогда, никогда не анализируйте округленные числа до той же значащей цифры, если вы знаете, что набор данных более сдержан. — Предыдущий комментарий без знака добавлен 24.237.80.31 (обсуждение) 04:24, 3 ноября 2013 (UTC) [ ответить ]

Это зависит от модели и контекста. Вы можете предположить равномерное распределение в интервале [0,1], в этом случае средняя точка 0,5 появляется с нулевой вероятностью, так что при этом предположении выбор для половинных точек не имеет значения. На практике это неверно, поскольку у вас есть определенные входные данные и алгоритмы, но тогда лучший выбор зависит от фактического распределения входных данных (либо истинных входных данных программы, либо промежуточных результатов). Винсент Лефевр ( talk ) 13:37, 20 апреля 2015 (UTC) [ reply ]

Кажется, существует по крайней мере еще один метод: округление в большую или меньшую сторону с вероятностью, определяемой близостью.

В JavaScript это задается как
R = Math.round(X + Math.random() - 0.5)

Возможное преимущество состоит в том, что среднее значение R для большого набора округлений константы X равно самому X.

82.163.24.100 11:51, 29 января 2007 (UTC) [ ответить ]

Это называется «дизеринг». Добавил раздел об этом. -- Хорхе Столфи ( обсуждение ) 05:41, 1 августа 2009 (UTC) [ ответить ]

В разделе сглаживания говорится: "Это эквивалентно округлению y + s до ближайшего целого числа, где s — случайное число, равномерно распределенное между 0 и 1". Я не математик, поэтому, возможно, что-то упускаю, но, похоже, это округляет ваш пример до 23 с вероятностью .33 и до 24 с вероятностью .67 вместо .83 и .17. Должно быть "округление y+s к 0"? (для y>=0 в любом случае) M frankied (обсуждение) 18:31, 9 августа 2010 (UTC) [ ответить ]

Да, следовало бы сказать округление в меньшую сторону, а не округление к ближайшему, я обновил текст. Dmcq ( обсуждение ) 18:42, 9 августа 2010 (UTC) [ ответ ]

Может ли кто-нибудь объяснить мне, почему - и почему это имеет смысл - мы округляем, скажем, 1,5 до 2, а не до 1? Вот мои мысли: 1,1, 1,2, 1,3 и 1,4 округляются до 1 - 1,6, 1,7, 1,8, 1,9 округляются до 2. Так что 1,5, конечно, находится прямо посередине. Почему мы должны предполагать, что это больше 2, чем 1, если это одинаково близко? Вы думаете, это просто потому, что учителя добрые, и когда они выставляют средние оценки, они хотят немного поднять вам оценку, а не понизить? Есть ли какое-то философское или математическое обоснование? Идея вики 23:38, 6 февраля 2008 (UTC) [ ответить ]

Вы забыли 1.0. — Предыдущий неподписанный комментарий добавлен 207.245.46.103 ( обсуждение ) 19:08, 7 февраля 2008 (UTC) [ ответить ]

Я ведь тоже забыл 2.0, верно? Идея Вики 19:41, 7 февраля 2008 (UTC) [ ответить ]

Я не вижу веской причины. Конвенция полезна, но могло бы быть и наоборот.-- Патрик ( обсуждение ) 23:46, 7 февраля 2008 (UTC) [ ответить ]

Это именно то, о чем я тоже думаю! Так что, возможно, это правда: учителя математики просто были любезны, отмечая средние результаты тестов учеников! Они могли бы иметь соглашение в другом направлении. Идея Вики 00:01, 8 февраля 2008 (UTC) [ ответить ]

Или продавцы придумали его для нахождения цены половины единицы. Но более вероятно, что они округляют все сломанные значения, а не только те, что на полпути.-- Патрик ( обсуждение ) 00:22, 8 февраля 2008 (UTC) [ ответить ]

См. обсуждение выше, вопрос «Какой метод вносит больше всего ошибок?». Думаю, я отзову свое утверждение 1.0. —Предыдущий неподписанный комментарий добавлен 207.245.46.103 ( обсуждение ) 18:30, 8 февраля 2008 (UTC) [ ответить ]

Надеюсь, текущая версия статьи проясняет, что это всего лишь произвольный выбор (а какой-то выбор необходим). Всего наилучшего, -- Хорхе Столфи ( обсуждение ) 05:47, 1 августа 2009 (UTC) [ ответить ]

Плавающий блок на обычном ПК работает с числами IEEE-754, числами с плавающей двоичной точкой. Я не видел, чтобы на этой странице или на этой странице обсуждения рассматривалась проблема округления двоичных дробных чисел до указанного количества знаков десятичной дроби. Проблема возникает из-за того, что переменные с двоичными дробями с точкой, как правило, не могут точно представлять числа десятичной дроби. Это можно увидеть из следующей таблицы. Эта таблица является попыткой представить числа от 1,23 до 1,33 с шагом 0,005.

ExactFrac Приблизительно. Ближайший IEEE-754 (64-битное число с плавающей запятой)1230/1000 1,230 1,2299999999999999822364316059974953532218933105468751235/1000 1,235 1,23500000000000009769962616701377555727958679199218751240/1000 1,240 1,23999999999999999111821580299874767661094665527343751245/1000 1,245 1,245000000000000106581410364015027880668640136718751250/1000 1.250 1.251255/1000 1,255 1,254999999999999893418589635984972119331359863281251260/1000 1,260 1,26000000000000000000000000888178419700125232338905334472656251265/1000 1,265 1,26499999999999990230037383298622444272041320800781251270/1000 1,270 1,2700000000000000177635683940025046467781066894531251275/1000 1,275 1,2749999999999999111821580299874767661094665527343751280/1000 1,280 1,28000000000000002664535259100375697016716003417968751285/1000 1,285 1,28499999999999992006394222698872908949851989746093751290/1000 1,290 1,290000000000000035527136788005009293556213378906251295/1000 1,295 1,29499999999999992894572642398998141288757324218751300/1000 1.300 1.30000000000000004440892098500626161694526672363281251305/1000 1,305 1,30499999999999993782751062099123373627662658691406251310/1000 1,310 1,3100000000000000532907051820075139403343200683593751315/1000 1,315 1,3149999999999999467092948179924860596656799316406251320/1000 1,320 1,32000000000000006217248937900876626372337341308593751325/1000 1,325 1,32499999999999995559107901499373838305473327636718751330/1000 1,330 1,3300000000000000710542735760100185871124267578125

Точный результат деления, указанный в первом столбце, показан как длинное число в третьем столбце. Предполагаемый результат находится во втором столбце. Следует отметить, что только одно из частных является точным; остальные лишь приблизительны. Таким образом, когда мы пытаемся округлить наши числа вверх или вниз, мы не можем использовать правила, основанные на простых больше, меньше или на некотором точном значении десятичной дроби, потому что, как правило, эти значения десятичной дроби не имеют точного представления в числах двоичной дроби. JohnHD7 (обсуждение) 22:08, 28 июня 2008 (UTC) [ ответить ]

Это не уникально для десятичных дробей и достаточно хорошо покрыто в плавающей точке . Операции с плавающей точкой имеют конечную точность, что приводит к ошибкам округления, которые могут накапливаться. Если вам нужно, чтобы ваш код генерировал определенное количество точных десятичных (или двоичных и т. д.) знаков или удовлетворял какому-либо другому критерию точности, вы должны проверить, что наихудшее отклонение, которое может генерировать ваш код, остается в пределах. Shinobu ( talk ) 07:18, 8 ноября 2008 (UTC) [ ответить ]

Я видел два источника, которые утверждают, что правильно округлять (например) 2,459 до 2,4, а не до 2,5, хотя они оба приводят одну и ту же фальшивую логику: что 2,45 можно округлить как до 2,4, так и до 2,5, и поэтому это применимо и к 2,459, хотя это другое число и оно, очевидно, ближе к 2,5. Но уверены ли мы, что это не стандартная практика в какой-нибудь сумасшедшей области или чем-то подобном? Evercat ( обсуждение ) 20:51, 17 сентября 2008 (UTC) [ ответить ]

Это недопустимый метод округления, так как результат может значительно отклоняться более чем на половину целого шага от оригинала. Если он где-то действительно используется, пользователи должны получить по рукам. Возможно, если его использование вызовет большой скандал, было бы уместно задокументировать это в Википедии, но пока ему не хватает известности. Shinobu ( обсуждение ) 07:07, 8 ноября 2008 (UTC) [ ответить ]

Согласен. Эти источники, вероятно, просто неправы. -- Хорхе Столфи ( обсуждение ) 05:44, 1 августа 2009 (UTC) [ ответить ]

Пожалуйста, прокомментируйте: округление 2.50001 до ближайшего целого числа. Это 2 или 3? Redding7 (обсуждение) 01:42, 5 января 2010 (UTC) [ ответить ]

Определенно 3 (расстояние от 2,50001 до 2 составляет 0,50001, до 3 — 0,49999, так что последнее ближе всего). — Хорхе Столфи ( обс .) 03:02, 5 января 2010 (UTC) [ ответить ]

Пожалуйста, отредактируйте «Функции округления в языках программирования» для единообразия именования. Я не уверен, какие имена вы предпочитаете, поэтому я позволю вам сделать это, но, пожалуйста, будьте последовательны. Shinobu ( обсуждение ) 07:07, 8 ноября 2008 (UTC) [ ответить ]

Раздел «Общий метод» не объясняет отрицательные числа. Первый пример отрицательного числа просто говорит «один округляет вверх также», но показывает другое поведение для случая 5, в противном случае то же самое, что и положительное. Второй пример должен быть противоположным, но показывает то же самое! Он называет это «вниз» вместо «вверх», но дает тот же ответ. — Długosz ( talk ) 19:55, 18 февраля 2009 (UTC) [ ответить ]

Раздел был полностью переписан. Проверьте, была ли исправлена ​​проблема. -- Jorge Stolfi ( обсуждение ) 05:42, 1 августа 2009 (UTC) [ ответить ]

В статье утверждается, что

«Некоторые метеорологи могут писать «-0», чтобы указать температуру между 0,0 и −0,5 градуса (исключая), округленную до целого числа. Это обозначение используется, когда отрицательный знак считается важным, независимо от того, насколько мала величина; например, при указании температуры по шкале Цельсия , где значение ниже нуля означает замерзание».

Меня беспокоит этот абзац, потому что (1) следует предоставить доказательства того, что метеорологи действительно это делают; это вполне может быть оригинальным изобретением редактора. Также (2) подсчет дней с отрицательной температурой кажется довольно ненаучной идеей, поскольку даже небольшие ошибки в измерениях могут привести к большой ошибке в результате. Если термометр на станции показывает -0,4C или -0,1C, то нет уверенности, что уличные лужи замерзают. С другой стороны, если термометр показывает +0,1C или +0,4C, то лужи все равно могут замерзать. Чтобы сравнить суровость погоды, следует использовать более надежную статистику, например, среднюю температуру. Поэтому, похоже, нет веских оправданий для сохранения знака минус. Всего наилучшего, -- Хорхе Столфи ( обсуждение ) 06:03, 1 августа 2009 (UTC) [ ответить ]

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

$XX.XXY округлялось «вверх», если Y было нечетным, и «вниз», если Y было четным. (5 из 10 вариантов в каждом направлении)

Например:

Я забыл, как он обрабатывал отрицательные случаи... Приведенный «банковский раунд» (округление половины к четному) выполняет одну из тех же целей симметричного округления, но другим способом, потенциально с предвзятостью, которая имеет отношение к финансам, и мне интересно, отсутствует ли в статье этот метод (и если да, то стоит ли его добавлять тому, кто точно знает детали), задокументирован ли он где-либо еще в Википедии, или использовался ли он вообще, или был неверен в моем источнике ранее! (Возможно, Википедия, iirc). Преимущества этого, по-видимому, в основном «случайны» с равномерным распределением в том смысле, что вещи не движутся к ближайшему числу на требуемом уровне точности, где это можно определить, но с повторяющимися результатами. FleckerMan (обсуждение) 01:03, 18 августа 2009 (UTC) [ ответить ]

Действительно, похоже, это другой метод округления. Его следует добавить в раздел «Базовое округление до целого числа», но переформулировать как округление XXX.Y до целого числа. Однако этот метод не округляет до ближайшего допустимого значения. Если бы я был клиентом такого банка, я бы чувствовал себя обманутым (хотя в долгосрочной перспективе этот метод справедлив). 8-) -- Хорхе Столфи ( обс .) 17:29, 18 августа 2009 (UTC) [ ответить ]

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

Я поискал в Google, но пока не нашел ничего, хотя бы отдаленно напоминающего достойную ссылку на эту тему.

Вкратце, «разница», вызванная округлением одного значения (доля цента), переносится вперед и добавляется к следующему результату, прямо перед округлением. Это продолжается до самого конца. Цель состоит в том, что если вы добавляете «p%» процентов к каждому из длинной строки счетов, то каждый получит «p%» процентов (в пределах пенни), и конечный результат покажет, что (общая сумма до процентов) * (1+p%) = (общая сумма конечных сумм, рассчитанных для каждого из счетов). И да, если все сделано правильно, конечные итоги всегда совпадают.

Поэтому нам следует искать источники, которые говорят: «Начните с 0,5 в вашем «переносе». Добавьте «перенос» перед округлением. Установите «перенос» на сумму, «полученную» или «потерянную» в результате этого округления».

-- Джефф Григг 68.15.44.5 (обсуждение) 00:44, 20 октября 2017 (UTC) [ ответить ]

Я удалил длинный список функций округления в языке X, Y, Z, ... Он был бесполезен для читателей (программисты найдут его в статье о языке, а не здесь), он был слишком длинным (и все еще далеким от завершения) и чрезвычайно повторяющимся (большинство языков теперь просто предоставляют четыре основные функции округления IEEE -- trunc, round, ceil, floor). Списки не были удалены, а просто перемещены в соответствующие статьи языка (уф!). Всего наилучшего, -- Хорхе Столфи ( обсуждение ) 22:31, 6 декабря 2009 (UTC) [ ответить ]

Выглядит намного лучше без них. Я долго думал, что делать с такими разделами во многих статьях. Думаю, стоит упомянуть только некоторые реализации стандартной библиотеки, списки языков, конечно, излишни. Dmcq ( обсуждение ) 23:22, 6 декабря 2009 (UTC) [ ответить ]

Список базовых функций округления IEEE, конечно, состоит из 4 функций, потому что в большинстве случаев он забывает говорить об отрицательных числах. Именно здесь округление вверх или вниз отличается от округления к нулю или от нуля. Затем для функции "round" также есть 4 режима округления, которые доступны для всех операций с плавающей точкой, независимо от этих функций округления: речь идет о том, как округляются числа с плавающей точкой: вверх или вниз? Здесь снова есть те же 4 режима, плюс 2 дополнительных режима для округления до ближайшего четного и округления до ближайшего нечетного... IEEE не имеет никаких рандомизированных режимов округления и не поддерживает сглаживание с переменными смещениями (единственные поддерживаемые смещения - 0 для функций floor и ceil и связанная с ними функция "truncate" (округление до нуля) и 0,5 для функции round). IEEE также не имеет округления до бесконечности (округление от нуля) и округления до нечетного, поскольку они не имеют практического применения....

Однако «округление до ближайшего целого числа и округление до нуля» имеет математические приложения (особенно при вычислении кратчайших непрерывных дробей любого рационального числа) из-за своей симметрии: свойство округления до ближайшего числа позволяет свести непрерывные дроби к наименьшей форме (с меньшим количеством членов), а симметрия позволяет отрицательному рациональному числу иметь точно такие же члены (по абсолютной величине) в непрерывной дроби, как и противоположное положительное рациональное число. При меньшем количестве членов (из-за округления до ближайшего) это также позволяет непрерывным дробям сходиться в два раза быстрее на каждый член (поэтому количество членов фактически делится в среднем на 2 при выражении любого действительного числа в виде непрерывных дробей: это особенно важно при оптимизации скорости численного вычисления иррациональных функций, но также это обеспечивает лучшую числовую устойчивость результата при работе с числами с плавающей точкой (с ограниченной точностью), производя более точные числа и монотонные приближения (если мы используем ограниченное количество членов при вычислении аппроксимаций непрерывных дробей, начиная с последнего члена)... verdy_p ( talk ) 01:54, 12 августа 2010 (UTC) [ reply ]

Кажется, есть много вещей, которые я не помню, чтобы видел где-то еще здесь. Думаю, мне нужно вставить несколько цитат, необходимых в статье. Dmcq ( talk ) 19:58, 12 августа 2010 (UTC) [ ответить ]

Я подумывал добавить это:

Преимущество «округления до четного» (если основание не кратно 4) заключается в том, что оно предотвращает распространение проблемы половин. Рассмотрим 23,55: с правилом «округления до нечетного» это будет 23,5, а затем 23, хотя 24 будет ближе. Вместо этого 23,55 округляется до 23,6, а затем до 24.

Это объясняется в главе 4 «Искусства программирования» , если не ошибаюсь, и я бы процитировал ее, если бы мой экземпляр не был спрятан где-то в коробке. — Tamfang ( обсуждение ) 03:04, 19 июля 2010 (UTC) [ ответить ]

Да, и именно поэтому «округление до нечетного» не является частью стандартных режимов округления IEEE-754 (поэтому оно не имеет собственной поддержки в x87 FPU), а также объясняет, почему «округление до четного» является режимом по умолчанию для плавающих точек в ANSI C, C++, Java и многих других языках, поддерживающих или использующих типы с плавающей точкой (включая Javascript, несмотря на то, что Javascript не требует какой-либо минимальной точности для чисел, за исключением того, что они обрабатываются так, как если бы они были в десятичном виде с бесконечной точностью, как указано в их исходном текстовом представлении). verdy_p ( talk ) 02:00, 12 августа 2010 (UTC) [ ответить ]

Причина в том, что если вы сложите два случайных числа примерно одинаковой величины, вам вряд ли придется округлять сумму, если они являются результатами округления до четного, поэтому вам понадобится меньше операций округления в целом. Dmcq ( обсуждение ) 09:09, 12 августа 2010 (UTC) [ ответить ]

Вам все равно понадобится округление, потому что такое сложение четных чисел будет сопротивляться только один раз, прежде чем снова понадобится новое округление для наименее значимого бита. В среднем это просто разделит на 2 остаточную ошибку, созданную накопленными значениями, т. е. это просто добавит один бит точности к сумме. Если вы накапливаете много значений, этот один бит быстро перестанет быть очень значимым в общей ошибке, оставшейся в сумме. Поэтому утверждение, что «это предотвращает распространение проблемы половин», ложно. Это просто уменьшает проблему на 50%.

Есть еще одна модель, «округление до нечетного», которая лучше сохраняет величину, и поэтому лучше предотвращает это распространение ошибок (но также не предотвращает его полностью). К сожалению, это не режим округления по умолчанию.

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

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

Например, при округлении 64-битных элементов типа double до 32-битных float, сложите исходные значения до 64-битных double и используйте эту высокоточную сумму для окончательного округления суммы до 32-битных float: это также объясняет, почему C и C++ автоматически повышают значения float до double внутри выражений и округляют обратно до 32-битных float только результат полного выражения, если выражение имеет семантику float (т. е. не было явно повышено до double ); во всех остальных случаях компилятор предупредит программиста о возможной потере точности.

Однако это автоматическое продвижение без промежуточного округления до точности float не произойдет, если функция скомпилирована с семантикой "strict floatting point", где округление будет происходить после каждой операции, даже если это создает большие ошибки округления в конечном результате выражений. Режимы вычисления "relaxed" и "strictfp" также существуют в Java. Обычно использовать режим округления "strictfp" - плохая идея, если только вы не хотите строгой переносимости с системами, которые не поддерживают вычисления с 64-битной двойной точностью (такие системы сейчас встречаются крайне редко).

Фактически, C и C++ также могут вычислять выражения, также неявно продвигая также 32-битные float и 64-битные double в более точный long double (обычно 80-битной ширины на системах x87) внутри выражений. Эффективное округление до 32-битных или 64-битных значений происходит только при сохранении результата в переменной float или double или при передаче его в качестве параметра функции, конструктору или методу. Здесь снова режим вычислений "strictfp" может заставить компилятор округлить все промежуточные значения long double до их семантического 32-битного или 64-битного типа.

В C, C++ и Java (и, вероятно, также во многих других языках, поддерживающих стандарт IEEE 754) режим вычислений "strictfp" не является режимом по умолчанию и должен быть указан явно, либо в исходном коде с дополнительными ключевыми словами-модификаторами в объявлении функции, либо в объявлении блока операторов (или иногда внутри заключенного в скобки подвыражения), либо с помощью специальной опции компилятора. Скомпилированный код будет менее эффективным из-за дополнительных операций округления, которые будут скомпилированы и выполнены во время выполнения. verdy_p ( talk ) 23:47, 12 августа 2010 (UTC) [ reply ]

Пожалуйста, перестаньте просто утверждать вещи и вместо этого вставьте несколько цитат. Куча пустых слов не делает то, что вы говорите, лучше. Dmcq ( talk ) 07:43, 13 августа 2010 (UTC) [ ответить ]

Меня учили, что "округлить половину до четного" также называют правилом "7-up". Кто-нибудь еще знает об этом? 216.58.55.247 (обс.) 00:36, 26 декабря 2010 (UTC) [ ответить ]

Почему он так называется? Oli Filth ^{( обсуждение | вклад )} 00:52, 26 декабря 2010 (UTC) [ ответить ]

Нет, никогда о таком не слышал. Похоже на идею какого-то учителя. Я бы предположил, что идея в том, что 7-up пишется с точкой после 7, а 7.5 округляется до 8, так как 7 — нечетное число. Просто мое предположение. Dmcq ( talk ) 10:09, 26 декабря 2010 (UTC) [ ответить ]

Я сократил разделы о сглаживании и масштабированном округлении. Сглаживание лучше рассматривать в другом месте. Масштабированное округление не имело ссылок и было длинным и бессвязным и было вставлено в числа с плавающей точкой без всякой причины. Dmcq ( обсуждение ) 23:30, 10 декабря 2011 (UTC) [ ответ ]

В частности, ссылаясь на округление § Двойное округление , представляется важным, что при использовании нечетного основания многократное округление AFAICT является стабильным.при условии, что мы начинаем с конечной точности (на самом деле с более широкого класса значений, который исключает только ограниченный набор повторяющихся значений). Наверняка работа по этому вопросу была опубликована, и это было бы уместно упомянуть в этой статье? — Quondum 06:17, 20 ноября 2012 (UTC) [ ответить ]

Хм. Мне кажется, что по этому поводу почти ничего не опубликовано. Жаль. — Quondum 19:21, 23 апреля 2015 (UTC) [ ответить ]

Причина может быть в том, что нечетное основание никогда не используется на практике (за исключением основания 3 на Setun в прошлом). Vincent Lefèvre ( обсуждение ) 22:08, 23 апреля 2015 (UTC) [ ответ ]

Может быть, не все так плохо; поиск Google по словам «Сетунь» и «округление» выдает некоторые результаты. Рассмотрим [2], Сбалансированная троичная система («Дональд Кнут указал, что усечение и округление — это одна и та же операция в сбалансированной троичной системе»), [3] («идеальное округление достигается просто усечением») — этого может быть достаточно для этой статьи. Нам придется сделать несколько очевидных выводов, например, что повторное идеальное округление все еще является идеальным округлением. Мы могли бы ограничить комментарий исходным троичным случаем, хотя он должен применяться без изменений к любому нечетному основанию. — Quondum 23:05, 23 апреля 2015 (UTC) [ ответить ]

Интересно, следует ли добавить параграф об округлении по Фон Нейману и липком округлении, или это считается оригинальным исследованием (на практике не используется, за исключением внутренних целей, в частности, нет открытого API, нет стандарта, нет стандартной терминологии...). Короче говоря: округление по Фон Нейману (введено AW Burks, HH Goldstine и J. von Neumann, Preliminary discussion of the logical design of an electronic computing instrument , 1963, взято из отчета в US Army Ordnance Department, 1946) состоит в замене младшего бита усечения на 1 (в двоичном представлении); цель состояла в том, чтобы получить статистически несмещенное округление (как утверждается в этой статье) без распространения переноса. В работе On the precision untilable with various floating-point numeric systems , 1972, Брент предложил не делать этого для точно представимых результатов. Это соответствует режиму округления с прилипанием (термин, используемый Дж. С. Муром, Т. Линчем и М. Кауфманном, Механически проверенное доказательство корректности ядра алгоритма деления с плавающей точкой AMD5K86™ , 1996), также известному как округление до нечетного (термин, используемый С. Болдо и Г. Мелькиондом, Эмуляция FMA и правильно округленные суммы: доказанные алгоритмы с использованием округления до нечетного , 2006); его можно использовать, чтобы избежать проблемы двойного округления. Винсент Лефевр ( обсуждение ) 13:58, 20 апреля 2015 (UTC) [ ответить ]

Я думал, что это стандартно иметь бит округления и бит прилипания в описаниях того, как все это делается в IEEE. Вы это имеете в виду? Я бы подумал, что это должно войти в какую-нибудь статью IEEE. Dmcq ( talk ) 15:34, 20 апреля 2015 (UTC) [ ответить ]

Бит округления и бит прилипания — хорошо известные понятия (хотя они используются только разработчиками, т. е. о них ничего не говорится в стандарте IEEE 754, например). Однако округление прилипания можно рассматривать как способ включения полезной части информации бита округления и бита прилипания в возвращаемое значение (в основном внутренне, перед вторым округлением в целевой точности), и оно используется гораздо реже. Винсент Лефевр ( обсуждение ) 21:21, 20 апреля 2015 (UTC) [ ответить ]

Я удалил предложения о липком округлении. Если кто-то хочет добавить их обратно, у них должен быть свой собственный раздел, как и у других методов функционального округления. Я думал, что предложения, которые были, были неадекватны для описания того, как они работают и почему они важны. Это довольно неясный метод, и я не эксперт по нему. StephenJohns00 (обсуждение) 04:47, 13 августа 2018 (UTC) [ ответить ]

IBM в своих zSeries и pSeries реализует следующий метод (цитируется по «z/Architecture Principles of Operation»):

> Округлите, чтобы подготовиться к меньшей точности: для допустимого набора BFP или HFP выбранным кандидатом является тот, чья голосующая цифра имеет нечетное значение. Для допустимого набора DFP выбирается кандидат, который меньше по величине, если только его голосующая цифра не имеет значение 0 или 5; в этом случае выбирается кандидат, который больше по величине.

Здесь BFP — это двоичный код IEEE754, DFP — это десятичное число IEEE754, а HFP — это двоичный код старого образца S/360/шестнадцатеричный код с плавающей точкой. Думаю, стоит перечислить. Netch 06:42, 07 июня 2021 (UTC) [ ответить ]

Я думаю, что в этой статье нужно объяснить, что «Округление на половину вверх» НЕ является асимметричным для таких вещей, как секундомеры, тогда как «Округление на половину вниз» просто неправильно в таких случаях. Это может быть (или не быть) частью причины, по которой «Округление на половину вверх» является более распространенным правилом.

Дело в том, что когда секундомер показывает, например, 0,4, это на самом деле означает «не менее 0,4, но меньше 0,5», что в среднем составляет 0,45. Таким образом, округление становится симметричным — 0,0 на самом деле 0,05, что теряет 0,05, чему соответствует выигрыш в 0,05, когда 0,9 (что на самом деле 0,95) округляется вверх, и аналогично 0,1 (что на самом деле 0,15) соответствует 0,8 (что на самом деле 0,85), 0,2 (что на самом деле 0,25) соответствует 0,7 (что на самом деле 0,75), 0,3 (что на самом деле 0,35) соответствует 0,6 (что на самом деле 0,65), и, наконец, 0,4 (что на самом деле 0,45) соответствует 0,5 (что на самом деле 0,55).

Вероятно, многие другие процессы измерения имеют сходство с секундомерами.

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

Кстати, можно привести веские доводы в пользу того, чтобы сразу же поместить большую часть вышеизложенного в статью, не ища надежных источников для ее подтверждения (поскольку большая часть статьи не имеет таких источников — самоочевидная истина не нуждается в подтверждающих источниках), но если так, то, по крайней мере, на данный момент я предпочитаю предоставить кому-то другому возможность попытаться сделать это, поскольку такой человек меньше рискует быть обвиненным в «предвзятости в пользу своего собственного неприемлемого оригинального исследования» (самоочевидная истина не является оригинальным исследованием, но всегда может быть обозначена как таковая в среде вроде Википедии). Tlhslobus ( обсуждение ) 10:13, 12 апреля 2016 (UTC) [ ответ ]

Поразмыслив, я решил просто добавить немного этой очевидной истины и посмотреть, что из этого получится. Tlhslobus ( обсуждение ) 10:43, 12 апреля 2016 (UTC) [ ответить ]

То, что вы говорите, это просто то, что секундомер округляет до одного десятичного знака, так что может возникнуть проблема двойного округления. Вам действительно нужна ссылка, прежде чем выкладывать свои собственные мысли о таких вещах. Dmcq ( talk ) 18:13, 12 апреля 2016 (UTC) [ ответить ]

Была та же проблема с предвзятостью, которая также вызвана двойным округлением. Я удалил соответствующий текст для согласованности. Vincent Lefèvre ( talk ) 20:17, 12 апреля 2016 (UTC) [ ответить ]

Обсуждение удаления по смежной теме происходит на Wikipedia:Статьи по удалению/Синтаксис округления Mathcad . Один из возможных результатов, который я намерен предложить, — это объединение с разделом «Функции округления в языках программирования» здесь. Пожалуйста, примите участие, если у вас есть мнение. — Дэвид Эппштейн ( обсуждение ) 19:21, 28 июня 2016 (UTC) [ ответить ]

Что-то я тут не понимаю. В тексте говорится, что -23,5 следует округлить до -24, но когда я пытаюсь применить формулу, то получаю -23.

${\displaystyle q=-\left\lceil -y-0.5\right\rceil -1+\left|\operatorname {sgn}((y\!\!\!\!\mod 2)-0.5)\right|}$

${\displaystyle y=-23.5}$

${\displaystyle q=-\left\lceil -(-23.5)-0.5\right\rceil -1+\left|\operatorname {sgn}((-23.5\!\!\!\!\mod 2)-0.5)\right|}$

${\displaystyle q=-\left\lceil 23.5-0.5\right\rceil -1+\left|\operatorname {sgn}((-1.5)-0.5)\right|}$

${\displaystyle q=-\left\lceil 23\right\rceil -1+\left|\operatorname {sgn}(-2)\right|}$

${\displaystyle q=-23-1+\left|-1\right|}$

${\displaystyle q=-23-1+1}$

${\displaystyle q=-23}$

Может кто-нибудь сказать мне, в чем проблема? Может быть, я не совсем понимаю часть. -- 181.16.134.10 (обсуждение) 19:42, 26 декабря 2016 (UTC) [ ответить ]${\displaystyle \left|\operatorname {sgn}((y\!\!\!\!\mod 2)-0.5)\right|}$

Лично я считаю, что эту формулу следует удалить, поскольку modulo может иметь много разных определений в компьютерных языках. Я думаю, что я прикреплю к ней необходимую ссылку, которая позволит кому-то другому удалить ее в будущем. В любом случае, в математике обычное определение таково: результат 0 <= результат < абсолютное значение делителя. Это означает, что -23,5 mod 2 дает 0,5, а не -1,5. Dmcq ( talk ) 20:29, 26 декабря 2016 (UTC) [ reply ]

Да, для справки: операция по модулю . В математике я не уверен, что есть стандартное определение; обычно используется отношение эквивалентности: n ≡ k mod m (ISO 80000-2:2009). Более того, формула слишком сложна, чтобы быть действительно полезной на WP, IMHO. И она не обязательно будет использоваться в реализациях (вероятно, нет). Vincent Lefèvre ( talk ) 22:36, 26 декабря 2016 (UTC) [ ответить ]

Привет, Дэвид Эппштейн ,

Я оставляю это, поскольку мне любопытно, почему вы отменили мои правки на странице округления в Википедии. Я не уверен, что вы имеете в виду под «корректность требует анализа условий переполнения» в этом контексте. Помощь была бы оценена по достоинству.

Спасибо!

Elyisgreat ( обсуждение ) 02:10, 15 января 2017 (UTC) [ ответить ]

Вы сказали, что формула, очевидно, верна. Но некоторые очень похожие на вид формулы, например, для целого числа, находящегося посередине между двумя другими целыми числами x и y, могут иметь числовые проблемы (например, переполнения), если записаны очевидным образом, например (x+y)/2, и их может быть предпочтительнее записать неочевидным образом, например x+(yx)/2 или даже ((x^y)>>1)+(x&y). Поэтому было бы полезно иметь источник для лучшего выбора формулы для использования в этом режиме округления, от того, кто, как можно доверять, думал об этих проблемах и либо справился с ними должным образом, либо пришел к выводу, что нет причин не делать это очевидным способом. — Дэвид Эппштейн ( обсуждение ) 03:13, 15 января 2017 (UTC) [ ответить ]

Спасибо за это. Я посмотрю, что смогу найти. По-видимому, еще одна проблема — неоднозначность операции по модулю при работе с отрицательными значениями; я предположил определение, которое принимает знак делителя, однако это было, по-видимому, непонятно некоторым пользователям. Теперь я знаю, что нет ничего математически проблемного в формулах, которые я опубликовал, однако я не уверен, могут ли они вызвать переполнение в различных программных реализациях. Хотя мне любопытно: не возникнут ли какие-либо проблемы с переполнением, вызванные формулой округления до четного, также в формуле округления на половину вверх? —Elyisgreat ( talk ) 06:17, 15 января 2017 (UTC) [ reply ]

Неясность модуля по отношению к отрицательным числам заключается в том, что многие основные языки программирования (C, C++, Java и т. д.) ошибаются и возвращают отрицательные результаты для отрицательного делимого. На самом деле, это из-за округления! Они выбирают значение модуля так, что (x / y) * y + x % y == x, всегда, но затем они выбирают режим округления для деления, который несовместим с тем, что модуль всегда положительный. Так что это еще одна опасность простого предоставления формулы без источников или разъяснений: люди будут использовать формулу, думая, что они могут просто записать ее таким образом в программе, и она вернет неправильный ответ. — Дэвид Эппштейн ( обсуждение ) 06:31, 15 января 2017 (UTC) [ ответить ]

Помимо того, что формула не совсем очевидна, что является обязательным условием, если источник не указан (см. WP:CALC) , проблема с mod, о которой говорит Дэвид Эппштейн, делает ее совершенно непригодной для использования в контексте. Подробнее об этом см. в разделе Оператор Modulo . Я думаю, что другие формулы хороши, поскольку являются простыми транскрипциями английского языка в математику, хотя я думаю, что «отрицательную» версию можно было бы удалить без потерь. На самом деле в последней формуле я вообще не знаю, к чему должен относиться mod, поэтому я даже не знаю, что он означает. Dmcq ( обсуждение ) 13:32, 15 января 2017 (UTC) [ ответ ]

Исходную формулу можно записать без функции mod, если она вызывает неоднозначность. Ее можно записать так:

${\displaystyle q={\begin{cases}y-0.5,&{\mbox{if }}y-2\left\lfloor y/2\right\rfloor =0.5\\\left\lfloor y+0.5\right\rfloor ,&{\mbox{if }}y-2\left\lfloor y/2\right\rfloor \not =0.5\end{cases}}}$

или:

${\displaystyle q={\begin{cases}y-0.5,&{\mbox{if }}y-\left\lfloor y\right\rfloor =0.5{\mbox{ and}}\left\lfloor y\right\rfloor {\mbox{is even }}\\y+0.5,&{\mbox{if }}y-\left\lfloor y\right\rfloor =0.5{\mbox{ and}}\left\lfloor y\right\rfloor {\mbox{is odd }}\\\left\lfloor y+0.5\right\rfloor ,&{\mbox{if }}y-\left\lfloor y\right\rfloor \not =0.5\end{cases}}}$

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

—Elyisgreat ( обсуждение ) 19:49, 15 января 2017 (UTC) [ ответить ]

Попытка выяснить, какая из нескольких похожих формул является правильной для включения, определенно вторгается на территорию WP:OR , по моему мнению. Пожалуйста, просто найдите источник. — Дэвид Эппштейн ( обсуждение ) 20:22, 15 января 2017 (UTC) [ ответить ]

Согласен, это похоже на WP:OR . Формулы, которые не являются прямой формализацией определения и которые никогда не используются на практике, следует отвергать. Vincent Lefèvre ( talk ) 22:31, 15 января 2017 (UTC) [ ответить ]

Следующая (оригинальная исследовательская) формула реализует truncate(y) без сингулярности при y=0. Требует функций abs и floor:

${\displaystyle \mathrm {truncate} (y)=\left\lfloor y\right\rfloor +{\frac {1-{\frac {\left|\left\lfloor y\right\rfloor +{\frac {1}{2}}\right|}{\left\lfloor y\right\rfloor +{\frac {1}{2}}}}}{2}}=\left\lfloor y\right\rfloor -{\frac {\left|\left\lfloor y\right\rfloor +{\frac {1}{2}}\right|}{2\left\lfloor y\right\rfloor +1}}+{\frac {1}{2}}}$

70.190.166.108 (обсуждение) 17:39, 15 января 2017 (UTC) [ ответить ]

Я провел некоторую очистку стиля и разметки по всей статье, особенно семантически различая различные варианты использования того, что визуально отображается курсивом, с помощью (оболочки шаблона для ) и ( ) там, где это уместно, и время от времени удаляя некоторые бессмысленные, пугающие акценты. Можно было бы сделать больше. Например, кажется ненужным и раздражающим для читателя продолжать выделять курсивом каждое упоминание алгоритма/подхода округления после первого случая (который уже выделен жирным шрифтом), и за исключением случаев, когда мы говорим о них как о словах-как-словах (как в "Термин банковское округление ..."). Также провел некоторые другие очистки, связанные с MOS:NUM , такие как использование неразрывных пробелов в " y  ×  q  = ...", а не " y × q =...", или использование обычных пробелов, переносимых на строку. Возможно, я пропустил пару случаев, но я сделал это во внешнем текстовом редакторе и был довольно тщательным.{{var}}<var>...</var>{{em}}<em>...</em>

Однако я ничего не трогал в <math>...</math>разметке ; я не уверен, поддерживают ли они (или сырой HTML ). Я отмечу, что представление переменных внутри блоков кода математической разметки крайне непоследовательно и должно быть нормализовано до разметки var (если возможно) или, по крайней мере, до несемантического курсива, для последовательности и во избежание путаницы читателя.  —  SMcCandlish ☺ ☏ ¢  ≽ ^ʌ ⱷ҅ _ᴥ ⱷ ^ʌ ≼  02:21, 11 сентября 2017 (UTC) [ ответить ]{{math}}{{var}}<var>...</var>

Раздел « Округление половин до нечетных» в настоящее время содержит:

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

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

Эта система используется редко, поскольку она никогда не округляет до нуля, хотя «округление до нуля часто является желательным атрибутом для алгоритмов округления».

Опять же, это правило ничьей касается только чисел, находящихся на полпути, так что утверждение «оно никогда не округляется до нуля» неверно. Более того, это предложение также подразумевает, что «округлять половину от нуля» и «округлять от нуля» также будут использоваться редко, что неверно. Винсент Лефевр ( обсуждение ) 14:47, 11 сентября 2017 (UTC) [ ответить ]

@Vincent Lefèvre: Я полагаю, что «никогда не до нуля» означает, что применимый случай округления (половина числа) не будет округляться до нуля. Однако желательно ли это или нет, зависит от контекста. Например, в фиксированной точке округление к нечетному приведет только к одному изменению бита, тогда как округление к четному может вызвать полное сложение. Paamand (обс.) 09:04, 21 сентября 2017 (UTC) [ ответить ]

Да, это может быть (немного?) быстрее только в некоторых конкретных случаях (на полпути), но при использовании выделенного оборудования, и такие случаи могут нуждаться в обнаружении, что означает, что это также может замедлить работу. Так что это не очевидно. Более того, я сомневаюсь, что это используется на практике. В любом случае, это кажется WP:OR , если у вас нет какой-либо ссылки, показывающей существующее использование. Vincent Lefèvre ( talk ) 10:05, 21 сентября 2017 (UTC) [ ответить ]

В цитируемом Руководстве по НДС говорится:

Примечание: уступка в этом пункте по округлению сумм НДС в меньшую сторону предназначена для торговцев счетами-фактурами и применяется только в том случае, если НДС, взимаемый с клиентов, и НДС, уплачиваемый таможне и акцизам, одинаковы. Как правило, уступка по округлению в меньшую сторону не подходит для розничных торговцев, которым следует ознакомиться с пунктом 17.6.

и в пункте 17.6 говорится, что округление только в меньшую сторону не допускается. Так что я не думаю, что это "достаточно ясно" указано. --81.178.31.210 17:27, 2 сентября 2006 (UTC) [ ответить ]

Может ли кто-нибудь ответить на этот вопрос? В статье есть место для таких примеров. -- Хорхе Столфи ( обсуждение ) 05:52, 1 августа 2009 (UTC) [ ответить ]

Независимо от предыдущего вопроса, НДС по статьям в счете-фактуре является примером необходимости округления каждой статьи таким образом, чтобы сумма округленных статей равнялась округленной сумме статей. Частным решением только для положительных статей является метод Largest_remainder_method , более общим — Curve_fitting . Возможно, кто-то, кто читает по-немецки, может включить (и расширить?) в материал статьи из https://de.wikipedia.org/wiki/Rundung#Summenerhaltendes_Runden. -- Wegner8 07:04, 18 сентября 2017 (UTC)

Сделанный. Wegner8 11:51, 7 октября 2017 г. (UTC) — Предыдущий неподписанный комментарий добавлен пользователем Wegner8 ( обсуждение • вклад )

Я не уверен, заслуживает ли это освещения в этой статье, но на этой странице блога ^[1] описывается «аргентинское» и «швейцарское» округление.

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

"Швейцарское округление" (если я правильно понимаю) - это округление до четвертей. Например, округление до 0,0, 0,25, 0,5, 0,75 и 1,0 в качестве округленных результатов.

-- Джефф Григг 68.15.44.5 (обсуждение) 00:32, 20 октября 2017 (UTC) [ ответить ]

Это означало бы, что «Аргентинское округление» соответствует округлению с фиксированной точкой по основанию 2 с одной дробной цифрой, но это не правильное округление, и что «Швейцарское округление» соответствует округлению с фиксированной точкой по основанию 2 с двумя дробными цифрами. Так что это не совсем новые округления. Винсент Лефевр ( обсуждение ) 00:39, 21 октября 2017 (UTC) [ ответить ]

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

Гупта, Суйог; Анграул, Анкур; Гопалакришнан, Кайлас; Нарайанан, Притиш (9 февраля 2016 г.). «Глубокое обучение с ограниченной числовой точностью». АрXiv. п. 3.

где вероятность округления до пропорциональна близости к :${\displaystyle x}$${\displaystyle \lfloor x\rfloor }$${\displaystyle x}$${\displaystyle \lfloor x\rfloor }$

${\displaystyle \operatorname {Round} (x)={\begin{cases}\lfloor x\rfloor &{\text{ with probability }}1-(x-\lfloor x\rfloor )\\\lfloor x\rfloor +1&{\text{ with probability }}{x-\lfloor x\rfloor }\end{cases}}}$

Округление в Монте-Карло округление случайно, вышеприведенное можно рассматривать как одну из форм округления Монте-Карло, но можно использовать и другие, и их можно использовать с несколькими запусками для проверки стабильности результата. Стохастическое округление выше имеет свойство, что сложение является несмещенным. Многое об арифметике Moonte Carlo на сайте Monte Carlo Arithmetic. Dmcq ( talk ) 16:17, 21 октября 2017 (UTC) [ ответить ]

По моему мнению, было бы неплохо добавить начальный раздел, в котором говорилось бы что-нибудь об аксиомах операций округления, возможно, начав с «что такое округление» в самом общем смысле, а затем добавив несколько более специализированных аксиом для различных используемых типов округления. Однако мне пока не ясно, насколько такая «аксиоматическая теория округления» уже разработана в исследовательском сообществе. Так что, возможно, еще слишком рано обсуждать ее здесь в контексте статьи WP. Я проверю некоторые известные мне ресурсы, которые существуют по такой аксиоматизации, и размещу ее здесь для дальнейшего обсуждения. Любые другие комментарии приветствуются, спасибо! Axiom0 ( talk ) 14:37, 7 марта 2018 (UTC) [ reply ]

Поиск источников — это отличное место для начала. См. WP:V и WP:RS . -- Гай Мейкон ( обсуждение ) 14:53, 7 марта 2018 (UTC) [ ответить ]

Предлагаю взглянуть на то, что было сделано для доказателей теорем, таких как Coq . Например: Daumas, Marc; Rideau, Laurence; Théry, Laurent (2001). "A Generic Library for Floating-Point Numbers and Its Application to Exact Computing" . Получено 7 марта 2018 г. {{cite journal}}: Cite journal required |journal=( помощь ) Но учтите, что это уже более конкретно (только с плавающей точкой), чем то, что рассматривается в статье WP. Винсент Лефевр ( обсуждение ) 16:00, 7 марта 2018 (UTC) [ ответ ]

Вот список источников определений округления, которые я нашел на данный момент (в хронологическом порядке, «список в разработке»):

U. Kulisch. Математические основы компьютерной арифметики. IEEE Transactions on Computers, C-26(7):610–621, июль 1977 г. (стр. 610 и след.)

Р. Мэнсфилд. Полная аксиоматизация компьютерной арифметики. Математика вычислений, 42(166):623–635, 1984. (стр.624)

Г. Хеммерлин и К. Хоффманн. Нумерическая математика. Springer, 4-е издание, 1994 г. (стр. 14; только очень конкретно (FP))

Я добавлю больше позже, и, возможно, смогу найти более ранние источники. Однако, насколько мне известно, ни Тьюринг (1948), ни Уилкинсон (1963) в своих публикациях формально не определяли операцию округления. Но я могу ошибаться. Axiom0 ( talk ) 22:19, 8 марта 2018 (UTC) [ ответить ]

После некоторых дополнительных исследований я пришел к выводу, что, к сожалению, действительно слишком рано включать такой начальный раздел в статью WP. Поскольку общепринятая «аксиоматическая теория округления» еще не разработана. И как указал Винсент Лефевр на своей странице обсуждения, нам не следует пытаться изобрести ее здесь. Так что я извиняюсь за то, что зашел слишком далеко. Мне просто понравилась эта идея :-) Axiom0 ( обсуждение ) 11:31, 21 марта 2018 (UTC) [ ответить ]

В тексте в настоящее время говорится, что правило округления до половины «приведет к смещению в сторону нуля, когда y − 0,5 является четным» .

Я предполагаю, что это означает, что с таким набором, как 2.5, 2.5, 4.5, 10.5, результатом округления будет 2, 2, 4, 10, что имеет смещение в сторону нуля. Но −1.5, −1.5, −11.5, −7.5 также имеют форму "y − 0.5 четно", и они округляются до −2, −2, −12, −8. Так что на самом деле это должно выглядеть так:

«правило введет смещение в сторону отрицательной бесконечности, когда y − 0,5 четное» .

Итак, я это исправил. Boud ( обсуждение ) 16:41, 24 апреля 2018 (UTC) [ ответить ]

Лично я считаю, что этот фрагмент следует просто удалить. Я никогда не видел ни одного документа, описывающего его, так что он, вероятно, недостаточно важен, чтобы его включать, и, по сути, весьма вероятно, нарушает WP:OP — что объясняет, почему человек, написавший его, ошибся. Dmcq ( обсуждение ) 21:24, 24 апреля 2018 (UTC) [ ответ ]

Я также считаю, что это следует удалить. Vincent Lefèvre ( обсуждение ) 21:45, 24 апреля 2018 (UTC) [ ответить ]

Я думаю, что это на самом деле округление на половину от нуля, которое широко используется во многих дисциплинах. StephenJohns00 (обсуждение) 04:56, 13 августа 2018 (UTC) [ ответить ]

Я тоже так думаю, и, вероятно, именно поэтому он был включен в IEEE 754-2008. Винсент Лефевр ( обсуждение ) 07:13, 13 августа 2018 (UTC) [ ответить ]

Да, это не до положительной бесконечности, это округление до ближайшего и это для десятичных вычислений. Некоторые финансовые учреждения хотят этого - и я думаю, у них есть деньги ;-) Dmcq ( talk ) 15:25, 13 августа 2018 (UTC) [ ответить ]

• Метод наибольшего остатка — это, безусловно, метод округления. Он практически используется в некоторых демократиях для распределения мест. Поэтому он должен появиться в этой статье.
• Это определенно можно сделать с помощью элементарной арифметики. Поэтому не требуется никаких исследований и никаких источников. (Должно быть возможно предотвратить повторный вызов этого соответствующего бота.)
• Дэвид Эппштейн , Dmcq : После того, как вы дважды удалили соответствующий раздел, вставьте, пожалуйста, формулировку, которая вам нравится.

Вот мой предложенный текст, упрощенный еще раз. Wegner8 08:06, 28 октября 2018 (UTC)

=== Округление слагаемых с сохранением итога: Округление НДС ===

Округление с сохранением итога означает округление каждого слагаемого таким образом, что сумма округленных чисел равна их округленной сумме. [[Метод наибольшего остатка]] является особым случаем только с положительными слагаемыми.

Помимо прочего, эта процедура применяется (а) для [[пропорционального представительства]] в законодательном органе с фиксированным числом членов и (б) если в счете-фактуре общая сумма [[НДС]] должна быть распределена по статьям с сохранением правильности суммирования в каждом столбце.

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

На каком основании вы пришли к выводу, что « Метод наибольшего остатка — это определенно[sic] метод округления»? Он — и все другие методы пропорционального представительства по партийным спискам — по-видимому, имеют лишь поверхностное сходство с округлением. — Гай Мейкон ( обсуждение ) 09:37, 28 октября 2018 (UTC) [ ответить ]

Частные (обычно нецелые простые дроби) даны, целые числа поблизости должны быть определены. Это особый случай округления. -- Wegner8 10:47, 28 октября 2018 (UTC)

Вы занимаетесь WP:Original исследованием , если у вас нет надежного источника, который говорит, что это метод округления. Эта политика является базовой для Википедии. См. WP:5P2 «Личный опыт, интерпретации или мнения редакторов не принадлежат». Лучшее, что можно сделать, это также посмотреть Пропорциональность , но различные темы пропорционального деления или пропорционального представительства или тому подобного просто не считаются округлением в источниках и поэтому не должны рассматриваться как округление здесь. Dmcq ( обсуждение ) 11:34, 28 октября 2018 (UTC) [ ответ ]

Можете ли вы, вместо того, чтобы просто удалять потенциально полезный материал, помочь найти для него правильное место и формулировку? Где человек с проблемой НДС будет искать решение? -- Спасибо за подсказку к статье Партийно-списочное пропорциональное представительство; эта ссылка должна заменить ссылку на Метод наибольшего остатка в предложенном выше тексте. -- Wegner8 06:49, 29 октября 2018 (UTC)

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

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

Означает ли тот факт, что это потенциально полезно, что мы должны добавить приведенное выше утверждение в нашу статью Rounding ? Нет. Это чрезвычайно полезная информация для тех, кому нужны очень высокие напряжения, но кому здесь не место.

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

У нас есть место, где вы можете спросить, где находится нужное место, и волонтеры готовы помочь вам. Смотрите WP:Helpdesk . Обратите внимание, что как только вы выясните, где находится нужное место, вам нужно следовать WP:V и указать источник для ваших утверждений. При добавлении информации, пожалуйста, WP:CITE источник для каждого утверждения.

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

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

Вот еще несколько страниц, которые могут быть вам полезны:

• Введение
• Пять столпов Википедии
• Вклад в Википедию
• Как редактировать страницу
• Страницы помощи
• Как написать отличную статью
• Узнайте, что происходит в сообществе Wikimedia

Кроме того, когда вы публикуете сообщения на страницах обсуждений, вы должны подписывать свое имя , используя четыре тильды (~~~~); это автоматически добавит ваше имя пользователя и дату с правильно отформатированными ссылками. -- Гай Мейкон ( обсуждение ) 07:44, 29 октября 2018 (UTC) [ ответить ]

Ну, я думаю, что цитата в конце каждого предложения — это немного перебор, когда источник может охватывать целый абзац, но да, в принципе то, что входит в статью, должно быть резюме того, что говорится в одном или нескольких источниках. Dmcq ( обсуждение ) 12:11, 29 октября 2018 (UTC) [ ответ ]

ps с трансформатором можно было бы добавить больше обмоток для более высокого напряжения, ни одна обмотка не должна выдерживать более высокое напряжение. — Предыдущий неподписанный комментарий добавлен Dmcq ( обсуждение • вклад ) 12:15, 29 октября 2018 (UTC)[ отвечать ]

Кто сказал что-нибудь о цитате в конце каждого предложения? Добавление Wegner8 вообще не содержало цитат.

В высоковольтном трансформаторе путь пробоя обычно проходит по схеме обмотка с самым низким напряжением --> сердечник --> обмотка с самым высоким напряжением. Для трансформаторов с воздушным сердечником крайне сложно развести два конца вторичной обмотки достаточно далеко друг от друга, чтобы выдержать напряжение, способное образовать дугу более 20 футов, -- с чем легко справляются мультипликаторы Кокрофта-Уолтона. -- Гай Мейкон ( обсуждение ) 17:10, 29 октября 2018 (UTC) [ ответить ]

«При добавлении информации, пожалуйста, WP:CITE указывайте источник для каждого утверждения» можно понимать как требование указать источник в конце каждого утверждения.

Ферриты не проводят ток ;-) Я просто хочу сказать, что надежный источник очень хорош, даже если человек считает, что это «полезная информация», иначе могут возникнуть проблемы. Dmcq ( обсуждение ) 17:31, 29 октября 2018 (UTC) [ ответить ]

Ферриты не проводят при низких напряжениях . Воздух тоже. Оба имеют диэлектрическое выдерживаемое напряжение (обычно называемое «напряжением пробоя»). Попробуйте получить вид напряжения, который обычно встречается в больших умножителях Кокрофта-Уолтона, из трансформатора с ферритовым сердечником, и он пробьет дугу прямо через феррит. Действительно верно, что ни одна часть умножителя Кокрофта-Уолтона не видит полного выходного напряжения, и действительно верно, что некоторые части трансформатора видят полное выходное напряжение. -- Гай Мейкон ( обс .) 18:55, 29 октября 2018 (UTC) [ ответить ]

Статья начинается так: «Округление числа означает замену его другим числом, которое приблизительно равно исходному...». Разве это не то же самое, что делает округление НДС? Все говорят о фейковых новостях; отрицание фактов — это близнец фейковых новостей. Пожалуйста, восстановите абзац об округлении НДС. -- Wegner8 08:19, 10 января 2019 (UTC) — Предыдущий неподписанный комментарий добавлен Wegner8 ( обсуждение • вклад )

Нет, это не просто округление числа. Это может быть его собственная статья. Тогда я полагаю, что ссылка в разделе «См. также» будет в порядке. Винсент Лефевр ( обсуждение ) 11:10, 10 января 2019 (UTC) [ ответить ]

В любом случае, у вас уже есть источник для округления НДС? Если да, вы могли бы начать статью, например, о округлении НДС по всему миру. Каждая система будет применять округление, и эта статья могла бы также иметь ссылку на него как на интересное использование. Dmcq ( talk ) 13:58, 10 января 2019 (UTC) [ ответить ]

На Talk:Nearest integer function есть предложение объединить эту статью с этой; см. Talk:Nearest_integer_function#Merge_into_Rounding . -- JBL ( talk ) 22:16, 18 апреля 2019 (UTC) [ ответить ]

В разделе истории есть краткий отрывок о накоплении возраста в конце, что является своего рода округлением, которое люди делают, и, похоже, больше касается психологической вещи и способа исправления статистики, чем округления, как описано в остальной части статьи. Уместно ли это ралли в этой статье? Dmcq ( обсуждение ) 11:44, 24 сентября 2019 (UTC) [ ответить ]

Никаких упоминаний о точном округлении и о том, почему это хорошая идея. Я думаю, это означает, что логика может быть меньше, и, как правило, округление/переполнение/недополнение происходит быстрее, но я пришел сюда за дополнительной информацией и ничего не нашел. — Предыдущий неподписанный комментарий добавлен ChippendaleMupp (обсуждение • вклад ) 15:50, 13 февраля 2020 (UTC) [ ответить ]

Приношу свои извинения , доктор Лефевр . Честно говоря, я думал, что исправляю опечатку.

Этот пример показался мне интересным, но когда я попытался решить его, подставив вместо него другие значения , он, похоже, не совпал.${\displaystyle n}$

Вот оригинальный текст до моей правки:

Например, если гипотеза Гольдбаха верна, но недоказуема , то результат округления следующего значения до следующего целого числа не может быть определен: 1+10 ^{− n} , где n — первое четное число, большее 4, которое не является суммой двух простых чисел, или 1, если такого числа нет. Округленный результат равен 2, если такое число n существует, и 1 в противном случае.

Давайте сначала рассмотрим случай, когда число не существует, поэтому подставим его в формулу:${\displaystyle n=1}$

$${\displaystyle 1+10^{-n}=1+10^{-1}=1+{\frac {1}{10^{1}}}=1+{\frac {1}{10}}=1.1}$$

Теперь давайте рассмотрим другой случай, когда существует четное число больше 4, которое не является суммой двух простых чисел. Это число, по-видимому, будет очень большим, но давайте начнем с :${\displaystyle n=4}$

$${\displaystyle 1+10^{-n}=1+10^{-4}=1+{\frac {1}{10^{4}}}=1+{\frac {1}{10000}}=1.0001}$$

Очевидно, чем больше , тем ближе полученное значение будет к 1. Для очень большого мы получим 1,000...0001 с очень большим количеством нулей между ними.${\displaystyle n}$${\displaystyle n}$

Итак, значения, которые мы получаем в обоих случаях примера, 1,1 и 1,000...0001, будут округлены до одного и того же числа, независимо от того, какой режим округления мы используем. Так как же нам заставить эту формулу округляться до 1 или 2, в зависимости от доказуемости гипотезы Гольдбаха?

Единственный способ, который я могу придумать для получения разных округленных значений, — это использовать его в случае, когда такого числа не существует, что приведет к округлению приведенной выше формулы до 2 в этом случае и до 1 в другом случае (при округлении до ближайшего целого числа).${\displaystyle n=0}$

Очевидно, я что-то здесь не так понял, но не могу понять, что именно. Я был бы очень признателен, если бы кто-нибудь мог объяснить этот пример.

Grnch ( обсуждение ) 21:51, 27 марта 2021 (UTC) [ ответить ]

@Grnch: Если предположение ложно, то результатом будет 1+10 ^{− n} для некоторого значения n , что округлит его до 2. Если предположение верно, то результатом будет 1 (см. «1, если такого числа нет» выше), что округлит его до 1 (поскольку 1 — целое число, округление не меняет его значения). — Винсент Лефевр ( обсуждение ) 02:46, 28 марта 2021 (UTC) [ ответить ]

Я потратил гораздо больше времени, пытаясь понять этот ответ, чем мне хотелось бы признать, пока до меня наконец не дошло: моя проблема не математическая, а грамматическая.

В этом предложении:

1+10 ^{− n} , где n — первое четное число, большее 4, которое не является суммой двух простых чисел, или 1, если такого числа нет

Я взял "1, если такого числа нет" для применения к выражению "где n есть", т. е. что n должно принимать значение 1, когда такого числа не существует. Теперь я понимаю, что на самом деле все выражение принимает значение 1, когда такого числа не существует.

Чтобы попытаться выразить это более точно, я интерпретирую пример как округление значения , где определяется как:${\displaystyle x}$${\displaystyle x}$

$${\displaystyle x=1+10^{-n},{\text{where }}n={\begin{cases}{\text{the first even number greater than 4 which is not a sum of two primes}}\\1,{\text{ if no such number exists}}\end{cases}}}$$

Но на самом деле правильная интерпретация — округлить значение , где определяется как:${\displaystyle x}$${\displaystyle x}$

$${\displaystyle x={\begin{cases}1+10^{-n},&{\text{where }}n{\text{ is the first even number greater than 4 which is not a sum of two primes}}\\1,&{\text{if no such number exists}}\end{cases}}}$$

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

Может быть, добавление приведенной выше математической нотации (второй) поможет устранить возможную двусмысленность из примера?

Grnch ( обсуждение ) 01:07, 31 марта 2021 (UTC) [ ответить ]

@Grnch: Да, это следует прояснить, но не с <math display="block">тем, что все в нем отображается как изображение, что плохо для доступности или если кто-то хочет скопировать-вставить. Я не знаю, есть ли wikicode для решения этой проблемы. В качестве альтернативы, добавление «либо» перед «1+10 ^{− n} » сделало бы предложение однозначным, IMHO. — Vincent Lefèvre ( talk ) 11:01, 31 марта 2021 (UTC) [ ответить ]

О, это было бы идеально! Да, это стратегическое добавление «либо» создало бы симметрию «либо/либо», которая должна сделать смысл всего предложения более очевидным, по крайней мере, для меня. Спасибо! — Grnch ( talk ) 17:44, 3 апреля 2021 (UTC) [ ответить ]

@Grnch: Выполнено в Special:Diff/1015824758 . — Винсент Лефевр ( обсуждение ) 19:46, 3 апреля 2021 (UTC) [ ответить ]

Я не нашел описания округления до ближайшего целого значения, кратного 1/2, т. е. до значений 0, 0,5, 1, 1,5 и т. д. -- Fkbreitl ( обсуждение ) 12:00, 8 мая 2021 (UTC) [ ответ ]

Не требуется (как округление до некоторого количества дробных цифр): это как точное умножение на 2, округление до целого числа и деление на 2. Статья не может охватить все возможные случаи округления. — Венсан Лефевр ( обсуждение ) 16:43, 8 мая 2021 (UTC) [ ответить ]

Я подумал, что было бы полезно включить формулу для округления числа вверх и вниз до ближайшего кратного другого положительного числа, поскольку уже есть раздел для округления до определенного кратного (https://en.wikipedia.org/wiki/Rounding#Rounding_to_a_specified_multiple), а также раздел для округления вверх и вниз до ближайшего целого числа (https://en.wikipedia.org/wiki/Rounding#Rounding_down и https://en.wikipedia.org/wiki/Rounding#Rounding_up). Формулы будут такими:

${\displaystyle \mathrm {roundUpToMultiple} (x,m)=\lceil x/m\rceil \times m}$

${\displaystyle \mathrm {roundDownToMultiple} (x,m)=\lfloor x/m\rfloor \times m}$

Итак, я добавил их в статью, но пользователь Vincent Lefèvre удалил их. Он сказал, что «Это частный случай того, что описано в этом разделе (который не ограничивается округлением до ближайшего)». Хотя это правда, я не вижу, почему это проблема или причина для их удаления. Я имею в виду, что округление вверх или вниз (с использованием функций потолка и пола) является частным случаем округления, так почему бы нам также не удалить разделы «Округление вниз» и «Округление вверх»? -- Alej27 ( talk ) 19:24, 3 марта 2022 (UTC) [ ответить ]

Дело в том, что в этом разделе Округление до указанного кратного дана общая формула, где вы можете выбрать любую функцию округления до целого числа для «округления». Например, с помощью из подраздела Округление вниз вы сразу получите свою вторую формулу. Бесполезно повторять все, что было сказано в разделе Округление до целого числа . — Винсент Лефевр ( обсуждение ) 20:25, 3 марта 2022 (UTC) [ ответить ]${\displaystyle \mathrm {roundToMultiple} (x,m)=\mathrm {round} (x/m)\times m}$${\displaystyle \mathrm {round} (x)=\mathrm {floor} (x)=\left\lfloor x\right\rfloor }$

Привет @ Boh39083 , я заметил, что вы ввязались в небольшую войну откатов по поводу ваших последних изменений. Может быть, вы хотите немного обсудить здесь свое обоснование? (ср. "жирный–откат–обсуждение" .) Попытка привести аргументы в сводках правок не является наиболее эффективной, по моему опыту. – jacobolus  (t) 16:04, 19 ноября 2023 (UTC) [ ответить ]

В JS я протестировал простое преобразование 1/3 в процент (число JS — это число с плавающей точкой двойной точности), и если вы сначала разделите (округлите) его перед умножением, то получите большее расхождение, чем если бы вы сначала умножили, а затем разделили (поскольку деление может привести к получению непредставимого значения, поэтому необходимо выполнить округление):

(1/3*100).toFixed(16)'33.3333333333333 286' (1*100/3).toFixed(16)'33.33333333333333 57'

Это потому, что первый сделал 1/3, что не может быть точно представлено в формате с плавающей точкой двойной точности, поэтому это число округляется, а затем умножается на 100, что увеличивает эту ошибку. Последний сделал 1*100, что может быть точно представлено, затем делится на 3, что затем округляется, на последнем этапе. Joeleoj123 ( talk ) 02:04, 18 декабря 2023 (UTC) [ ответить ]

Это рассматривается в связанной статье об ошибке округления . MrOllie ( обсуждение ) 02:08, 18 декабря 2023 (UTC) [ ответить ]