Questions tagged «math»

比较浮点值是否相等时，有两种不同的方法： NaN不等于自身，这符合IEEE 754规范。 NaN等于自身，这提供了自反性的数学属性，这对于定义等价关系至关重要 在C＃（内置的IEEE浮点类型float和double）遵循IEEE语义==和!=（和关系运算符一样<），但确保反思object.Equals，IEquatable<T>.Equals（和CompareTo）。 现在考虑一个在float/ 之上提供矢量结构的库double。这样的向量类型将重载==/ !=并覆盖object.Equals/ IEquatable<T>.Equals。 大家都同意==/ !=应该遵循IEEE语义。问题是，这样的库是否应该以Equals自反的方式或与IEEE语义相匹配的方式来实现该方法（与相等运算符分开）。 将IEEE语义用于Equals以下方面的参数： 遵循IEEE 754 （可能更快），因为它可以利用SIMD指令 我已经在stackoverflow上问了一个独立的问题，关于如何使用SIMD指令表达自反式相等性及其性能影响：用于浮点相等性比较的SIMD指令 更新：似乎可以使用三个SIMD指令有效地实现自反性相等。 Equals涉及浮点的文档不需要反射： 对于Equals（Object）方法的所有实现，以下语句必须为true。在列表中x，y和z代表对象引用不为空。 x.Equals(x)返回true，除非涉及浮点类型。参见ISO / IEC / IEEE 60559：2011，信息技术-微处理器系统-浮点运算。 如果您将浮点数用作字典键，那么您将生活在一种罪过的状态中，不应期望表现出理智的行为。 自反的观点： 这是与现有的类型，包括一致的Single，Double，Tuple和System.Numerics.Complex。 我不知道BCL中Equals遵循IEEE而不是反身的任何先例。相反的例子包括Single，Double，Tuple和System.Numerics.Complex。 Equals主要用于依赖自反性的容器和搜索算法。对于这些算法，如果阻止它们工作，则性能提升是无关紧要的。不要牺牲性能的正确性。 它打破了所有基于散列集和词典，Contains，Find，IndexOf各种收藏品/ LINQ，一套基于LINQ操作（Union，Except，等），如果数据中包含NaN的值。 在IEEE语义可接受的情况下执行实际计算的代码通常适用于具体类型并使用==/ !=（或更可能是epsilon比较）。 您目前无法使用泛型编写高性能的计算，因为您需要为此进行算术运算，但是这些不能通过接口/虚拟方法使用。 因此，较慢的Equals方法不会影响大多数高性能代码。 对于需要IEEE语义或需要提高性能的情况，可以提供一种IeeeEquals方法或一种方法IeeeEqualityComparer<T>。 我认为这些论点强烈支持反身执行。 微软的CoreFX团队计划在.NET中引入这种向量类型。与我不同，他们更喜欢IEEE解决方案，主要是因为性能方面的优势。由于这样的决定在最终发布后肯定不会改变，因此我想从社区中获得我认为是一个大错误的反馈。

9 c#  .net  math  floating-point 

我目前正在阅读John Gustafson（Youtube）的“错误的终结-统一计算” 。我仍然不确定如何用unums 处理在IEEE中由负号零处理的情况。 因此，首先，unum可以表示某些精确值（类似于浮点数），还可以表示在精确值（包括精确的-∞和∞）之间的开放区间。因此，完整的实线由交替的精确值和开放时间间隔表示： -∞，（-∞，-maxreal），-maxreal，... -smallsubnormal，（-smallsubnormal，0）， 0， （0，smallsubnormal），smallsubnormal，... maxreal，（maxreal，∞），∞ 以这种方式（在IEEE传统中）异常值（例如下溢和上溢）只是一些开放时间间隔。换句话说：这些以前特殊的条件现在变成常规情况。 IEEE的-∞对应于{-∞}和（-∞，-maxreal）的并集。 现在，有符号零可能是时间间隔（-smallsubnormal，0）和（0，smallsubnormal）。 但是，1 /（-smallsubnormal，0）现在是（-∞，-maxreal），而不仅仅是-∞。而1/​​0是∞。 我仍然犹豫的是在IEEE -0和+0比较中相等。但他们不是没有共同点。似乎映射不是100％。因此，我想知道是否存在可能出现差异的极端情况（（以及这些情况是否确实相关））。 （我知道为什么负零很重要？， 用于负浮点值）

9 math  floating-point 

通过走出去模运算（同时探索之间的区别我走进林荫道rem和mod我碰上了）： 在数学中，模运算的结果是欧几里得除法的余数。但是，其他约定也是可能的。计算机和计算器具有多种存储和表示数字的方式；因此，它们对模运算的定义取决于编程语言和/或底层硬件。 问题： 通过欧几里得除法运算，我发现此运算的余数始终为正（或0）。底层计算机硬件的哪些限制迫使编程语言设计师与数学有所不同？ 每种编程语言都有其预定义或未定义的规则，根据这些规则，取模运算的结果将得到其符号。制定这些规则时采用什么理由？并且如果底层硬件是问题所在，那么规则是否不应该根据编程语言而独立于编程语言而改变？

9 programming-languages  language-design  math  arithmetic  design-decisions 

使用证明形式的关系代数和/或关系演算来测试/验证SQL语句，函数和存储过程的正确性，是否可行甚至可能？ 在我看来，至少应该有这种可能，但是我不知道是否缺少细节，使证明与代码之间的1：1映射不正确。 你们有没有尝试过这样的方法？奏效了吗？您的经历如何？

9 testing  sql  math  relational-database 

最近，我对Haskell产生了浓厚的兴趣。 在尝试学习新概念（例如，forall关键字和ST monad）和一般的Haskell的类型系统时，我不断地从类别理论和lambda演算中学习概念。所以，我想知道： 数学的其他哪些分支对于深入了解Haskell的类型系统也很重要？ 我可以放弃对这些数学的严格研究，而是专注于某些相关概念吗？（例如，lambda演算中的量词。）如果是，那么哪些概念必不可少？ 我希望很快能学到类型和编程语言，但是，请提出您认为合适的其他替代阅读资源。

9 programming-languages  functional-programming  math  haskell  type-systems