Обсуждение Википедии:Руководство по стилю/Даты и числа

Астрономические единицы

(Обсуждение завершилось внесением изменений в MOS.)

Недавно в другой теме был сделан вывод, что единицы, одобренные для использования с СИ, не нуждаются в переводе в единицы СИ. Астрономические единицы (AU) одобрены для использования с СИ, но были высказаны некоторые мнения, что их следует переводить в единицы СИ.

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

Предыдущее обсуждение привело к решению не использовать метрические префиксы больше "тера", поскольку они не будут широко поняты; планетные системы простираются до петаметров, например, гелиопауза , хотя большинство расстояний в а.е., вероятно, не так. Статьи, такие как Makemake, в настоящее время используют Tm.

Какое решение поддерживают люди?

1. Астрономические единицы принимаются для использования в системе СИ и не требуют преобразования.
2. Астрономические единицы следует преобразовывать в километры с использованием «миллион», «миллиард» или «триллион» как в тексте, так и в компактных средах, таких как информационные окна и таблицы. Примеры:
   • 49,3 а.е. (7,38 млрд км)
   • 121 000 а.е. (18,1 трлн км)
3. Астрономические единицы следует преобразовывать в метры с использованием метрических префиксов . Примеры:
   • 49,3 а.е. (7,38 Тм)
   • 121 000 а.е. (18,1 Pm)
4. Что-то еще.

Вероятно, мы перейдем к использованию световых лет и парсеков, прежде чем преодолеем 9999 триллионов км, возможно, даже до 999 триллионов км. Миллион а.е. составляет около 150 триллионов км, а превышение 1 миллиона а.е. в любом случае может быть неудобным. -- Beland ( обс .) 19:06, 6 сентября 2024 (UTC) [ ответить ]

Я ничего не имею против световых лет или AU , но статьи должны включать преобразованное значение в метры с соответствующим префиксом, который избегает десятичных знаков 49,3 AU (7380 Gm). В конце концов, километр равен 1000 метров. Wikipedia просвещает, читатель всегда может сослаться на Giga или другой префикс, чтобы узнать, что это такое. Мы уже используем Giga или Gibi для хранения данных в компьютере. Avi8tor ( обсуждение ) 19:29, 6 сентября 2024 (UTC) [ ответить ]

Хм, Wikipedia:WikiProject Astronomy/Manual of Style#Units рекомендует км/с для больших скоростей, таких как межпланетные космические корабли. Немного сложнее сравнивать десятки тысяч км/с с Tm вместо миллиардов км (хотя, очевидно, намного проще, чем мили). -- Beland ( обсуждение ) 20:22, 6 сентября 2024 (UTC) [ ответить ]

Ваш вариант 2 кажется хорошим балансом: триллион — это самое большое, чего мы когда-либо действительно достигли (когда-то около 100 000 а.е. нам следует перейти на ly; возможно, стоит включить это в руководство!), и я не вижу большой выгоды в использовании метрических префиксов для миллиона и миллиарда здесь. Я думаю, что смысл преобразованного значения в том, чтобы у людей было значение, которое они могут попытаться сравнить с обычной жизнью, и «миллион км» кажется проще сделать это, чем «миллиард м». Научная нотация, вероятно, не стоит использовать в прозе, но может быть в информационных полях? - Parejkoj ( обсуждение ) 20:31, 6 сентября 2024 (UTC) [ ответить ]

НЕ #3. Цель преобразования — выйти за рамки специализированного языка. Давать две специализированные версии бессмысленно. Johnjbarton ( talk ) 23:04, 6 сентября 2024 (UTC) [ ответить ]

Вариант 2 ясен и полезен, и нам не нужно беспокоиться о выражении чего-либо в триллионах километров. Нептун находится всего в 30 а.е. (4,5 млрд км) от Солнца, и даже гелиопауза находится примерно в 120 а.е. (18 млрд км). 121 000 а.е. (1,91 светового года) — это действительно межзвездное расстояние, почти на полпути к ближайшей звезде здесь, в глуши, и я бы не ожидал, что наши источники будут использовать а.е. Не #3, это делает чтение слишком тяжелым трудом. NebY ( talk ) 23:38, 6 сентября 2024 (UTC) [ ответить ]

Я, должно быть, читал что-то другое, а не о гелиопаузе, которая находится в 120 000 а.е., и перепутал цифры. Облако Оорта и пара десятков других статей используют 200 000 а.е., 100 000 а.е. и 50 000 а.е. Например, Comet на самом деле преобразует 50 000 а.е. в световые годы.

Мы могли бы на самом деле посоветовать, скажем, что все, что больше 10 000 а.е., должно преобразовывать а.е. в световые годы, а не в километры (это около 0,16 световых лет). Это начинает становиться значительной частью расстояния до ближайшей звезды. Это облегчило бы переход от км к световым годам; в противном случае короткие расстояния будут иметь а.е.+км, а большие расстояния — световые годы+pc, и нет никакого способа сравнить их напрямую. -- Beland ( talk ) 00:58, 7 сентября 2024 (UTC) [ ответить ]

Я бы предпочел использовать AU для малых (астрономических) расстояний и pc (или ly) для больших, с обеспечением непрерывности за счет постоянного преобразования в SI. Я понимаю предложение Беланда так: преобразовать AU в km для коротких расстояний, AU в ly для средних расстояний и ly в pc для больших межзвездных расстояний. Это свиное ухо, но это, вероятно, лучшее, что мы можем сделать, учитывая (ошибочное по ИМХО) решение избегать преобразования межзвездных расстояний в SI. Dondervogel 2 ( talk ) 06:42, 7 сентября 2024 (UTC) [ ответить ]

Ах да, я забыл, насколько велики могут быть кометные орбиты и предполагаемые размеры облака Оорта. Я не решаюсь давать советы по точке перехода (немного похоже на то, когда следует использовать дюймы или футы) или вводить третью пару преобразования. Мое практическое правило может быть таким: в планетарном или внутрисистемном контексте используйте au/km, в межзвездном — ly/pc, и если его следует поместить в оба контекста, то рассмотрите возможность использования не только пары одного контекста, но и ведущего измерения из другого (au/km + ly или ly/pc + au), но экономно — и должен быть лучший способ выразить это. NebY ( talk ) 12:34, 7 сентября 2024 (UTC) [ ответить ]

Я согласен, что нам не следует иметь расстояние перехода, а вместо этого рекомендовать AU для внутрисистемных контекстов и ly для межзвездных контекстов. Когда оба контекста имеют значение, я думаю, лучше не пытаться создать правило; Солнечная система смешивает AU, ly и km в разных местах, и я думаю, что они делают хорошую работу. Tercer ( talk ) 13:03, 7 сентября 2024 (UTC) [ ответить ]

Может, нам просто сказать что-то вроде «там, где межпланетные и межзвездные масштабы пересекаются, можно преобразовывать AU в световые годы, чтобы расстояния были сопоставимы»? Кстати, для явно межпланетных расстояний вы были за AU+км или просто AU? -- Beland ( обсуждение ) 16:55, 7 сентября 2024 (UTC) [ ответить ]

Я думаю, что это хорошее решение. Что касается AU+км или AU, у меня нет твердого мнения. 150 миллионов км — это на грани того, что можно интуитивно понять, поэтому это может быть полезно для некоторых читателей. Я не думаю, что это стоит беспорядка, поэтому я бы предпочел написать только AU. Но если какой-то редактор захочет добавить преобразование км, я не буду беспокоить его по этому поводу. Tercer ( обсуждение ) 19:28, 7 сентября 2024 (UTC) [ ответить ]

Лично я бы отдал предпочтение варианту 2 как наиболее удобному для чтения. Однако вариант 1 логически вытекает из нашего общего правила, что «единицы, одобренные для использования с СИ, не нуждаются в преобразовании в единицы СИ», поэтому это тоже было бы разумным решением. Gawaon ( talk ) 06:42, 8 сентября 2024 (UTC) [ ответить ]

Вариант №4 . Ни один из вариантов №1-3 несовместим с использованием pc/ly для межзвездных расстояний. Чтобы избежать несоответствий, нам нужно перекрытие между

