Обсуждение пользователя:Tonyproctor

Турбулентность, окружающая использование и реализацию процедур NaN, была для меня также чумой. В статье о плавающей точке я попытался обсудить использование специальных кодировок, но это встретило неодобрение. С плавающей точкой арифметики, а также специального значения нуля, я хотел бы иметь +-underflow, +-overflow, +-infinity и по крайней мере одну форму ? с операциями, выполняемыми "аппаратно", а не программно или прерываниями и т. д. Обратите внимание, что есть всего восемь специальных значений. Поскольку в текущем "стандарте" доступно большое количество битов (расточительно, я думаю), есть возможности для организации, которые умоляют. Почему бы не использовать их? Мне бы хотелось схему, в которой были бы отдельные биты для sqrt(-1), log(-1), нескольких известных случаев, а также бит для общего беспорядка, идея в том, что окончательный плохой результат будет иметь некоторый след относительно того, как было разработано плохое состояние, и (x op y) будет "или" эти биты. Поскольку есть много бит, помимо "системных битов" может также быть отложенный набор "пользовательских битов" - я использовал набор состояний ошибок f, u, b, r, o, m (значения могут быть объяснены) с ? для комбинаций (f + f = f; f + <not f> = ? и т. д.), все сделано с помощью вспомогательных данных и программного обеспечения. В этом случае правила распространения состояний ошибок могут быть ясными и явными, поскольку они выполняются моим собственным кодом.

Средства для игры с такого рода идеями потребовали бы разработки и согласования дальнейших расширений текущих схем NaN, которые остаются частичными, нестабильными и полустандартными, поэтому мало надежды на что-то связное. Мы застряли со вспомогательным программным обеспечением. Одна попытка использования NaN вызвала странное поведение в отладочном выводе (это было похоже на ошибку компилятора, хо-хм), поэтому, хотя желаемые вычисления, казалось, вели себя так, как хотелось, и выполнялись с приятным сокращением времени, уверенность была разрушена, и эксперимент был отменен из-за давления других дел. Поэтому я вернулся к использованию определенного значения с плавающей точкой, как вы описываете. В моем случае -666.666E33 было привлекательным, поскольку было маловероятно, что эта конкретная и точная битовая комбинация когда-либо будет разработана в каком-либо вероятном вычислении. Мне бы понравилось -666.666E666, но, увы, это выходит за рамки. NickyMcLean ( обсуждение ) 20:59, 8 апреля 2009 (UTC) [ ответ ]

Наши впечатления похожи, NickyMcLean . Насколько я понимаю, кодировки NaN были разработаны для поддержки состояний, определяемых приложением, но кто-то, работающий над стандартом IEEE, не оценил необходимые требования к стабильности и переносимости. Как оказалось, способ, которым логика NaN реализована во многих архитектурах RISC, делает их бесполезными с точки зрения производительности. Я работал над большим продуктом OLAP и мне пришлось отменить все наши зависимости NaN, когда мы заметили штрафы на растущем количестве систем. TonyP (обсуждение) 15:07, 17 ноября 2018 (UTC) [ ответить ]

Отказавшись от использования состояния NaN (как подтвердил начальник, лучше быть правильным, чем быстрым), я позже попробовал снова, когда не так торопился, и на этот раз обнаружил, что тест, такой как , x ¬= yкомпилировался так, как будто это было ¬(x = y)вместо этого. Но (x = x)возвращает false, если x является состоянием NaN, если выполняется, но такое выражение является истинным, если анализируется компилятором - или мной. Таким образом, некоторые путаницы были уменьшены. Вторая, гораздо более осторожная попытка использовать NaN вместо специальных значений, обнаруженных явным кодом, сработала должным образом и дала прирост скорости - хотя осторожность, необходимая при осторожном использовании функций NaN, потребовала дополнительного времени на разработку и тестирование, которое может не окупиться при более быстром запуске в течение довольно долгого времени. Различия в значении между наличием значения, или значением, которое равно нулю, или которое является NaN, или вообще не имеет данных, могут потребовать разного подхода в разных контекстах, и я обнаружил, что у меня все еще есть возможность скорректировать поведение, когда рассматривается реальный пример. Наличие вспомогательной информации для данных (например, кодов f,u,b,r,o,m для одного из приложений, упомянутых выше) для прояснения контекста помогло бы, но это также означает еще большую сложность в обработке. Разработка кодекса практики, который будет работать для разнородных приложений, будет проблемой, а затем возникнет необходимость в допуске кода в языковую спецификацию, за которой последуют соответствующие корректировки компиляторов, что приведет к тому, что счастливые пользователи будут использовать схему в успешных проектах. Хм... NickyMcLean ( talk ) 07:07, 21 ноября 2018 (UTC) [ ответить ]

