Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
ВикиПроект по математике (Номинальный шаблон-класс)
Значок WikiProjectЭтот модуль входит в состав WikiProject Mathematics , совместной работы по расширению охвата математики в Википедии. Если вы хотите принять участие, посетите страницу проекта, где вы можете присоединиться к обсуждению и увидеть список открытых задач.
 Шаблон Этот модуль не требует оценки по шкале качества проекта .
 

Этот модуль реализует набор связанных математических операций и задач форматирования чисел.

См. Также [ править ]

средний [ править ]

Было бы полезно добавить среднюю функцию:

- [[средний  Находит среднее Использование: {{#invoke: Math | средний | значение1 | значение2 | ...}}ИЛИ ЖЕ {{#invoke: Math | средний }} При использовании без аргументов он принимает входные данные от родителяРамка. Обратите внимание: любые значения, которые не оцениваются как числа, игнорируются.]]функция z.average (кадр) локальные аргументы = frame.args; если args [1] == nil, то локальный родитель = кадр: getParent (); args = parent.args; конец местная сумма = 0; локальный счетчик = 0;  местный i = 1; а args [i] ~ = nil делать локальный val = z._cleanNumber (кадр, args [i]); если val ~ = nil, то сумма = сумма + значение count = count + 1 конец  я = я + 1; конец  return (count == 0 и 0 или сумма / счет)конец

- DixonD ( разговор ) 23:17, 23 марта 2013 г. (UTC)

Я добавил его. Полет драконов ( разговор ) 14:37, 18 апреля 2013 (UTC)

случайный [ править ]

Случайный вызов, вызываемый только с одним аргументом, возвращает ошибку сценария. Я попытался исправить это в своей песочнице, включая аргумент seed. - Вриуллоп ( разговор ) 12:37, 31 марта 2013 г. (UTC)

Какие параметры вызывать для случайного числа? Я предполагаю {{#invoke: Math | random | count | seed}}, но, похоже, он не дает мне случайного числа. Технический 13 ( разговор ) 15:59, 3 июля 2013 (UTC)

: Какие параметры были протестированы? W T 101 ( Chat • Count ) 18:23, 6 июля 2013 г. (UTC)

GCD [ править ]

Функция GCD была бы хорошей заменой для {{ gcd }}, которая на данный момент довольно ограничена. Для vi: Mô đun: Math я перенес псевдокод с расширенным евклидовым алгоритмом # Псевдокод на Lua, учитывая крайний случай, упомянутый в этом разделе:

- [= [ gcd] Вычисляет [[наибольший общий делитель]] в соответствии с [[расширенным алгоритмом Евклида]]. ] =] функция z . gcd ( frame ) local args = frame . аргументы        если  args [ 1 ]  ==  nil,  тогда  local  parent  =  frame : getParent ()  args  =  parent . конец аргументов   местный  a  =  z . _cleanNumber ( кадр ,  аргументы [ 1 ])  локальный  b  =  z . _cleanNumber ( рама ,  арг [ 2 ]) ,  если  не  или не б затем возвращать конец        local  s  =  0  local  olds  =  1  local  t  =  1  local  oldt  =  0  local  r  =  b  local  oldr  =  a  while  r  ~ =  0  do  local  quotient  =  math.floor ( oldr  /  r )  oldr ,  r  =  r ,  oldr  -  частное  *  r  olds ,  s  =  s , olds  -  частное  *  s  oldt ,  t  =  t ,  oldt  -  частное  *  t  end  mw . log ( "Коэффициенты Безу:" ,  olds ,  oldt )  mw . log ( "Наибольший общий делитель:" ,  oldr )  mw . log ( "Коэффициенты по НОД:" ,  t ,  s )  если  a  ==  0  и  b  <  0  или  b  ==  0  и  a  <  0,  то  oldr  =  oldr  *  - 1  конец  вернуть  старый конец

Я не особо разбираюсь в этой области, но я протестировал функцию на нескольких примерах входных данных, например, в Template: Gcd , и, похоже, дал правильные результаты. Если кто знает, как лучше написать эту функцию, я все уши.

 -  Минь Нгуён ( обсуждение , вклад ) 23:00, 26 ноября 2013 г. (UTC)

Спасибо за предложенный код. :) Я заметил пару вещей - во-первых, если вас интересует только наибольший общий знаменатель, то вы можете избавиться от s, old, t и oldt, поскольку они не используются при его вычислении. Во- вторых, если вы используете {{#invoke|math|gcd|-8|0}}вы получите ответ 8. Это кажется нелогичным для меня, но тогда я не совсем уверен , что условности здесь.

В дополнение к этому обновлению, я думаю, что модулю требуется немного TLC, чтобы он работал нормально, когда он вызывается из других шаблонов и других модулей Lua. Я начал работать над песочницей, но затем я потерял все свои изменения из-за ошибки в Vim, связанной с японскими методами ввода. Ба. :( Думаю, завтра попробую еще раз. Учитывая, что в этом модуле более миллиона включений, нам, вероятно, стоит потратить время на его тестирование, чтобы убедиться, что он работает, поэтому я пометил этот запрос как ответ на данный момент. - Г-н Страдивари ♪ доклад ♪ 13:24, 2 декабря 2013 г. (UTC)

Тестовые наборы [ править ]

Я добавил Module: Math / testcases и Module_talk: Math / testcases, и в текущей версии Module: Math есть некоторые ошибки . Скопируйте исправленную версию с сайта Commons: Module: Math . - Ярект ( разговор ) 18:38, 3 декабря 2013 г. (UTC)

Может быть, мистер Страдивари сможет рассмотреть этот запрос? - Мартин ( MSGJ  ·  talk ) 12:59, 4 декабря 2013 г. (UTC)
Конечно, посмотрю завтра. Вероятно, это следует сделать одновременно с указанным выше запросом, и я бы предпочел, чтобы мои улучшения также были внесены, поэтому на создание кода уйдет час или два. - Г-н Страдивари ♪ выступление ♪ 14:26, 4 декабря 2013 г. (UTC)
Обновление: код в песочнице должен быть выполнен, и он проходит все модульные тесты. Однако я еще не обновил его, так как я изменил довольно много вещей и хочу написать больше модульных тестов, чтобы убедиться, что все работает правильно, а не только старые вещи, которые были сделаны с помощью #invoke. - Г-н Страдивари, выступление, 14:04, 8 декабря 2013 г. (UTC)
Еще одно обновление: я сделал пару настроек на основе отзывов о новых тестовых примерах для чистых функций Lua, и все выглядит почти готовым к работе. Прежде чем мы это развернем, я думаю, что напишу еще несколько тестовых примеров, чтобы как можно больше протестировать вспомогательные функции. Я также хотел бы, чтобы другие прокомментировали вопрос о gcd с нулевыми и отрицательными значениями. Каким должен быть наибольший общий делитель 0 и -8? 8 или -8? Я действительно не уверен. - Мистер Страдивари, выступление, 03:38, 12 декабря 2013 г. (UTC)
Лично я не думаю, что это важно. В решетке натуральных чисел (включая 0), упорядоченных по делимости, gcd - это встреча , и, насколько мне известно, это наиболее естественное определение. Если вы добавите отрицательные числа, у вас больше нет решетки, потому что (например) 8 и −8 делят друг друга, но не равны (так что делимость - это не частичный порядок, а, скорее, предварительный порядок . благодаря очевидному отношению эквивалентности вы получаете решетку обратно, за исключением того, что теперь 8 и -8 - это один и тот же узел.
Поэтому, если ваше приложение чувствительно к тому, будет ли ответ 8 или -8, вам нужно исправить свое приложение, а не беспокоиться об определении gcd. - Трубатор ( разговор ) 04:08, 12 декабря 2013 (UTC)
Я согласен с Трубадуром в том, что естественно работать с положительными целыми числами, а не с целыми числами. Но следующая наиболее естественная вещь - определить gcd (0, -8) = 8 (и аналогично gcd (-4, -8) = 4 и т. Д.), Чтобы применение gcd всегда давало положительное значение (кроме gcd (0, 0), что не определено). - JBL ( разговор ) 04:38, 12 декабря 2013 (UTC)
На самом деле я сказал натуральные числа (неотрицательные целые числа). - Трубатор ( разговор ) 05:12, 12 декабря 2013 (UTC)
О, и я не согласен с тем, что gcd (0,0) не определен; Смотри ниже. - Трубатор ( разговор ) 05:48, 12 декабря 2013 (UTC)
Проблема в том, что gcd целых чисел определяется только с точностью до знака. Вы можете всегда использовать gcd (0, x ) = x , gcd (0, x ) = - x всегда, или gcd (0, x ) = | х | всегда, или вы даже можете назначить знаки наугад. Математически они эквивалентны. Тем не менее, заставить gcd быть положительным независимо от ввода, вероятно, является правильным, но по вычислительным причинам, а не математическим: например, чтобы проверить, что два числа взаимно просты, проще всего проверить, что gcd равен 1 , а не то, что это 1 или -1. Мне кажется, что необходимость делать последнее чревато ошибками. Озоб ( разговор ) 05:01, 12 декабря 2013 (UTC)
( редактировать конфликт ) (написано до того, как я увидел ответ Озоба) Спасибо вам обоим за ответы - это очень помогает. Если бессмысленно иметь дело с чем-либо, кроме положительных целых чисел, мы можем использовать два основных подхода. Во-первых, мы можем просто вызвать ошибку, если пользователь попытается ввести что-нибудь, кроме положительного целого числа. Это имеет то преимущество, что любые ошибки будут обнаружены сразу и не будут усугубляться передачей другим функциям Lua, которые зависят от gcd; это также означало бы, что нам не нужно было бы беспокоиться о том, как именно обрабатывать крайние случаи, связанные с нулями, дробными числами и отрицательными числами.

Во-вторых, мы могли бы лучше всего предположить, что имеет в виду пользователь при вводе отрицательных чисел, нулей и дробей - это потребует округления входного числа до ближайшего целого числа, а затем преобразования знака в положительный, если функция выводит отрицательное число. Это имело бы то преимущество, что уменьшило вероятность появления большого красного текста в статьях, а также позволило бы другим функциям Lua использовать функцию gcd, не беспокоясь о проверке типа ее вывода. Однако нам все равно придется решить, что делать с gcd (0, 0). (Возможно, мы могли бы вывести nilзначение в другие модули Lua и пустую строку в #invoke.)

Я бы согласился реализовать любой из этих подходов, поэтому, пожалуйста, дайте мне знать, если вы предпочтете один из них. - Мистер Страдивари, выступление, 05:09, 12 декабря 2013 г. (UTC)

С нуля действительно проблем нет. На мой взгляд, совершенно нормально установить gcd (0,0) = 0 - это совпадение 0 и 0 в решетке, которую я описал. Некоторые авторы не любят говорить, что 0 делит 0, потому что 0/0 не определено. На мой взгляд, это немного глупо, потому что « k делит n » не означает столько « n / k - целое число», как « n - целое число, умноженное на k », и, конечно же, 0 - это целое число, умноженное на 0. Так что если вы настроите его так, чтобы он возвращал gcd (0,0) = 0, вы будете расходиться с использованием некоторых авторов, но я не могу представить себе практических проблем, которые это вызовет. - Троватор ( разговор ) 05:41, 12 декабря 2013 (UTC)
Я согласен. gcd (0,0) определен, не является частным случаем (математически) и равен нулю. Озоб ( разговор ) 14:15, 12 декабря 2013 (UTC)
Меня лично не волнует, что происходит с gcds отрицательных чисел, но, пожалуйста, пожалуйста (если вы еще этого не сделали), убедитесь, что x mod y (для положительного y) всегда возвращает целое число в интервале [0, y –1] независимо от того, отрицательно ли x. C / C ++ / Java делают это неправильно, Python понимает это правильно, а Python - это тот, который вы должны подражать. - Дэвид Эппштейн ( разговор ) 06:18, 12 декабря 2013 г. (UTC)
Это было бы очень хорошо, да. - Троватор ( разговор ) 06:27, 12 декабря 2013 (UTC)
В Module: Math нет функции mod , потому что Lua уже имеет оператор% и математическую библиотеку , а на обычных страницах вики есть modоператор для функции парсера #expr (см. Справка: Расчет ). Однако я не знаю, ведут ли они то поведение, которое вам нужно. - Г - н Страдивари ♪ ♪ разговор 6:39, 12 декабря 2013 (UTC)
Хорошо спасибо. Lua, похоже, является одним из языков с правильным модулем. - Дэвид Эппштейн ( разговор ) 08:45, 12 декабря 2013 г. (UTC)
На самом деле, глядя на более поздние сообщения в bugzilla: 6068 , похоже, что нам действительно нужна разумная функция по модулю для wikitext, поэтому я добавил функцию мода в модуль. Вы можете использовать его {{#invoke:math/sandbox|mod|x|y}}- можете ли вы протестировать его и убедиться, что он работает должным образом? - Г-н Страдивари, выступление 09:28, 12 декабря 2013 г. (UTC)
  • Примечание. На данный момент я отключил запрос на редактирование. Если мы говорим о добавлении функций в модуль, то действительно рано делать запрос. (Надеюсь, мы будем готовы к развертыванию в ближайшие несколько дней.) - Г-н Страдивари ♪ выступление ♪ 09:31, 12 декабря 2013 г. (UTC)

Я пришел сюда из-за вопроса, поднятого на лекции в Википедии: WikiProject Mathematics. Как было сказано выше, кажется, что лучший выбор для операции по модулю - это выбрать mod b в интервале [0, | b | -1]. Это означает, что gcd (a, b) неотрицателен, за исключением случаев (b = 0, a <0) или (b <0, b делит a). Если кто-то хочет упростить дроби, вам нужно окончательное значение r и s, потому что r и s взаимно просты и a / b = ± t / s для этих окончательных значений. Если a и b положительны, точнее будет a / b = -t / s, потому что as + bt = 0. Однако, чтобы узнать, является ли s или t отрицательным, нужно проверить их знаки (или отслеживать четность числа итераций.Если a или b отрицательны, то есть несколько случаев, которые следует рассмотреть, и я считаю более безопасным (и не очень дорогостоящим) начать с проверки знаков ввода, чтобы начать вычисление с | a | и | b | и отрегулировать знаки в конце. D.Lazard (обсуждение ) 13:28, 12 декабря 2013 (UTC)

Не для того, чтобы отвлекать обсуждение, но мне напомнили еще об одном хорошем моменте. Иногда от алгоритма НОД требуется не наибольший общий делитель, а тождество Безу : нужно решить ax + by = g . Такие алгоритмы обычно называют расширенными алгоритмами НОД. Они полезны (например), если вы хотите вычислить обратное в модульной арифметике. Кодирование расширенного алгоритма GCD практически идентично кодированию обычного алгоритма GCD, но вам необходимо отслеживать некоторые дополнительные выходные данные (два коэффициента). Озоб ( разговор ) 14:15, 12 декабря 2013 (UTC)
Если присмотреться, кажется, что это именно то, что вычисляет первоначально предложенный код. Было бы неплохо иметь две функции: обычный gcd ​​(который возвращает только gcd) и расширенный gcd ​​(который возвращает коэффициенты идентичности Безу). Озоб ( разговор ) 14:19, 12 декабря 2013 (UTC)
Недавно мне понадобились эти функции в Python. Стандартная библиотека Python gcd не проверяет знак и может возвращать отрицательное значение, если один из входов отрицательный. Некоторые тексты по теории чисел определяют gcd как положительное значение (за исключением gcd (0, 0)), и, как мне кажется, перенос этого значения является хорошей практикой программирования даже за счет выполнения нескольких дополнительных строк кода; программы должны возвращать однозначно определенные результаты. (Честно говоря, документация Python однозначно определяет выходные данные, хотя определение довольно сложное.) При вычислении коэффициентов идентичности Безу, также известного как расширенный алгоритм Евклида, большинство версий вычисляют решение, но не делают никаких заявлений о том, какое из многих возможных решений возвращается. Решение определяется однозначно, если накладываются дополнительные неравенства, но опять же за счет выполнения еще нескольких строк кода. -RDBury ( разговор ) 16:31, 12 декабря 2013 (UTC)
Это обсуждается в Расширенном алгоритме Евклида : с положительными входными данными расширенный алгоритм Евклида создает положительный НОД и одну из двух пар коэффициентов Безу, таких что as + bt = gcd (a, b) ≥ 0, s <b / gcd ( a, b) и t <a / gcd (a, b). Если кто-то хочет s> 0, как рекомендуется для модульного обратного преобразования, необходима еще одна строка кода, как в псевдокоде, приведенном в Расширенном алгоритме Евклида для модульного обратного преобразования. Если входные данные не обязательно положительные, результат, вероятно, будет таким же, но (при написании этой части расширенного алгоритма Евклида ) мне было лень проверить это и проверить, обсуждал ли Кнут это в своей книге (он, вероятно, сделал, в минимум в упражнениях). Д.Лазард ( разговор) 17:49, 12 декабря 2013 (UTC)
Между прочим, я следую предложению Особа о двух разных версиях: одна для одного только gcd (который не вычисляет s и t или последовательные частные) и одна для идентичности Безу (вычисляет также последние значения olds и oldt). Но я бы добавил третий для упрощения дробей (он использует последние значения s и t и некоторую настройку в конце для получения положительного знаменателя) Д. Лазард ( выступление ) 18:04, 12 декабря 2013 г. (UTC)
В Расширенный алгоритм Евклида я добавил раздел «Упрощение дробей». Д. Лазард ( разговор ) 19:26, 12 декабря 2013 (UTC)
@ D.Lazard : Имеет ли смысл возвращать коэффициенты Безу и частные в случае более двух чисел? Я знаю, что мы можем вычислить gcd более чем двух чисел, выполнив gcd (a, b, c) = gcd (gcd (a, b), c); Я не уверен, как это будет работать с коэффициентами Безу и частными. - Г-н Страдивари, выступление 02:35, 13 декабря 2013 г. (UTC)
В этом есть смысл. Это происходит рекурсивно, как и gcd (a, b, c) = gcd (gcd (a, b), c). Сначала находят такие s и t, что sa + tb = g, где g = gcd (a, b). Затем находят такие u и v, что ug + vc = h, где h = gcd (g, c). Подстановка показывает u (sa + tb) + vc = h, откуда (us) a + (ut) b + vc = h, так что us, ut и v являются коэффициентами Безу. Озоб ( разговор ) 14:36, 13 декабря 2013 (UTC)
Вы, несомненно, получите с помощью этого метода некоторые коэффициенты Безу. Но если вы измените порядок многочленов (например, вычисляя gcd (gcd (a, c), b)), вы получите разные коэффициенты Безу без какой-либо информации ни о взаимосвязях между этими двумя сериями коэффициентов Безу, ни о соотношения между этими рядами и «минимальными» (в некотором смысле) коэффициентами Безу. Я не знаю, как использовать эти обобщенные коэффициенты Безу. Постараюсь объяснить, в чем проблема. Коэффициенты Безу - это решения уравнения a 1 x 1 + ... + a k x k= gcd. Как и в случае уравнений над полем, решения этого уравнения представляют собой сумму частного решения и общего решения уравнения без правой части. Если k = 2, решение уравнения без правого члена ax + by = 0 есть (ub / gcd (a, b), ua / gcd (a, b)), где u - произвольное целое число. То есть они образуют свободную абелеву группу размерности один. Если k> 2, решения также образуют свободную абелеву группу, но ее размерность k-1. Таким образом, интересная проблема состоит в том, чтобы найти основу этой группы. Это, безусловно, может быть сделано с помощью алгоритма нормальной формы Смита , но это не является предметом данной темы. Д. Лазард ( разговор ) 16:02, 13 декабря 2013 (UTC)
Я согласен, но не уверен, что это имеет отношение к этому коду. Правильная логическая установка: расположите целые числа a 1 , ..., a k и −1 в элементе v свободной группы Z k + 1 . Тогда подрешетка Z k + 1, перпендикулярная v- множество всех возможных коэффициентов Безу. Это интересная задача как найти базис (любой базис) для этой подрешетки, так и найти «хороший» базис (т. Е. Удобный в вычислительном отношении). Первый, как вы говорите, можно решить с помощью нормальной формы Смита, а второй - с помощью LLL. Оба эти вопроса выходят за рамки этого модуля. Однако найти один выбор коэффициентов Безу несложно, используя конструкцию, которую я дал выше. Я не знаю, какое у него может быть приложение, но, по крайней мере, его легко вычислить.
@Мистер. Страдивари: Думаю, правильным ответом на ваш вопрос может быть «да, но это плохая идея». Озоб ( разговор ) 03:11, 14 декабря 2013 (UTC)
Хорошо, спасибо за ответы. Я буду реализовывать только gcd без возможности возвращать какие-либо коэффициенты Безу. Если они кому-то понадобятся, мы всегда сможем добавить их позже, или, может быть, лучше было бы создать более специализированный модуль, адаптированный к проблеме. - Г-н Страдивари ♪ выступление ♪ 23:49, 17 декабря 2013 г. (UTC)

Я заметил вышеупомянутое упоминание мода (%) и, только что обнаружив причину некоторых странностей в модуле, над которым я работаю, подумал, что поделюсь им. Я тестировал с очень большими входными данными, чтобы убедиться, что ничего не сломалось, и получил ошибку, которая была вызвана следующим. Lua оценивает 525000000000000120000000000% 3 как 68719476736! Это потому, что он вычисляет

a % b == a - math.floor(a/b)*b

и это заканчивается вычислением

525000000000000120000000000 - 525000000000000060000000000

с 68719476736как результат-мусор от превышения пределов разрешения с плавающей запятой. Johnuniq ( разговор ) 23:37, 17 декабря 2013 (UTC)

Хм, у нас были похожие проблемы с Module: Random - смотрите здесь, как мы с этим справились. Однако я не уверен, есть ли хорошее решение проблемы, которую вы описываете, или как мы будем ее реализовывать. - Г-н Страдивари ♪ выступление ♪ 23:49, 17 декабря 2013 г. (UTC)
Плохой способ, но я сделал вот что:
x = value % scale
if not (0 <= x and x < scale) then x = 0 end
Johnuniq ( разговор ) 00:23, 18 декабря 2013 (UTC)
Это цифры. Я слышал, что когда мы имеем дело с целыми числами больше 2 ^ 53, все становится очень сложно. Я реализовал твой хак и обновил модуль из песочницы. Это означает, что теперь у нас есть функция мода, и Мин Нгуен , это означает, что теперь вы, наконец, можете получить доступ к функции gcd. :) Я также добавил очень необходимую документацию - если вы заметили что-то, что я ошибся или пропустил, пожалуйста, исправьте это. - Г-н Страдивари, выступление 02:18, 18 декабря 2013 г. (UTC)
И обсуждаемые решения для генерации больших случайных чисел, и тип решения, который здесь может потребоваться, имеют общую черту: они требуют большой целочисленной арифметики. Все это означает, что большие числа представлены массивами машинных слов. Сложение происходит пословно, переноси распространяются соответствующим образом. Умножение аналогично. Также должен быть знаковый бит. Арифметика с большими целыми числами менее удобна, чем обычная арифметика, потому что она обычно не встроена в язык программирования, но в остальном это то же самое. В частности, с большой библиотекой целых чисел можно было бы точно выполнять операцию модификации, вычислять большие случайные числа и так далее. Озоб ( разговор ) 02:34, 18 декабря 2013 (UTC)

Большие целые числа [ править ]

Теперь, когда модуль обновлен, и мы говорим о возможных новых функциях или обновлениях, я подумал, что было бы неплохо начать новый раздел. Работа с очень большими числами является проблемой для всех арифметических операций в Lua, а не только в этом модуле, поэтому я думаю, что было бы лучше реализовать это как отдельный модуль. Кроме того, я нашел некоторый BigNum , код Lua, который уже делает то же самое. Однако я еще не уверен, насколько легко будет перенести его на Scribunto, и я нигде не могу найти лицензию, поэтому, возможно, мы вообще не сможем ее использовать. Однако могут быть и другие библиотеки с этой функцией - дайте мне знать, если вы их найдете. - Г-н Страдивари, выступление 02:45, 18 декабря 2013 г. (UTC)

Защищенный запрос на редактирование от 8 апреля 2014 г. [ править ]

Измените "frame: preprocess ('{{# expr:' .. number_string .. '}}')" на "frame: callParserFunction ('# expr', number_string)". Джекмакбарн ( разговор ) 23:08, 8 апреля 2014 (UTC)

Да check.svg Готово - выступление г-на Страдивари 03:32, 11 апреля 2014 г. (UTC)

Защищенный запрос на редактирование от 20 июня 2014 г. [ править ]

Пожалуйста, внесите эти изменения . Джекмакбарн ( разговор ) 02:21, 20 июня 2014 (UTC)

Да check.svg Готово - выступление г-на Страдивари 02:47, 20 июня 2014 г. (UTC)

_mod документация [ править ]

Может быть, в документации по модулю Module: Math # есть ошибка mm._round? Я мог ожидать, что функция mm._modбудет использоваться (которая не документирована в другом месте, хотя она является общедоступной). Я не проверял и не сравнивал расчеты, mm._roundможет быть прямо там. - Депип ( разговор ) 11:43, 2 июля 2014 г. (UTC)

Ой, должно быть, так было с тех пор, как я последний раз редактировал страницу / doc - и это было очень давно. Фиксированный. - Г-н Страдивари, выступление, 13:29, 2 июля 2014 г. (UTC)
Ничего страшного. Моя забава , что я доказал , я сделал RTFM  :-). - Депип ( разговор ) 21:50, 2 июля 2014 г. (UTC)

Возможное дополнение [ править ]

Никакой каламбур. Я преобразовал Template: Addition в более эффективный модуль , хотя потом подумал, что может сработать, чтобы сгруппировать его с этим модулем, который обрабатывает все другие математические функции. моль uɐɯ 20:45, 2 июля 2014 (UTC)

Красный значок информации с градиентом background.svg Не выполнено: сначала внесите запрошенные изменения в песочницу модуля; см. WP: ИСПЫТАНИЯ . Jackmcbarn ( разговорное ) 20:47, 2 июля 2014 (UTC)
Странно говорить, что я понимаю основы Lua, не понимая, как именно работает этот шаблон. Я как бы надеялся, что администратор, разбирающийся в Lua, конвертирует простую функцию, но я думаю, что сначала попробую интегрировать ее в модуль. моль uɐɯ 20:53, 2 июля 2014 (UTC)

ошибка мода [ править ]

Я использую мод так:

{{#invoke: math | mod | 123,6 | 1}} → 0,59999999999999
{{#invoke: math | mod | 345.6 | 1}} → 0,60000000000002
(жестко запрограммировано: есть, возвращает 0,60000000000002, ожидается 0,6). - Депип ( разговор ) 15:13, 22 мая 2015 (UTC)
Это связано с тем, что Lua использует числа с плавающей запятой для представления чисел, и, к сожалению, нет способа исправить это в модуле. См. Объяснение в разделе Проблемы с плавающей точкой # Проблемы с точностью . - Г-н Страдивари, выступление, 23:05, 22 мая 2015 г. (UTC)
Делает эту функцию ненадежной и бесполезной. Сколько редакторов использовали его без отметки до этого? - Депип ( разговор ) 23:48, 22 мая 2015 (UTC)
( конфликт редактирования ) Похоже, ошибка точности FP, усиленная способом ее вычисления, выполняя деление, а затем вычитание. См., Например, раздел 2.5.1 руководства . Вы можете использовать раунд, чтобы устранить его, например
{{#invoke: math | round | {{# invoke: math | mod | 123.6 | 1}} | 5}} → 0,6
Хотя это работает только в этом случае, поскольку ожидаемый результат - конечная десятичная дробь. - Джон Блэкберн слова деяния 23:12, 22 мая 2015 г. (UTC)
Вы хотите, чтобы я исследовал и использовал roundподлодку? (Как я узнаю, что такая ошибка есть?). Конечно, это вызвано FP. Моя причина в том, что я не могу доверять mod, поэтому это бесполезно. Я ожидал, что кто-то добавит mod_correct. - Депип ( разговор ) 23:38, 22 мая 2015 (UTC)
Трудно представить, как это могло работать иначе. Mod, т.е.%, часто определяется для целых чисел, чтобы дать целочисленный результат, который теоретически был бы точным. Но версия Lua так не работает, и она не будет работать в вашем примере с нецелочисленными входами. Поэтому приходится использовать математику FP (фактически двойную точность), которая неточна. Неточность в хорошо понятном смысле, поэтому есть простые обходные пути, такие как использование round, при условии, что ваш ожидаемый результат является конечным десятичным числом. Это означает , что это не возможно , чтобы обеспечить «правильную» версию моды , которая работает для всех возможных входов .-- JohnBlackburne слово поступки 23:51, 22 мая 2015 (UTC)
Я могу разбираться в вопросах FP, но мне это не интересно. Я здесь не для того, чтобы этому учиться. modбесполезно. И на самом деле вы несете чушь: в одном посте ранее вы говорили, как это можно решить округлением, теперь вы говорите, что это невозможно решить. - Депип ( разговор ) 00:21, 23 мая 2015 (UTC)
ваши примеры могут быть исправлены округлением, но не в общем случае - практически в любом случае, когда второй аргумент мода является дробью. - JohnBlackburne words deeds 00:41, 23 мая 2015 г. (UTC)
Обвиняет меня в ошибке . - Депип ( разговор ) 01:26, 23 мая 2015 (UTC)

Нет, это не было моим намерением. Я просто указывал, что мое «исправление», которое «исправляет» ваши примеры, не может использоваться в более общем плане с произвольным вводом. Никто не виноват в этом, просто математика работает, - Джон Блэкберн слова дела 01:43, 23 мая 2015 г. (UTC)

Хорошо, слишком грубо. Я ударил. - Депип ( разговор ) 21:30, 23 мая 2015 г. (UTC)
Депип, каков ваш вариант использования? Арифметика с плавающей запятой следует определенным правилам и имеет определенные ограничения, которые имеют смысл с компьютерной точки зрения, но часто кажутся странными с человеческой точки зрения. Как уже говорили другие, не существует полностью общего решения (кроме полного отказа от арифметики с плавающей запятой), но во многих конкретных случаях можно найти решения. Например, округление обычно может восстановить ожидания отображения человеком, если заранее известно, что входные данные являются завершающими десятичными знаками. Итак, каков ваш вариант использования? Полет драконов ( разговор ) 01:52, 23 мая 2015 (UTC)
Я думаю, здесь есть четко определенная математическая операция: элементы группы R / α Z представлены действительными числами в [0, α). Однако в целом определение этого представления невозможно с помощью вычислений; это не сложно, но может потребоваться бесконечная память. Я не вижу ничего плохого в приведенных выше примерах; числа с плавающей запятой имеют конечную точность, и вычисления с ними, естественно, имеют некоторую погрешность. Озоб ( разговор ) 03:59, 23 мая 2015 (UTC)
Моя причина в том, что ошибка FP не нужна. Еще сильнее: FP вообще не нужен. Результат может увидеть любой, кто просто взглянет на задачу мода. Что, если бы я не проверял это? re Озоб: «в общем, определение этого представления невозможно с вычислительной точки зрения» - я отказываюсь принять это только потому, что вы предполагаете, что «вычислительный» ограничен статусом ~ 1980 года. К тому времени Дональд Кнут заметил, что компьютеры должны уметь работать 7/9правильно. (Моя новая мысль, и придумать идею: mod_betterдолжен быть третий параметр precisionи т. Д.). - Депип ( разговор ) 21:30, 23 мая 2015 г. (UTC)
Читайте про плавающую точку здесь Christian75 ( обсуждение ) 21:51, 23 мая 2015 (UTC)
Если один из ваших входных данных равен 123,6, вам нужна математика FP. Вы можете сделать это, многократно вычитая 1, целое число, но поскольку вы вычитаете его из числа FP, вы выполняете математику FP. Если вы используете целочисленную математику (опция Lua отсутствует), вам необходимо преобразовать все входные данные в целое число, поэтому 123 или 124, что явно даст неправильный ответ. Что касается того, чтобы посмотреть на него и увидеть результат для меня, по крайней мере, так как он эффективно выполняет операцию «гидроразрыва», то есть извлекает дробную часть числа FP, обычную операцию в вычислениях. Как только вы поймете, что очевидно, каким должен быть результат, - Джон Блэкберн, слова деяния, 21:59, 23 мая 2015 г. (UTC)
Если один из ваших входных данных равен 123,6, вам нужна математика FP - нет, не нужно. Я могу сделать это мысленно, глядя на цифры. Я могу сделать это с помощью функции обработки строк, просто вырезая символы. Моя точка-1 заключается в том, что FP вводится ненужным, а затем сама FP создает проблему. Пункт 2 заключается в том, что вы все время говорите мне, что иначе нельзя. - Депип ( разговор ) 22:07, 23 мая 2015 (UTC)
Математические функции Lua используют математику с плавающей запятой (как, впрочем, и функция синтаксического анализатора #expr), и во многих случаях позволяют вводить базовые выражения. Если вы хотите использовать какую-то формулировку точной математики, вы, конечно, можете это сделать, хотя, по-видимому, вам нужно будет либо сделать это вручную, либо написать для этого свои собственные функции. Если вы хотите использовать точную математику, вы получите другой набор крайних случаев, например, как вы выбираете представление дробей, констант и других выражений, например {{#invoke: math | mod | 11/3 | 1}} = 0,6666666666667 или {{#invoke: math | mod | e ^ pi | 1}} = 0,140692632779. Оба они здесь являются усеченными десятичными знаками, но дают разумные приближения. Лично я думаю, что {{#invoke: math | mod | 345.6 | 1}} → 0,60000000000002 также является разумным приближением, хотя, очевидно, вы не согласны.В последнем случае вы можете получить точный ответ путем округления, но любой из двух предыдущих примеров станет несколько менее точным при дальнейшем округлении. Если вы ограничиваете класс входных данных, которые вы разрешаете (например, только конечные десятичные числа), тогда можно было бы написать функцию, которая более точна для этого класса выражений (например, используя строковые операции), но у вас будет другой набор возможностей и ограничений. чем текущий мод, используемый здесь.но у вас будет другой набор возможностей и ограничений, чем у текущего мода, используемого здесь.но у вас будет другой набор возможностей и ограничений, чем у текущего мода, используемого здесь. Полет драконов ( разговор ) 23:58, 23 мая 2015 (UTC)
«Математические функции Lua используют математику с плавающей запятой» - О. Почему это актуально для меня? «Если хочешь использовать ...» - Нет, не хочу . Где я так сказал? Я хотел чего-то еще. (Еще один хороший редактор, объясняющий мне, что я тот, кто не понимает. К настоящему времени уже достиг десятка). Просто прочтите F OP. - Депип ( разговор ) 02:28, 27 мая 2015 (UTC)
Повторюсь - в модуле это исправить не возможно. Это отстой, я знаю, но мы ничего не можем с этим поделать. - Г-н Страдивари, выступление 02:46, 27 мая 2015 г. (UTC)
Да нет. Я знаю. Просто рад, что вовремя узнал. - Депип ( разговор ) 02:55, 27 мая 2015 (UTC)

@ Г-н Страдивари и Депип : На самом деле, может быть способ обойти это, что сделает всех счастливыми. При вызове из викитекста мы можем округлить возвращаемое значение до 15 значащих цифр. Я уже настроил Module: Decimals для этого некоторое время назад. Джекмакбарн ( разговор ) 16:11, 27 мая 2015 (UTC)

Я планировал просмотреть эту страницу, но сохранил ее. Я оставлю свои препирательства. - Депип ( разговор )

Защищенный запрос на редактирование от 27 марта 2016 г. [ править ]

Я упростил некоторые вещи в Module: Math / sandbox , создав новую binary_fold()функцию для min и max, которая принимает функцию, которая возвращает true, когда "доминирующее" значение должно быть следующим значением, и false в противном случае, изменил некоторые локальные функции на анонимные функций, и изменил "applyFuncToArgs" на "fold", поскольку прежнее название вводит в заблуждение: оно означает, что оно "отображает" список в соответствии с функцией, а не свертывает / сокращает его до одного значения. Diff + Amendment (финальная версия - последняя версия или последняя версия), тестовые примеры . Без функциональных изменений. Esquivalience t 01:48, 27 марта 2016 г. (UTC)

  • Модуль: Math • Модуль: Math / песочница • разные ( дифф )

Johnuniq ( разговор ) 02:43, 27 марта 2016 (UTC)

Да check.svg Готово. Я всегда знал, что «applyFuncToArgs» - паршивая функция, но тогда я не знал достаточно программирования, чтобы знать что-то лучше или понять, что я могу расширить функциональность с помощью двоичной версии. Это большое улучшение. - Г-н Страдивари ♪ доклад ♪ 12:17, 28 марта 2016 г. (UTC)

Защищенный запрос на редактирование от 25 июня 2018 г. [ править ]

Fix опечатка в комментариях: изменение {{#invoke:Math | log | x }}к {{#invoke:Math | log10 | x }}в комментариях чуть выше wrap.log10функции, потому что функция называется «log10». {{3x | p}} ery ( talk ) 03:41, 25 июня 2018 г. (UTC)

Я бы поставил это в список дел, а не набрал 1,6 миллиона страниц из-за опечатки. Johnuniq ( разговор ) 03:55, 25 июня 2018 (UTC)
На данный момент отключен. Если вы оставите это в песочнице, его можно будет развернуть, когда в то же время будут внесены более существенные изменения - Мартин ( MSGJ  ·  talk ) 07:22, 26 июня 2018 г. (UTC)
Примерно в 2020 году, показывает ли что-нибудь прошлое? {{3x | p}} ery ( talk ) 21:46, 26 июня 2018 г. (UTC)

Защищенный запрос на редактирование от 30 сентября 2018 г. [ править ]

@ Primefac : замените содержимое Module: Math на Module: Math / sandbox , эти исправления позволяют функции median принимать десятичные числа и не возвращать сообщение об ошибке при отсутствии ввода. См. User: BrandonXLF / sandbox / 5 и Template: Median . - BrandonXLF (t @ lk) 23:13, 30 сентября 2018 г. (UTC)

 Частично сделано: я реализовал лучшее решение, используя существующие подфункции в модуле. Primefac ( разговор ) 23:21, 30 сентября 2018 (UTC)

Работает ли параметр round's precision = для значений, которые округляются до ближайшего целого числа? [ редактировать ]

Согласно документации, я ожидал, что {{#invoke:Math|precision_format|value=1.02|precision=1}}в результате будет "1.0". В настоящее время результат - «1». При правильном использовании значения «1,12» возвращается «1,1». Что мне не хватает?

Обновление: функция precision_format работает лучше, но я не знаю, делает ли она то, что я хочу. См. Шаблон: Инфляция / контрольные примеры # Значимые цифры . - Jonesey95 ( разговорное ) 23:27, 21 октября 2019 г. (UTC)

Это связано с тем, что разработчики этого модуля неуклюже написали функцию. Попробуйте вместо этого вызвать formatnum .formatNum (number, lang, prec). Я не уверен, что их оболочка {{#invoke}} пригодна для использования, но функция определенно вызывается из Lua, а именно из модуля: Complex_date . Incnis Mrsi ( разговор ) 10:12, 22 октября 2019 (UTC)
В формате formatnum есть комментарии, в которых говорится, что он усекает, а не округляет, и мне не удалось заставить работать оператор invoke. Насколько я могу судить, параметр precision_format = этого модуля отлично подходит для округления и точности, поэтому я просто использовал его. - Jonesey95 ( разговорное ) 16:06, 22 октября 2019 г. (UTC)

precision_format [ править ]

Возможно ли иметь версию precision_format, которая не использует научную нотацию для малых чисел? например иметь {{#invoke:Math|precision_format|1/30000|7|scinote=n}}возврат 0,0000333 вместо 0? Я, вероятно, мог бы что-нибудь взломать, постобработав вывод, но, кажется, лучше иметь способ сделать это в модуле, поскольку модуль выполняет эту часть в самом конце. Frietjes ( разговорное ) 18:36, 7 декабря 2019 (UTC)

Как получить разницу двух чисел [ править ]

Как код записи , чтобы получить разницу два численного values.?- ❙❚❚ ❙❙ JinOy ❚❙❚ ❙❙ ✉ 19:50, 8 апреля 2020 (UTC)

Gnoeee , вы бы не использовали для этого модуль, вы бы использовали #expr условное выражение для вычисления разницы. Например, {{#expr: 2-1}}→ 1. Primefac ( разговорное ) 20:13, 8 апреля 2020 (UTC)
@ Primefac : - Спасибо. Я просто попытался тест, {{#invoke:math|sum|10|-5}}и работы- ❙❚❚ ❙❙ JinOy ❚❙❚ ❙❙ ✉ 20:22, 8 апреля 2020 (UTC)
Думаю, технически это тоже работает. Думаю, я просто считаю, что #expr намного проще в использовании и менее трудоемко. Primefac ( разговорное ) 20:29, 8 апреля 2020 (UTC)
Я добавил его в статью « Пандемия коронавируса 2020 года в Керале», чтобы подсчитать количество активных случаев. Из Викиданных я получил общее количество случаев, число смертей и выздоровление. Активные обращения недоступны в Викиданных. Итак, добавлен код с #expr и его работа. Но в моей родной Wiki (малаялам) #expr показывает ошибку при попытке. Так что использовали 'математику' над there.- ❙❚❚ ❙❙ JinOy ❚❙❚ ❙❙ ✉ 20:58, 8 апреля 2020 (UTC)

ошибка " " [ править ]

Здравствуйте, это не проблема enwiki. В bnwiki этот модуль иногда дает неверный результат. Возникла проблема с "precision_format". Например, {{#invoke: Math | precision_format | 2.0004 | 3}} дает ২ 000 вместо ২,০০০ ( еще пример , bn: Module: Math , песочница ). Как я могу это исправить? Не стесняйтесь редактировать песочницу. - আফতাবুজ্জামান ( разговорное ) 23:56, 2 июня 2020 (UTC)

@ আফতাবুজ্জামান : Эта ошибка связана со следующим оптимистичным кодом:
local zero_sep = lang: formatNum (1.1)formatted_num = formatted_num .. zero_sep: sub (2,2)
Код пытается определить символ десятичной точки (например, .или ,). Код предполагает, что местный номер использует английские цифры, и в этом случае :sub(2,2)будет извлечен второй символ, которым, как они надеются, является .или ,. Однако в bnwiki 1.1 это ১.১, и код получает второй байт первой цифры, которая дает этот сломанный символ Unicode. Простым исправлением было бы изменить приведенное выше, закомментировав или удалив первую строку и отредактировав вторую строку:
--local zero_sep = язык: formatNum (1.1)formatted_num = formatted_num .. '.'.
Немного умнее было бы изменить его так, чтобы использовать mw.ustring.sub, но для вас это бессмысленно, потому что вы знаете, что вам нужна точка. В результате будут использоваться en-цифры. С этим мало что можно сделать, кроме кода преобразования, который мы обсуждали в прошлом. Johnuniq ( разговор ) 05:09, 3 июня 2020 (UTC)
@ Johnuniq : Спасибо. Проблема решена. Все дает правильный результат, но почему-то {{round|0.000020004|7}}дает неверный результат. আফতাবুজ্জামান ( разговор ) 03:02, 4 июня 2020 (UTC)

@ আফতাবুজ্জামান : Хм, похоже, это ошибка в lang: formatNum. Поместите следующее в песочницу модуля и проверьте с помощью {{#invoke:SANDBOXNAME|main}}.

локальная функция main () локальный язык = mw.getContentLanguage () локальный r = lang: formatNum (0,00002) return #r .. '/' .. r .. '/'конецreturn {main = main}

Попытка дать показанные результаты:

  • В bnwiki: 7 /২.০/ (цифрами en, это "7 /2.0/")
  • В enwiki: 6 /2.0E-5/

7 - это длина (количество байтов) результата. Каждая из двух миллиардов цифр составляет 3 байта в UTF-8, а точка - 1, поэтому в сумме получается 7. Дело в том, что в выводе нет ничего скрытого - это всего 7 байтов. Думаю, вы могли бы спросить об этом в Phabricator. Возможно, электронная нотация не поддерживается на языке, где она обычно не используется? Это используется? Johnuniq ( разговорное ) 03:59, 4 июня 2020 (UTC)

@ Johnuniq : Да , электронная нотация необычна в бенгальском языке. Я не уверен, что мне следует запрашивать при отправке сообщения об ошибке. Если можете, пожалуйста. Во всяком случае, проведя много часов я был в состоянии сделать это , кажется , это устранит проблему. Стоит ли внедрять? - আফতাবুজ্জামান ( разговорное ) 00:44, 7 июня 2020 (UTC)
@ আফতাবুজ্জামান : Это изменение выглядит хорошо, молодец! Я изучил код на предмет ваших изменений, но решение о том, что общая функция всегда работает, было бы головокружительным делом, поэтому я не углублялся ранее. Повторите мой предыдущий комментарий об ошибке: если вы свяжетесь с песочницей модуля, которую я мог бы создать (здесь будет Module: Sandbox / Johnuniq / format), я, вероятно, попытаюсь сообщить об этом. Johnuniq ( разговор ) 01:29, 7 июня 2020 (UTC)
@ Johnuniq : Спасибо. здесь . আফতাবুজ্জামান ( разговор ) 01:45, 7 июня 2020 (UTC)
@ আফতাবুজ্জামান : Я писал на phab: T254683 . Johnuniq ( разговор ) 07:45, 7 июня 2020 (UTC)

Я вижу, что обновление программного обеспечения после вышеизложенного изменило происходящее. bn: Обсуждение модуля: খেলাঘর / Johnuniq / формат используется, чтобы показать, что lang:formatNum(0.00002)bn дает эквивалент «2.0» (неверно), в то время как здесь, в enwiki, он дает «2.0E-5». Теперь оба результата эквивалентны «0». Некоторые последствия:

  • {{#invoke:Math|precision_format|2.0004|3}} → 2.000 (хорошо)
  • {{round|0.00019|4}}→ 0,0002 (хорошо)
  • {{round|0.000019|5}} → 0
  • {{round|0.000020004|7}} → 000

Johnuniq ( разговор ) 06:26, 11 января 2021 (UTC)