• большие межпланетные расстояния (в а.е.) и малые межзвездные расстояния (в световых годах/пк), и
• большие планетные расстояния (в км) и малые межпланетные расстояния (в а.е.).

Единственный способ, который я вижу, чтобы достичь обоих, — это преобразовать au в SI для малых межпланетных расстояний и au в ly/pc для больших s. Dondervogel 2 ( talk ) 09:02, 8 сентября 2024 (UTC) [ ответить ]

Комментарий Приведем несколько примеров того, как в настоящее время обрабатывается последнее: при прогнозируемом минимальном расстоянии 0,051 парсека — 0,1663 световых года (10 520 астрономических единиц) (около 1,60 триллиона км) (от ледника Глизе 710 ); около 52 000 астрономических единиц (0,25 парсека; 0,82 световых года) от Солнца (от звезды Шольца ); и большая полуось 506 а.е. (76 миллиардов км) или 0,007 световых лет (из инфобокса Седны ). Renerpho ( обсуждение ) 22:55, 8 сентября 2024 (UTC) [ ответ ]

Второй вариант мне кажется предпочтительным стилем MOS (кроме выбора единиц) для тройного преобразования и чего-то, что естественным образом получается из {{ convert }} , тогда как два других требуют некоторой доработки. Четверное преобразование кажется немного перебором. -- Beland ( talk ) 17:20, 9 сентября 2024 (UTC) [ ответить ]

В случае статьи о солнечной системе стало немного глупо продолжать конвертировать шкалы расстояний из AU в км. Было достигнуто общее согласие использовать AU везде, поскольку AU предназначена для межпланетных масштабов (тогда как км предназначен для планетарных масштабов). В начале статьи есть комментарий, объясняющий этот термин, и это все, что нужно. Сопоставимое преобразование, используемое в статьях об астероидах, — AU и Gm. Praemonitus ( обсуждение ) 21:57, 9 сентября 2024 (UTC) [ ответить ]

• Из перечисленных вариантов я бы выбрал вариант 1 (использовать только AU), хотя я мог бы увидеть преобразование в км или м с использованием научной нотации. У меня довольно сильная негативная реакция на Gm, Tm и т. д.; я думаю, что это просто фетишизм СИ. Я почти уверен, что эти единицы используются в дикой природе очень редко. -- Trovatore ( обсуждение ) 00:17, 10 сентября 2024 (UTC) [ ответить ]

Я бы выбрал вариант 1, но самое главное, мы должны использовать современную аббревиатуру au везде, где она появляется. Использование Википедии оставалось непоследовательным слишком долго (включая эту ветку). Skeptic2 ( обсуждение ) 11:29, 12 сентября 2024 (UTC) [ ответить ]

Полностью согласен с согласованностью символа (au, а не AU). Давайте убедимся, что любые новые указания отражают этот консенсус. Dondervogel 2 ( обсуждение ) 11:55, 12 сентября 2024 (UTC) [ ответить ]

Это предложение удалить «Статьи, которые уже используют AU, могут перейти на au или продолжить с AU; ищите консенсус на странице обсуждения». из MOS:UNITSYMBOLS ? Я использую «AU» в разговоре, потому что это то, чему я научился, будучи студентом, но у меня нет особых предпочтений. -- Beland ( обсуждение ) 18:00, 12 сентября 2024 (UTC) [ ответить ]

Это не было моим намерением. Я просто имел в виду, что любое новое утверждение об астрономических единицах должно следовать существующему консенсусу mosnum, который заключается в использовании au для обозначения единицы. Я не могу говорить за Skeptic2. Dondervogel 2 ( обсуждение ) 18:06, 12 сентября 2024 (UTC) [ ответ ]

У меня нет четких предпочтений между au и AU, но я не совсем уверен, что это нужно унифицировать по всей Википедии. Главное, чтобы это было единообразно в рамках любой отдельной статьи, в духе WP:ARTCON . -- Trovatore ( talk ) 18:09, 12 сентября 2024 (UTC) [ ответить ]

Хм, ну, существующий консенсус не совсем для "au", он для "au", за исключением случаев, когда "AU" последовательно установлено. Я намеренно использовал "au" в примерах, потому что это, кажется, долгосрочное направление, в котором мы движемся, но для согласованности с другой рекомендацией примеры, возможно, должны иметь примечание о том, что "AU" допустимо, если используется последовательно на протяжении всей статьи. С другой стороны, если мы добавляем или удаляем преобразования по всему проекту, это было бы подходящим временем для стандартизации "au". Отказ от исключения "AU" также приведет к более простым правилам. В любом случае, я собираюсь запустить скрипт для поиска несоответствующих случаев, как я сделал, чтобы обеспечить соблюдение нового правила, согласно которому liter использует заглавный символ "L".

Кстати, мне было интересно, где был установлен консенсус по существующим рекомендациям, и, похоже, это обсуждение в Википедии: Руководство по стилю/Даты и числа/Архив 157#Сокращение для астрономической единицы еще раз . -- Beland ( обсуждение ) 18:16, 12 сентября 2024 (UTC) [ ответить ]

Я предпочитаю вариант 1 , без преобразований или с дополнительными преобразованиями. 21 Andromedae ( обсуждение ) 15:27, 14 сентября 2024 (UTC) [ ответить ]

Использование au вместо AU было рекомендовано МАС в 2012 году и в настоящее время принято ведущими профессиональными журналами, такими как MNRAS, ApJ, AJ и т. д. Таким образом, au является международно признанной аббревиатурой и должна была быть принята Википедией десять лет назад. Skeptic2 ( обсуждение ) 19:00, 12 сентября 2024 (UTC) [ ответ ]

Подводя итоги au

Хорошо, попытаюсь оценить приведенные выше мнения в редукционистской манере (поправьте меня, если я где-то ошибся):

• Ави8тор: #3
• Парейкой: #2
• Джонджбартон: НЕ #3
• NebY: #2, НЕ #3, для перекрытия: au+km+ly (и наоборот ly+pc+au)
• Dondervogel2: #2 больше или меньше, для перекрытия au+km, au+ly+pc
• Tercer: #1, но #2 допустимо, для перекрытия: «там, где межпланетные и межзвездные масштабы перекрываются, допустимо преобразовывать астрономические единицы в световые годы, чтобы сделать расстояния сопоставимыми», а не конкретное правило
• Гаваон: #2, но #1 ОК
• Praemonitus: №1 в Солнечной системе.
• Трубадур: #1, но #2 ОК, m с научной записью ОК, НЕ #3
• Скептик2: #1

И подведем итоги:

• #1: 3 первых варианта, 1 второй вариант, 1 для контекста солнечной системы
• #2: 4 первых выбора, 2 вторых выбора
• #3: 1 за, 3 явно против
• #4: 3 в пользу преобразования из au в ly, чтобы обеспечить перекрытие

Довольно очевидно, что существует консенсус против #3, и похоже, что есть слабое предпочтение #2 перед #1. Учитывая причины, по которым люди отметили «за» и «против» преобразования au в km, может иметь смысл принять #2, но подчеркнуть существующее «чрезмерное» исключение, которое приведет к #1 в тех местах, где, как я ожидаю, люди сильнее всего чувствуют, что au-only лучше.

Кажется, мы предпочитаем "au" вместо "AU", поэтому я буду использовать это в примерах. Я провожу сканирование баз данных и спрошу об удалении "AU" из разрешенной единицы отдельным вопросом, как только у меня появятся некоторые цифры.

Также кажется, что есть поддержка перекрывающихся, но не жестко определенных диапазонов между km, au и ly, чтобы читатели могли делать соответствующие сравнения. Как именно это сделать, было немного неясно, но ради операционализации этого я внесу конкретное предложение. (Если у людей есть сильные чувства, не стесняйтесь обсуждать.) Предыдущий RFC решил преобразовать ly в pc, и могут возникнуть некоторые возражения, если использовать ly, а pc — нет (хотя астрономы также используют au). Также было решено не преобразовывать между km и ly, отчасти из-за проблем с пониманием при слишком больших количествах km, так что, возможно, нам следует избегать этого. Что также означало бы, что одни и те же единицы будут использоваться независимо от того, являются ли au или ly первичными, что довольно мило. Таким образом, перекрывающимися единицами на верхнем конце будут au, ly и pc, с первичными ly или au.