Прошло уже некоторое время с тех пор, как я работал над этим, NickyMcLean , но я помню, что значения NaN нельзя было сравнивать друг с другом, если они сначала не были приведены к целочисленным (или длинным целым) значениям — в этом случае вы затем сравнивали их битовые шаблоны. Даже если два NaN имеют одинаковую битовую комбинацию, то они считаются не одинаковыми, поскольку они не упорядочены относительно действительных значений и могут представлять разные условия. Например, sqrt(-1) и log(-1) могут оба генерировать одно и то же NaN, но это не значит, что условия, которые их генерировали, были одинаковыми. Продукт БД, архитектором которого я был, использовал значения NaN для Null (например, 0/0 и т. д.), неинициализированного (что было сигналом) и недоступности данных. Мы также использовали бесконечности. Мы определили правила для того, как они распространяются, и все выглядело отлично, пока мы не обнаружили несколько серьезных провалов производительности (наш продукт работал на многих типах оборудования, под VMS, Windows, IBM mainframe O/S и многих вариациях UNIX, а некоторые, такие как VAX, не поддерживали NaN). Затем нам пришлось принять ужасный «план Б», используя особенно высокие значения, которые вряд ли можно было увидеть в обычных данных. Это был беспорядок! TonyP (обсуждение) 10:49, 21 ноября 2018 (UTC) [ ответить ]

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

Если вы считаете, что эта страница не должна быть удалена по этой причине, вы можете оспорить номинацию , посетив страницу и нажав кнопку с надписью «Оспорить это быстрое удаление». Это даст вам возможность объяснить, почему вы считаете, что страница не должна быть удалена. Однако имейте в виду, что как только страница помечена как требующая быстрого удаления, она может быть удалена без задержки. Пожалуйста, не удаляйте тег быстрого удаления со страницы самостоятельно, но не стесняйтесь добавлять информацию в соответствии с политикой и рекомендациями Википедии . Если страница удалена, и вы хотите восстановить удаленный материал для будущего использования или улучшения, то, пожалуйста, свяжитесь с администратором удаления . Daiyusha ( обсуждение ) 12:53, 25 января 2019 (UTC) [ ответить ]

Здравствуйте, Tonyproctor. Мы приветствуем ваши вклады, но если у вас есть внешние отношения с людьми, местами или вещами, о которых вы написали на странице FHISO, у вас может быть конфликт интересов (COI). Редакторы с конфликтом интересов могут быть неправомерно подвержены влиянию своей связи с темой. См. руководство по конфликту интересов и часто задаваемые вопросы для организаций для получения дополнительной информации. Мы просим вас:

• избегайте редактирования или создания статей о себе, своей семье, друзьях, компании, организации или конкурентах;
• предложить изменения на страницах обсуждения затронутых статей (см. шаблон {{ request edit }} );
• раскрывать свой конфликт интересов при обсуждении затронутых статей (см. WP:DISCLOSE );
• избегайте ссылок на веб-сайт вашей организации в других статьях (см. WP:SPAM );
• сделайте все возможное , чтобы соблюдать политику Википедии в отношении контента .

Кроме того, вы должны раскрыть информацию о своем работодателе, клиенте и аффилированности в отношении любого вклада, который составляет всю или часть работы, за которую вы получаете или ожидаете получить компенсацию (см. WP:PAID ).

Также обратите внимание, что редактирование в целях рекламы, популяризации или продвижения кого-либо или чего-либо не допускается. Я вижу, что вы упомянули себя как члена FHISO, вам следует также объявить COI, если вы редактируете что-либо, связанное с этим. Daiyusha ( talk ) 12:55, 25 января 2019 (UTC) [ ответить ]

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

Статья будет обсуждаться на Wikipedia:Статьи для удаления/Holos (программное обеспечение) до тех пор, пока не будет достигнут консенсус, и любой, включая вас, может принять участие в обсуждении. Номинация объяснит политику и руководящие принципы, которые вызывают беспокойство. Обсуждение сосредоточено на высококачественных доказательствах и наших политиках и руководящих принципах.

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

UtherSRG (обсуждение) 13:18, 7 августа 2023 (UTC) [ ответить ]