Итак, как насчет того, чтобы добавить это в качестве еще одного пункта «В общем... за исключением» после исключения «световых лет»:

• Астрономические единицы (au) следует преобразовывать в километры (км) с использованием "million", "billion" или "trillion" как в тексте, так и в компактных средах, таких как инфобоксы и таблицы. Когда большие межпланетные расстояния перекрываются с малыми межзвездными расстояниями, преобразуйте au в ly и pc или ly в pc и au (в зависимости от контекста). Примеры:
  • 49,3 а.е. (7,38 млрд км)
  • 121 000 астрономических единиц (1,91 световых лет ; 0,59 парсека )
  • .9 световых лет (0,28 пк; 57 000 а.е.)

и добавьте «статьи, подобные Солнечной системе , где указано много межпланетных расстояний» в список примеров «чрезмерного» исключения. -- Beland ( обсуждение ) 03:26, 13 сентября 2024 (UTC) [ ответить ]

Спасибо, что уделили время. Вы хорошо уловили мою позицию в своем резюме. Dondervogel 2 ( talk ) 05:52, 13 сентября 2024 (UTC) [ ответить ]

Я думаю, что последний пример должен читаться как "0.9 ly", поскольку мы не делаем 0-dropping. В остальном мне нравится! Gawaon ( talk ) 06:11, 13 сентября 2024 (UTC) [ ответить ]

О, чувак, верно подмечено. У меня есть скрипт, чтобы исправить именно это, и мне жаль, что я этого не заметил. Так что сделайте это:

0,9 световых лет (0,28 пк; 57 000 а.е.)

— Предыдущий неподписанный комментарий добавлен Beland ( обсуждение • вклад ) 17:57, 13 сентября 2024 (UTC) [ ответить ]

Добавлено на страницу MOS; дальнейшие изменения приветствуются, если кто-то заметит что-то еще неладное. -- Beland ( обсуждение ) 23:00, 13 сентября 2024 (UTC) [ ответить ]

Руководство на APPROXDATE для совершенно неизвестных диапазонов

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

Я предлагаю добавить:

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

Это фактически сделало бы «опустить это» значением по умолчанию. Мысли / альтернативные идеи? Будет ли это полезным включением? (Или, в качестве альтернативы, кто-нибудь хочет поспорить, что мы должны предложить что-то другое для этого случая, например, использовать «(неизвестно)», даже если это может быть известно, просто не редакторам Википедии в данный момент?) SnowFire ( обсуждение ) 22:04, 10 сентября 2024 (UTC) [ ответ ]

• Два момента:
  • Проблема не касается конкретных дат или диапазонов дат. Это могут быть любые данные в таблице, поэтому я не уверен, что это проблема конкретно с датами и числами.
  • Совет сказать «неизвестно» или «спорно» хорош, но моя интуиция подсказывает, что это не то, о чем MOS должен высказывать свое мнение (по крайней мере, пока) — см. WP:MOSBLOAT . Возникали ли в настоящее время споры по этому поводу в нескольких статьях?

E Eng 23:27, 10 сентября 2024 г. (UTC) [ ответить ]

Честно говоря, я не уверен, что это всплывает особенно часто. Недавно это всплыло на обсуждении FLC, и я понял, что, похоже, не существует «стандарта» для урегулирования этого вопроса. Я чувствителен к проблемам CREEP, и если мы просто хотим отложить это как «подождать, пока второй человек пожалуется», это нормально для меня — просто подумал, что первый человек, поднявший этот вопрос, все равно может быть полезным сигналом. SnowFire ( обсуждение ) 09:14, 11 сентября 2024 (UTC) [ ответить ]

Категорически против этого предложения. Это возникает все время , если вы пишете о средневековых и более ранних людях и событиях. Очевидно, что вам все равно нужно что-то включить. Совершенно нелепо говорить, что датирование должно быть подавлено только потому, что мы не знаем, например, родился ли кто-то в 1105 или 1109 году, или в какой-то промежуточной дате! Но нет смысла в еще одном тонко отточенном наборе инструкций, который большинство проигнорирует. MOS:APPROXDATE уже слишком длинный и чрезмерно предписывающий. Johnbod ( talk ) 15:34, 21 сентября 2024 (UTC) [ ответить ]

Предполагаемые или приблизительные недаты?

Мы обычно не используем c.  (и т. д.) для цифр, отличных от дат, даже в тех местах, где мы бы с радостью использовали английское слово around . Будет ли уместно явно упомянуть варианты для недат, такие как est.  , approx.  , и связанные шаблоны где-нибудь? И попытка использования circa для недат, и общая путаница по этому вопросу кажутся по крайней мере получастыми. Remsense  ‥ 论05:36, 21 сентября 2024 (UTC) [ ответить ]

Circa или c. в основном используется для дат, но в его значении нет ничего, что делало бы его только для дат. Создание нового правила (в дополнение к нашему и так слишком большому количеству) кажется мне излишним.  SchreiberBike  |  ⌨  00:49, 22 сентября 2024 (UTC) [ ответить ]

Согласен, что не должно быть никаких новых положений, но использование c. или circa для чего-либо, кроме дат, лет и т. д., покажется читателям очень неуклюжим. Я бы бросил вам вызов, чтобы вы нашли любое использование, не связанное со временем, в высококачественных источниках. E Eng 01:24, 22 сентября 2024 (UTC) [ ответить ]

Мне это кажется этимологической ошибкой: само существование более узкой конвенции, где он используется только для дат, означает, что другие варианты использования, пытающиеся рассматривать его как идеальный синоним слова « около» , читать активно неудобно; это неправильное использование. С учетом этого я бы возразил, что это, скорее всего, MOS creep: приблизительные и оценочные цифры важны и распространены, и редакторы регулярно выражают общее отсутствие понимания того, как лучше всего их представить. Remsense  ‥ 论00:58, 22 сентября 2024 (UTC) [ ответить ]

Подождите... вы возражаете против собственного предложения как WP:MOSCREEP ? E Eng 01:24, 22 сентября 2024 (UTC) [ ответить ]

Нет, извините: я возражал против беспокойства Шрайбера по поводу MOSCREEP. Remsense  ‥ 论01:27, 22 сентября 2024 (UTC) [ ответить ]

То есть вы хотели сказать что-то вроде "Я возражаю против характеристики этого как MOSCREEP"? При таком предположении я не согласен (с вами), пока (согласно MOSCREEP, который -- кхм -- я написал) не будет доказательств того, что эта проблема была проблемой на нескольких страницах. Есть? E Eng 01:44, 22 сентября 2024 (UTC) [ ответить ]

Вы правы. Определенно есть классы статей, где это проблема; я посмотрю, что я могу сделать. Remsense  ‥ 论01:46, 22 сентября 2024 (UTC) [ ответить ]

Как кот, который съел немного сыра, а затем встал у мышиной норы, я жду, затаив дыхание. E Eng 02:47, 22 сентября 2024 (UTC) [ ответить ]

Последние правки

Ряд правок Jc3s5h и JMF , вносящих и удаляющих изменения в Wikipedia:Руководство по стилю/Даты и числа § Распространенные математические символы , поднимают вопросы, которые, по моему мнению, следует обсудить.

1. Последнее изменение, permalink/1247903136 , содержит комментарий Эта страница не охватывает матричные операции. Однако я не вижу в статье ничего, что поддерживало бы ограничение числовыми операциями.
2. Последнее изменение восстанавливает ссылку на скалярное произведение , несмотря на комментарий.
3. Похоже, что существуют разногласия по поводу знака деления.

Вопросы, которые я хотел бы поднять, следующие:

1. Следует ли в этом разделе упомянуть {{ tmath }} или <math>...</math>?
2. Входят ли векторные операции в сферу действия статьи? Независимо от ответа, скалярные и перекрестные произведения следует рассматривать последовательно.
3. Должны ли быть две новые строки для скалярного и векторного произведения?
4. Должна ли быть строка для тензорного произведения ?
5. Является ли обелус бесполезным, поскольку у него есть три формы?
6. Следует ли заменить знак деления ( U+00F7 ÷ ЗНАК ДЕЛЕНИЯ ) на косую черту ( U+002F / SOLIDUS )?
7. Следует ли явно отказаться от U+2215 ∕ DIVISION SLASH в пользу Slash?
8. Следует ли явно отказаться от использования «x» и «*» в качестве знаков умножения в пользу U+00D7 × ЗНАК УМНОЖЕНИЯ ?
9. Должен ли этот раздел показывать разметку L A T E X для символов в дополнение к ссылкам на сущности символов HTML ?

-- Шмуэль (Сеймур Дж.) Мец Имя пользователя: Chatul ( обсуждение ) 10:52, 27 сентября 2024 (UTC) [ ответить ]

1. Я считаю, что эта страница должна быть посвящена общим статьям, а <math> следует зарезервировать для статей по продвинутой математике и естественным наукам.
2. Векторные операции в настоящее время не входят в сферу действия страницы проекта, и я не в восторге от их добавления.
3. Скалярное произведение и перекрестное произведение определенно не должны рассматриваться в той же строке, что и любая скалярная операция. Точка умножения определенно не должна быть связана со статьей "Скалярное произведение", а крест умножения не должен быть связан со статьей "Перекрестное произведение".
4. Продукты Tensor не следует рассматривать на этой странице проекта, поскольку они слишком продвинуты.
7. Я не готов тратить пять минут на то, чтобы понять, что означает эта строка.
8. Звездочку как знак умножения следует использовать только в статьях о компьютерных языках, где она используется в этом качестве.
9. LATEX не следует упоминать, поскольку мы не используем его в Википедии. Это не руководство по стилю для написания за пределами Википедии.

Jc3s5h ( обсуждение ) 19:45, 27 сентября 2024 (UTC) [ ответ ]

Честно говоря, мне было интересно, что этот обширный список делает в MOS в первую очередь. Глоссарий математических символов делает это лучше. Его действительно нужно сократить, чтобы охватить только те символы, которые имеют проблемы со стилем: скалярное деление и умножение.

• Знак деления начальной школы следует официально отменить по причинам, изложенным в знаке деления .
• «Обычную» косую черту (002F) следует предпочесть 2215, та же логика, что и для прямых и фигурных кавычек.
• Я предпочитаю U+00D7 × ЗНАК УМНОЖЕНИЯ вместо x, как для биологии, так и для математики, но, возможно, это требует обсуждения.

𝕁𝕄𝔽 ( обсуждение ) 20:04, 27 сентября 2024 (UTC) [ ответить ]

Комментарии:

• Я не вижу веской причины запрещать использование знака деления для выражения деления. Это кажется абсолютно нормальным. В статье о знаке деления , кажется, говорится, что это может сбивать с толку на итальянском, русском, польском, датском, норвежском или шведском языках, но это английская Википедия. Мы также используем точки в качестве десятичных разделителей , и мы используем запятые в качестве разделителя тысяч , хотя это может сбивать с толку на других языках.
• Я также не вижу веской причины запрещать использование звездочки для умножения; она кажется понятной, простой для набора, недвусмысленной и распространенной на практике. Я согласен с тем, что не следует использовать "x" для умножения, хотя я думаю, что можно выражать отношения "by" для пиломатериалов 2x4, листов фанеры 4x8 и грузовиков 4x4.
• <math>x</math> (т. е. ) выглядит иначе, чем ''x'' (т. е. x ), а они выглядят иначе, чем {{math|''x''}} (т. е. x ), по крайней мере на моем экране, и видеть их смесь в одной статье может быть немного раздражающе (особенно если они расположены рядом друг с другом). ${\displaystyle x}$

—⁠ ⁠ BarrelProof ( обсуждение ) 21:46, 7 октября 2024 (UTC) [ ответить ]

Asterisk означает свертку (что несколько связано с идеей «умножения», но не следует путать с обычным умножением). Его использование в качестве замены «×» или «⋅» — плохая привычка со времен плохой технологии (но она никогда не использовалась как таковая в профессиональном наборе) и в настоящее время не имеет оправдания. — Михаил Рязанов ( обсуждение ) 22:12, 7 октября 2024 (UTC) [ ответить ]

Свертка будет рассматриваться только в очень математически сложных специализированных контекстах. Это не то, с чем большинство людей когда-либо сталкивалось. Даже для тех, кто ее использует, она часто выражается с помощью суммирования или интегрирования . —⁠ ⁠ BarrelProof ( talk ) 22:21, 7 октября 2024 (UTC) [ ответить ]

Я не думаю, что это веская причина делать исключения, чтобы терпеть/продвигать небрежную типографику (более того, в некоторых компьютерных шрифтах звездочка ASCII больше похожа на верхний индекс, чем на бинарный оператор, согласующийся с +, −, = и т. д.).

Я не думаю, что мы должны чувствовать ответственность за то, как Википедия отображается всеми возможными шрифтами. Мы должны помнить, что каждый должен иметь возможность редактировать статьи Википедии. В статье, которая не о математике или, по крайней мере, не использует ее за пределами уровня 10-го класса, f = 1,8 * c + 32 , по сути, нормально описывает преобразование из градусов C в градусы F. Это достаточно сложно, чтобы мы говорили людям обращать внимание на разницу между «-», «–», «—» и «−» и не использовать курсив для чисел в этой формуле, хотя я поддерживаю эти инструкции. —⁠ ⁠ BarrelProof ( обсуждение ) 03:37, 8 октября 2024 (UTC) [ ответ ]

Никто не должен жаловаться на в остальном хорошие правки, которые включают «ленивую» типографику. Эти правки на 100% хороши и являются чистым улучшением для Википедии. Другие редакторы, которым небезразлична типографика и MoS, могут подчистить разметку и выбор символов позже. Википедия — это совместный проект. Indefatigable ( обсуждение ) 15:46, 8 октября 2024 (UTC) [ ответ ]

Использование звездочки для обозначения умножения является синтаксисом языка программирования; я не думаю, что это распространено или хотя бы хорошо известно непрограммистам. isaacl ( обсуждение ) 01:47, 20 октября 2024 (UTC) [ ответ ]

Я согласен, что нам следует препятствовать использованию "*" в качестве символа умножения. Я согласен, что это легко набрать, поэтому если один редактор пишет " y = m * x + c " в в остальном правильной правке, ответом должно быть не отмена этой правки, а замена ее на " y = mx + c " или другую одобренную альтернативу. Dondervogel 2 ( talk ) 10:40, 20 октября 2024 (UTC) [ ответить ]

Использование звездочки для умножения абсолютно известно непрограммистам, поскольку именно она используется на цифровой клавиатуре большинства клавиатур в США. -- Пользователь:Khajidha ( обсуждение ) ( вклад ) 14:28, 12 ноября 2024 (UTC) [ ответ ]

Ах, но что появилось раньше — *ключ или его использование в математических выражениях? Сорок с лишним лет назад меня учили, что в компьютерном коде *символ выбирался, чтобы избежать путаницы с буквой x, поскольку ×не существовало ни в одном из наборов символов, которые использовались в то время — ASCII и EBCDIC. То же самое с /vs. ÷и, конечно же, -vs. −. -- Red rose64 🌹 ( talk ) 18:15, 12 ноября 2024 (UTC) [ reply ]

*появился на многих (но не на всех) ранних пишущих машинках. Если его не было, его часто заменяли дробной клавишей (1/2, 1/4 и т. д.) Практически каждый компьютерный терминал с 1970-х годов имел клавишу , но это, вероятно, связано с тем, что ее использовал Fortran (1957). Ранние клавиатуры телетайпа обычно использовали кодировку Бодо и не имели , но они были больше предназначены для телекоммуникаций, чем для программирования. Fortran был изобретен в IBM и использовал перфокарты/ленту с использованием BCDIC IBM . Ранние вариации BCDIC имели , и , но не . был добавлен вскоре после этого. Я считаю, что BCDIC пытался кодировать все, что обычно использовалось на пишущих машинках, — с учетом ограничения использования только 64 символов. Затем Fortran назначил функциональность всему, что было в этом наборе. выглядело больше всего, не будучи буквой, поэтому он получил эту работу.  Stepho  talk 23:56, 12 ноября 2024 (UTC) [ ответить ]***-/++*x  

Вводящий в заблуждение ярлык

Wikipedia:Manual of Style/Dates and numbers#Commonmath symbols указывает, что его сокращение — «MOS:COMMONMATH», но на самом деле MOS:COMMONMATH ссылается на Wikipedia:Manual of Style#Commonmath symbols (другой раздел на другой странице, хотя частично охватывает ту же тему), где также указано «MOS:COMMONMATH» в качестве сокращения. Возможно, один из них следует переименовать. — Михаил Рязанов ( обсуждение ) 00:47, 7 октября 2024 (UTC) [ ответить ]

@ Михаил Рязанов : Я проследил это до этой правки почти два года назад от SMcCandlish  ( talk  · contribs ), которую я отменил. Два перенаправления MOS:COMMONMATH и WP:COMMONMATH были созданы в один и тот же день в январе 2014 года (хотя с разницей примерно в двадцать часов), первое от BarrelProof  ( talk  · contribs ), а второе от Wavelength  ( talk  · contribs ) после этого обсуждения . Кажется, они были намеренно разными — и остаются такими с тех пор. Если бы одно из них должно было быть перепрофилировано для соответствия другому через десять лет, нам бы понадобился WP:RFD . -- Red rose64 🌹 ( talk ) 09:00, 7 октября 2024 (UTC) [ ответить ]

Должно быть, произошло что-то, что спровоцировало их создание в тот же день, но я не помню этого. —⁠ ⁠ BarrelProof ( обсуждение ) 09:17, 7 октября 2024 (UTC) [ ответить ]

Вы заметили, что на символах есть два раздела MOS, и предложили объединить их, Wavelength ответил, что оба расположения подходят, и вместо этого мы могли бы иметь два ярлыка, и больше никто ничего не сказал. NebY ( обсуждение ) 11:26, 7 октября 2024 (UTC) [ ответ ]

Спасибо за напоминание. Я думаю, что эти два раздела должны хотя бы упомянуть друг друга в примечаниях, если не объединить. Я просто добавил упоминания. Сбивает с толку то, что оба они являются частью MOS и оба являются разделами MOS с одинаковым заголовком: «Общие математические символы». Может быть, они должны стать MOS:COMMONMATH1 и MOS:COMMONMATH2?? Есть ли какой-то способ выразить разницу между целями этих двух? Я заметил, что один из них является частью Wikipedia:Manual of Style/ Dates and numbers, но вообще ничего не говорит о датах и ​​числах, поэтому я предлагаю объединить его с другим. Математика не является синонимом чисел. Этот раздел посвящен выражению операций и отношений и форматированию имен переменных, а не чисел. —⁠ ⁠ BarrelProof ( обсуждение ) 17:50, 7 октября 2024 (UTC) [ ответить ]

Лучше с заметками в шляпе, да. Хотя математика != числа, MOSNUM кажется естественным местом, где читатели могут искать руководство по символам; в конце концов, чем менее мы математически подкованы, тем более вероятно, что мы будем думать об операторах как о вещах, которые мы используем с числами. Я ожидал, что MOSNUM будет более подробным, но в MOS тоже есть дополнительный контент, так что это не полезное различие. Болтливый и формальный? NebY ( talk ) 20:10, 7 октября 2024 (UTC) [ ответить ]

Обычно, когда "MOS: FOO " и "WP: FOO " идут в два разных места, это нормально; причина, по которой у нас есть псевдопространство имен "MOS: FOO " для сокращений MoS, заключается в том, что страницы MoS поглощали слишком много мнемонически значимых строк сокращений, в которых "WP: FOO " для большего количества редакторов вызывало бы в памяти какой-то материал из пространства имен "WP:" не из MoS. Да, используйте примечание о разрешении неоднозначности по мере необходимости; у нас есть они не просто так. Однако в этом случае обе цели — разделы MoS, поэтому обе сокращения должны идти в одно и то же место, предположительно, в более подробный материал. Если материал в Wikipedia:Manual of Style#Common Mathic Symbols — это просто краткое изложение Wikipedia:Manual of Style/Dates and numbers#Common Mathic Symbols (что, вероятно, так и должно быть), то для первого сокращения вообще не требуется.  —  SMcCandlish ☏ ¢  😼  06:04, 8 октября 2024 (UTC) [ ответить ]

Не поощрять постфиксный плюс?

(мотивировано предыдущим разделом) Если есть какая-то работа по объединению/перестановке MOS:COMMONMATH и WP:COMMONMATH , можем ли мы также добавить, что «более N » и «по крайней мере N » должны использовать стандартную нотацию > N и ≥ N соответственно (как, например, указано в CMOS в 3.83 и 12.16) вместо постфиксного плюса ( N + , что неоднозначно, несовместимо с другими случаями, такими как < N и ~ N , и, похоже, не соответствует ни одному авторитетному руководству по стилю)? — Михаил Рязанов ( обсуждение ) Михаил Рязанов ( обсуждение ) 21:29, 7 октября 2024 (UTC) [ ответить ]

Эта проблема часто возникает? E Eng 22:12, 7 октября 2024 (UTC) [ ответить ]

Некоторое время назад я получил откат с наводящим на размышления резюме правок (эта конкретная статья сильно изменилась с тех пор, но я все еще время от времени натыкаюсь на похожие примеры — если нужно, я могу приложить некоторые усилия, чтобы найти конкретные примеры). Кроме того, простой поиск insource:/[0-9]\+ / prefix:: выдает тысячи результатов (до истечения времени ожидания), только небольшая часть из которых является законным использованием (или плохо отформатированными бинарными операциями). — Михаил Рязанов ( обсуждение ) 22:54, 7 октября 2024 (UTC) [ ответить ]

Тогда следующий вопрос: было ли время потрачено впустую на обсуждение этого вопроса по нескольким статьям, или их можно просто исправить на месте без суеты? Если последнее, то новое положение MOS не нужно, и поэтому необходимо, чтобы его не было . E Eng 23:10, 7 октября 2024 (UTC) [ ответить ]

Цифры в последовательности

«Фаза 1» или «Фаза один»? Похоже, это случай, который явно не охвачен.

В разделе «Числа» книги стилей AP рекомендуется использовать цифры для последовательностей: «Также используйте цифры во всех табличных материалах, а также в статистических и последовательных формах», из чего я делаю вывод, что для последовательностей, таких как «фаза 1», цифры следует использовать для ясности и последовательности.

Аналогично, глава 9 «Чикагского руководства по стилю» рекомендует использовать цифры при обозначении последовательности.

Я предлагаю добавить аналогичные четкие рекомендации в этот раздел MOS.

-- Jmc ( обсуждение ) 20:10, 19 октября 2024 (UTC) [ ответить ]

• Как обычно, прежде чем что-то добавлять в MOS, необходимо привести примеры того, что это проблема в нескольких статьях — см. WP:MOSBLOAT . Неужели редакторы не могут сами разобраться с этим в отдельных статьях? В любом случае, почему слово «Фаза» нуждается в этом? Почему не «Раздел» и «Часть» и любые другие подобные слова?
  Советы от APA и CMS великолепны, если вы создаете новую последовательность для своей диссертации, но это не про нас. Трудно представить себе статью, использующую фразу типа «Фаза 1» или «Фаза один» сама по себе — то есть, кроме как в подражании формулировкам источников. Так что следуйте источникам; например, Закон об экономической стабилизации 1970 года ссылается на Фазу I , Фазу II и Фазу III , потому что это форма, используемая в Законе. Мы не собираемся отменять это во имя согласованности с другими, не связанными статьями. E Eng 22:00, 19 октября 2024 (UTC) [ ответить ]

  Для ясности: я использую «Фазу» исключительно в качестве примера. Проблема использования цифр для последовательностей касается любой последовательности, включая «Раздел» и «Часть» — и другие примеры: «Игра 3» последовательности из девяти; «Глава 9» последовательности из 24; «Неделя 4» неограниченной последовательности.

  Я поднимаю этот вопрос в контексте различных редакционных практик в статье о скандале в British Post Office , где и цифры, и слова использовались для обозначения одних и тех же фаз и недель расследования. Я запросил указания у MOS, но не нашел.

  Я бы с удовольствием следовал источникам, не усложняя MOS, если бы был уверен, что в данном случае это общепринятая стилистическая традиция. -- Jmc ( обсуждение ) 22:27, 19 октября 2024 (UTC) [ ответить ]

  Такие названия очень часто устанавливаются авторитетными источниками и представляют собой собственные имена; мы должны следовать источникам, а не переименовывать их. Согласно EEng, нам нужно руководство MOS только в том случае, если наши источники не предоставляют четких названий, и либо есть разногласия среди редакторов, либо согласованность между статьями была бы существенной пользой. В случае с почтовым отделением я вижу, что фазы были названы расследованием как Фаза 1, Фаза 2 и т. д. [1], поэтому, если расследование не является противоречивым, мы можем следовать этому источнику. Тем не менее, я вижу, что это живая проблема в той скандальной статье о британском почтовом отделении , поэтому было бы неправильно устанавливать новое руководство или выпускать какое-то постановление на странице обсуждения MOS без ведома другого редактора; пинг MapReader . NebY ( обсуждение ) 14:56, 20 октября 2024 (UTC) [ ответ ]

  В период с мая 1966 года по декабрь 1989 года истории о Докторе Кто, состоящие из нескольких эпизодов, могли иметь названия в любой из четырех комбинаций: (i) «Эпизод ...» или «Часть ...»; (ii) цифры в виде цифр или слов. Решение о том, какой формат использовать, вероятно, принимал продюсер сериала, но в наших статьях о каждой истории мы даем фактическое название, показанное на экране, за исключением случаев, когда название на экране полностью заглавное, мы сокращаем его до заглавных букв. Некоторые справочники по Доктору Кто делают то же самое, поэтому мы следуем источникам. -- Red rose64 🌹 ( talk ) 18:18, 20 октября 2024 (UTC) [ ответить ]

  Поднятый вопрос был о «различных редакционных практиках в статье о скандале в британском почтовом отделении». Похоже, это вопрос внутренней согласованности, что не так. Для всего остального — это, по моему скромному мнению, — нам, возможно, не нужна согласованность между статьями, но внутри статей это выглядит плохо. Но ведь у нас уже есть правило, решающее эту общую проблему? Herostratus ( обсуждение ) 13:24, 21 октября 2024 (UTC) [ ответить ]

  Я думаю, что нет. В статьях о сериалах часто встречаются выражения вроде «сезон 3» и «эпизод 7», которые, кажется, противоречат нашей текущей формулировке (используйте слова для чисел ниже 10). Gawaon ( обсуждение ) 16:37, 21 октября 2024 (UTC) [ ответить ]

  Это действительно вопрос внутренней согласованности, и это выглядит плохо, как говорит Герострат . В рамках одной статьи ( скандал в British Post Office ) у нас есть (например) и «слушания по фазе 3», и «фазы пять и шесть». Существует ли на самом деле правило, касающееся этой общей проблемы? -- Jmc ( обсуждение ) 18:47, 21 октября 2024 (UTC) [ ответить ]

  Из Википедии:Руководство по стилю/Даты и числа#Числа в виде цифр или слов : "Сравнимые значения, расположенные рядом друг с другом, должны быть все прописаны или все цифрами, даже если одно из чисел обычно пишется по-другому". Если только вы не имеете дело только с сериалами, в которых менее 10 сезонов и менее 10 эпизодов в каждом, то MOS больше соответствует указанию всех номеров сезонов и эпизодов цифрами, а не словами. -- Пользователь:Khajidha ( обсуждение ) ( вклад ) 13:15, 22 октября 2024 (UTC) [ ответить ]

  Это правда, но сериалы с количеством сезонов менее десяти не так уж редки, и есть также мини-сериалы с количеством серий менее десяти. Gawaon ( обсуждение ) 16:39, 22 октября 2024 (UTC) [ ответить ]

  Независимо от того, соответствует ли это MOSNUM, мы часто — я подозреваю, что в подавляющем большинстве случаев — даем номера серий/сезонов и эпизодов цифрами. Я копался в Wikipedia:Good articles/Media and drama#Television . Статьи об отдельных эпизодах обычно начинаются, например, с «девятый и последний эпизод первого сезона», но с цифр в информационном поле. Статьи о сезоне/сериале перечисляют эпизоды с помощью цифр, а статьи о шоу перечисляют сериалы/сезоны и эпизоды с цифрами, независимо от того, больше их или меньше десяти, в соответствии с примерами в Wikipedia:Manual of Style/Television#Episode listing . Статьи часто озаглавлены <show> season <n>, где n — это цифра, а не слово, в соответствии с Wikipedia:Naming conventions (television)#Season articles . Взяв за образец наш WP:Избранные статьи#Медиа , я вижу тот же подход в заголовках, информационных блоках и списках.

  Я очень сомневаюсь, что редакторы примут изменения в этих FA и GA, чтобы привести их в соответствие с MOS:NUMERAL , что оценщики FA и GA начнут применять MOS:NUMERAL в таких случаях, что любые запросы на перемещение будут успешными или что MOS:TV и WP:TVSEASON будут приведены в соответствие с текущим MOS:NUMERAL . Изменить MOS:NUMERAL может быть проще. NebY ( talk ) 08:20, 23 октября 2024 (UTC) [ ответить ]

  Согласен, небольшое дополнение к MOS:NUMERAL может быть хорошей вещью. Gawaon ( talk ) 17:00, 23 октября 2024 (UTC) [ ответить ]

  Ваше последнее предложение не следует из вашего заявления. Было бы более в соответствии с MOS дать все словами. MapReader ( talk ) 11:16, 23 октября 2024 (UTC) [ ответить ]

мкс против нас

Какой стиль мне использовать для микросекунд? Относится ли μs ​​к "Не использовать символы предкомпозитных единиц"? DungeonLords ( обсуждение ) 04:44, 30 октября 2024 (UTC) [ ответить ]

Два символа "μ" и "s" вполне хороши. Совет по предварительно составленным символам — остерегаться определенных шрифтов, которые объединяют их в один символ, поскольку многие программные считыватели для людей с нарушениями зрения не знают все эти символы.  Stepho   talk  04:53, 30 октября 2024 (UTC) [ ответить ]

Формат дня, даты, месяца

Приветствия и поздравления. Я предполагаю, что такие конструкции, как «Среда, 24 февраля» не приветствуются, но я не могу найти их в тексте или архивах этой страницы. (Запятая кажется мне излишней.) Могу ли я получить подтверждение или опровержение? — DocWatson42 ( обсуждение ) 04:28, 4 ноября 2024 (UTC) [ ответить ]

• MOS:DATEFORMAT и MOS:BADDATE охватывают разрешенные и запрещенные форматы. Если день недели не имеет решающего значения, мы его опускаем.  Stepho   talk  06:16, 4 ноября 2024 (UTC) [ ответить ]

  Это особенно касается статьи « Хадака Мацури » и ее инфобокса Konomiya Hadaka Matsuri, который включает дни недели. — DocWatson42 ( обсуждение ) 07:40, 4 ноября 2024 (UTC) [ ответить ]

  Ах, таинственный Восток. E Eng 08:06, 4 ноября 2024 (UTC) [ ответить ]

• Приветствую, обнимаю и целую тебя тоже.
  • Если ваш вопрос заключается в том, следует ли включать день недели в даты без особой причины, ответ — « Нет» . То есть, если день недели каким-то образом имеет отношение к повествованию, конечно, включайте его, но в противном случае — нет.
  • Предположим, что мы находимся в ситуации, когда (согласно предыдущему) включение дня недели действительно оправдано, тогда, возможно, ваш вопрос заключается в том, как добавить DOW
    • Если дата 24 февраля или 24 февраля 2024 года , то, без сомнений, правильный формат — среда, 24 февраля или среда, 24 февраля 2024 года .
    • Согласно «Elite editing» [2] (кем бы они ни были — найдите текст «inverted style» на этой странице), соответствующие ответы для 24 февраля и 24 февраля 2024 года — это среда, 24 февраля и среда, 24 февраля 2024 года . Мне это кажется правильным — среда, 24 февраля 2024 года (все вместе, без запятых) кажется недопустимым.

Возникает естественный вопрос, следует ли MOS давать советы по всем вышеперечисленным вопросам. Мой ответ, как обычно, предварительно Нет , согласно WP:MOSBLOAT . E Eng 08:02, 4 ноября 2024 (UTC) [ ответить ]

Если посмотреть на статью, то дата — 12-й день китайского года, а день недели не имеет значения. Я бы убрал день недели из всех этих дат в инфобоксе. Если это имеет значение, то большую часть 1990-х я провел в Гонконге/Китае. Основные праздники, основанные на китайском календаре, относятся к дню недели так же, как мы относимся к дню, на который приходится Рождество.  Stepho   talk  09:18, 4 ноября 2024 (UTC) [ ответить ]

Хорошо, сделаю. Спасибо вам обоим. ^_^ — DocWatson42 ( обсуждение ) 09:21, 4 ноября 2024 (UTC) [ ответить ]

Новое 18-е издание The Chicago Manual of Style дает советы о запятых в датах в ¶ 6.14. Приводя примеры, они в основном приводят примеры со словами после окончания даты, чтобы проиллюстрировать пунктуацию в конце даты. Некоторые примеры:

• Слушание было назначено на 14:30 в пятницу, 9 августа 2024 года.
• Понедельник, 5 мая, был выходным днем; вторник, 6 мая, — нет.

Jc3s5h ( обсуждение ) 16:56, 4 ноября 2024 (UTC) [ ответ ]

Интервал с процентными пунктами

Вопрос относительно интервала использования процентного пункта (pp). Я всегда предполагал, что между числом и pp нет пробела (например, 5,5pp, а не 5,5 pp), на том основании, что вы не ставите пробел между числом и знаком процента (5% а не 5 %). В MOS об этом нет ссылки, но статья о процентном пункте использует его без пробела. Было бы неплохо прояснить это в MOS, поскольку я вижу регулярные изменения, добавляющие пробел, что я не уверен, правильно. Ура, Номер 5 7 23:49, 5 ноября 2024 (UTC) [ ответить ]

• MOS:PERCENT говорит "пропустить пробел".  Stepho   talk  23:54, 5 ноября 2024 (UTC) [ ответить ]

  Возможно, я что-то упускаю, но, насколько я вижу, там говорится о необходимости пропускать пробел при использовании символа процента (%), но ничего не говорится о том, что делать при использовании pp? Номер 5 7 00:21, 6 ноября 2024 (UTC) [ ответить ]

  Извините, я пропустил слово «точка» в вашем вопросе.  Stepho   talk  01:49, 6 ноября 2024 (UTC) [ ответить ]

• % по сути является постоянным множителем (.01), но pp больше похоже на единицу, поэтому моя интуиция подсказывает, что он должен быть с пробелом. Я заметил, что в статье о базисной точке используется пробел перед bp (в основном, во всяком случае). Мне будет интересно услышать, что думают другие. E Eng 18:23, 6 ноября 2024 (UTC) [ ответить ]

  У вас все наоборот. Процент (%) — это стандартный символ единицы измерения, и его следует ставить с пробелом, тогда как pp — это выдуманное сокращение, то есть вы можете поставить его где угодно, с пробелом или без него. Я знаю, что MOSNUM утверждает обратное, и это прерогатива WP. Другими словами, если нам нужно правило, давайте его придумаем и применим, но в этом нет никакой логики. Dondervogel 2 ( talk ) 21:06, 6 ноября 2024 (UTC) [ ответить ]

• Dondervogel, "Процент (%) — это стандартный символ единицы измерения, и его следует расставлять пробелами". А? Это ведь не символ единицы измерения ISO, не так ли? В английском языке пробелов нет, в отличие от французского. По поводу pp я согласен с EEng: расставляйте пробелы. Тони (обс.) 11:10, 8 ноября 2024 (UTC) [ ответить ]

  Конечно. Когда дело доходит до пипи, всегда делайте пробел [3]. E Eng 21:36, 8 ноября 2024 (UTC) [ ответить ]

  Да, «%» — это стандартный символ единицы измерения ISO. Dondervogel 2 ( обсуждение ) 12:45, 8 ноября 2024 (UTC) [ ответить ]

  Что это за единица измерения? Gawaon ( обсуждение ) 13:14, 8 ноября 2024 (UTC) [ ответить ]

  Ничего. Это безразмерная величина . К исходному вопросу: Я не вижу, чтобы "pp" часто использовалось, на самом деле редко. Вероятно, лучше записать его полностью при первом использовании, а если будут последующие использования, следуйте указаниям в MOS:ACRO1STUSE . -- Red rose64 🌹 ( talk ) 19:58, 8 ноября 2024 (UTC) [ ответить ]

  Он широко используется в информационных окнах выборов, где нет места для его записи. Номер 5 7 22:25, 8 ноября 2024 (UTC) [ ответить ]

  Я отвечу на обоснованный вопрос Гаваона в двух частях. Первая часть — цитата из ISO 80000-1:2009 (выделено мной)

  • В некоторых случаях в качестве дольной единицы единицы используется процент, символ %, где 1 % := 0,01.
  • ПРИМЕР 4
  • коэффициент отражения, r = 83 % = 0,83
  • Также промилле (или промилле), символ ‰, где 1 ‰ := 0,001, используется как дольная единица когерентной единицы один. Поскольку единицы «процент» и «промилле» являются числами, бессмысленно говорить, например, о процентах по массе или процентах по объему. Поэтому дополнительная информация, такая как % (м/м) или % (об/об), не должна присоединяться к символу единицы % . См. также 7.2. Предпочтительный способ выражения, например, массовой доли — «массовая доля B составляет w B = 0,78» или «массовая доля B составляет w B = 78 %». Кроме того, термин «процент» не должен использоваться в названии величины, поскольку он вводит в заблуждение. Если массовая доля составляет 0,78 = 78 %, то является ли процент 78 или 78 % = 0,78? Вместо этого следует использовать однозначный термин «фракция». Массовые и объемные фракции также могут быть выражены в таких единицах, как мкг/г = 10-6 или мл/м3 = 10-9.

  Обратите внимание на преднамеренный пробел между числовым значением (например, 83) и символом единицы измерения (%). Dondervogel 2 ( обсуждение ) 22:10, 8 ноября 2024 (UTC) [ ответить ]

  Вторая часть представляет собой частичное опровержение, цитирующее стандарт ISO 80000-1:2022, который заменяет документ 2009 года:

  • Если величина, которую необходимо выразить, представляет собой сумму или разность величин, то либо следует использовать скобки для объединения числовых значений, помещая общий символ единицы после полного числового значения, либо выражение следует записать в виде суммы или разности выражений для величин.
  • ПРИМЕР 1
  • l = 12 м - 7 м = (12 - 7) м = 5 м, а не 12 - 7 м
  • U = 230 ⋅ (1 + 5 %) V = 230 ⋅ 1,05 В ≈ 242 В, а не U = 230 В + 5 %

  Пробел между числовым значением (5) и символом процента (%) все еще есть, но я не смог найти явную ссылку на "%" как символ единицы. Я не уверен, как интерпретировать это изменение, но я сообщу здесь, если найду дополнительные разъяснения. Dondervogel 2 ( talk ) 22:16, 8 ноября 2024 (UTC) [ ответить ]

  Я нашел это в Специальной публикации NIST 811

  • В соответствии с [4: ISO 31-0] данное Руководство занимает позицию, что приемлемо использовать международно признанный символ % (процент) для числа 0,01 с СИ и, таким образом, выражать значения величин размерности один (см. Раздел 7.14) с его помощью. При его использовании между символом % и числом, на которое он умножается, оставляется пробел [4: ISO 31-0]. Кроме того, в соответствии с Разделом 7.6 следует использовать символ %, а не название «процент».
  • Пример: xB = 0,0025 = 0,25 %, но не: xB = 0,0025 = 0,25% или xB = 0,25 процента
  • Примечание: xB — символ количества вещества B (см. раздел 8.6.2).
  • Поскольку символ % представляет собой просто число, нет смысла прикреплять к нему информацию (см. раздел 7.4). Поэтому следует избегать использования таких фраз, как «процент по весу», «процент по массе», «процент по объему» или «процент по количеству вещества». Аналогично следует избегать написания, например, «% (м/м)», «% (по весу)», «% (об./об.)», «% (по объему)» или «% (моль/моль)». Предпочтительными формами являются «массовая доля составляет 0,10» или «массовая доля составляет 10 %» или «wB = 0,10» или «wB = 10 %» (wB — это символ количества для массовой доли B — см. раздел 8.6.10); "объемная доля составляет 0,35" или "объемная доля составляет 35 %" или "φB = 0,35" или "φB = 35 %" (φB — это символ количества для объемной доли B — см. раздел 8.6.6); и "доля количества вещества составляет 0,15" или "доля количества вещества составляет 15 %" или "xB = 0,15" или "xB = 15 %. Массовая доля, объемная доля и доля количества вещества B также могут быть выражены, как в следующих примерах: wB = 3 г/кг; φB = 6,7 мл/л; xB = 185 ммоль/моль. Такие формы настоятельно рекомендуются (см. также раздел 7.10.3).
  • В том же духе, поскольку символ % представляет собой просто число 0,01, неправильно писать, например, «где сопротивления R1 и R2 отличаются на 0,05 %» или «где сопротивление R1 превышает сопротивление R2 на 0,05 %. Вместо этого следует писать, например, «где R1 = R2 (1 + 0,05 %)» или определять величину Δ через соотношение Δ = (R1 - R2) / R2 и писать «где Δ = 0,05 %». В качестве альтернативы, в некоторых случаях, можно использовать слова «дробный» или «относительный». Например, было бы приемлемо написать «дробное увеличение сопротивления эталонного образца 10 кОм в 2006 году составило 0,002 %.»

  Как и в случае с ISO 80000-1:2022, между числовым значением (например, 35) и символом процента (%) всегда есть пробел, но нет упоминания % как символа единицы. Dondervogel 2 ( talk ) 22:38, 8 ноября 2024 (UTC) [ ответить ]

  Между числовым значением (например, 35) и символом процента (%) всегда есть пробел  – возможно, в мире NIST, но не здесь, в Википедии (см. MOS:PERCENT ), поэтому я не вижу, как что-либо из этого может помочь нам в решении рассматриваемой проблемы. E Eng 23:29, 8 ноября 2024 (UTC) [ ответить ]

  Я исправлял ошибочное представление о том, что % не является символом единицы измерения, хотя это так. По крайней мере, так было до 2022 года. Я считаю, что лучше не оставлять неверные утверждения без ответа, иначе они начнут жить своей собственной жизнью. Dondervogel 2 ( talk ) 00:24, 9 ноября 2024 (UTC) [ ответить ]

  Хм, хорошо, но вы же понимаете, что WP не следует рекомендациям NIST по поводу интервалов, да? E Eng 00:44, 9 ноября 2024 (UTC) [ ответить ]

  Да, и я не пытался это изменить. Мой вклад был в

  • исправить фактическую ошибку (вашу)
  • ответить на вопросы Тони и Гаваона

  Я не высказался по основной теме относительно процентных пунктов, потому что не ожидаю, что мое мнение (основанное не на высказываниях NIST, а на стандартах ISO, на которых они основаны) будет воспринято всерьез, так зачем мне тратить свое электронное дыхание? Dondervogel 2 ( обсуждение ) 09:41, 9 ноября 2024 (UTC) [ ответить ]

UNITSYMBOLS (1 × 3 × 6 м): «за каждым числом должно следовать название или символ единицы измерения»

MOS:UNITSYMBOLS в настоящее время требует символ единицы измерения после каждого значения при перечислении размеров, разделенных знаком × (« 1 м × 3 м × 6 м , а не 1 × 3 × 6 м »). Можем ли мы сделать исключение из этого правила и разрешить редакторам использовать только конечную единицу при написании для информационных полей и, возможно, других мест, где пространство ограничено?

Контекст: {{ Infobox mobile phone }} в настоящее время имеет предпочтение перечислять размеры продукта на отдельной строке. Этот и другие параметры могут сделать инфобокс очень длинным. Это особенно проблематично для страниц, которые охватывают несколько продуктов или версий продукта; см. размеры в инфобоксе Samsung Galaxy S21 . Чтобы сократить эти инфобоксы, мы могли бы использовать одну строку для всех трех размеров, но единица после каждого значения кажется излишней и может привести к переполнению строки.

Предыдущее обсуждение: обсуждение в Википедии: Руководство по стилю/Даты и числа/Архив 145#Повторяющиеся единицы в диапазонах и измерениях , где была указана возможность путаницы с фактическим умножением значений. Я думаю, что это незначительная проблема в целом, но ее стоит учитывать в прозе или в контекстах, где значения могут быть неоднозначными. —  HTGS  ( обсуждение ) 04:17, 11 ноября 2024 (UTC) [ ответить ]

Если пространство ограничено, имеет смысл представить одну составную единицу, равную произведению отдельных единиц. Для приведенного примера символ составной единицы будет m ³ . Dondervogel 2 ( talk ) 12:13, 11 ноября 2024 (UTC) [ ответить ]

Кто-нибудь слышал о телефоне, рекламируемом как 5 cc? Людям больше интересно, чтобы он был широким и высоким, но очень тонким. Это требует указания каждого отдельного размера.  Stepho   talk  22:40, 11 ноября 2024 (UTC) [ ответить ]

Нет, Двогель имеет в виду, что вы бы написали, что некий телефон имеет размеры 146 x 71,5 x 7,65 мм ³ . Уточнив это, я должен сказать, что это, конечно, смутит 99% наших читателей. E Eng 22:47, 11 ноября 2024 (UTC) [ ответить ]

Попался. Помимо того, что это сбивает с толку большинство читателей, это также отличается от 1 на 3 на 6 м , что разрешено.  Stepho  talk 23:30, 11 ноября 2024 (UTC) [ ответить ]  

Чтобы было понятно тем, кто играет дома, в то время как канонические формулировки — 1 м на 3 м на 6 м и 1 м x 3 м x 6 м , MOS в настоящее время делает исключение, разрешая 1 на 3 на 6 м (особенно в случае, когда все величины указаны в одной и той же единице — в данном случае метры), но не соответствующего исключения, разрешающего 1 x 3 x 6 м . Хотя это может оскорбить пуристов, я действительно не вижу, почему исключение не должно быть распространено и на этот последний случай. Мысли? E Eng 23:39, 11 ноября 2024 (UTC) [ ответить ]

Спасибо, что прояснили мои намерения. И заставили меня посмеяться. Ха-ха.

Для трехмерного объекта можно написать либо 146 мм x 71,5 мм x 7,65 мм, либо 146 x 71,5 x 7,65 мм ³ . Я согласен, что первый вариант понятнее, но последний занимает меньше места, что может быть предметом рассмотрения. Разницы в значении нет.

Думаю, можно было бы написать и 146 x 71,5 x 7,65 мм, но тогда у нас будет длина, а не объем. Было бы понятнее записать эту длину как 79,86 м. Dondervogel 2 ( talk ) 23:42, 11 ноября 2024 (UTC) [ ответить ]

можно также написать 146 x 71,5 x 7,65 мм , но тогда у нас будет длина, а не объем  — формально, возможно, но вы могли бы сказать почти то же самое о 146 на 71,5 на 7,65 мм , и все же мы это допускаем. Никто не подумает, что 146 x 71,5 x 7,65 мм означает длину 79,86  м (т.е. 79860  мм). В контексте читатели поймут это таким, как оно есть. Я хотел бы услышать, что другие думают о моем предложении. E Eng 23:56, 11 ноября 2024 (UTC) [ ответить ]