在Number或BigInteger和BigDecimal(或这些API的文档中)中出现错误? [英] Bug in Number or BigInteger and BigDecimal (or alternatively in the API documentation of those)?

问题描述

根据Number.longValue()的规范，该方法应...

According to the specification of Number.longValue() the method should...

将指定数字的值返回为long.这可能涉及舍入或截断.

但是，BigInteger(和BigDecimal)将覆盖此方法，并返回它表示的数字的整数部分的64个低位.例如，来自BigInteger的文档:

However, the BigInteger (and BigDecimal) overrides this method and returns the 64 low bits of the integer part of the number it represents. From the docs of BigInteger for example:

[...]如果此BigInteger太大而无法容纳一个长整数，则仅返回低阶64位.[...]

我声称"这可能涉及舍入或截断."并没有说出该方法实际应返回的内容 ，或者，在实现或文档中存在错误.

I claim that either "This may involve rounding or truncation." doesn't say anything about what the method actually should return, or, there is a bug in implementation or documentation.

您同意吗，还是我的推理有误?

Would you agree, or do I have a mistake in my reasoning?

示例代码:

import java.math.BigInteger;
import static java.math.BigInteger.*;

public class Main {
    public static void main(String[] args) {

        BigInteger i = valueOf(Long.MAX_VALUE);

        // Result: Long.MAX_VALUE, just as expected.
        Number n1 = i;
        System.out.println(n1 + " -> " + n1.longValue());

        // I expect to get the "rounded" value Long.MAX_VALUE
        Number n2 = i.add(ONE);
        System.out.println(n2 + " -> " + n2.longValue());

        // I expect to get the "rounded" value Long.MAX_VALUE
        Number n3 = i.multiply(TEN);
        System.out.println(n3 + " -> " + n3.longValue());
    }
}

输出:

9223372036854775807 -> 9223372036854775807
9223372036854775808 -> -9223372036854775808
92233720368547758070 -> -10

推荐答案

措辞这可能涉及舍入或截断" 出现在javadocs中的longValue()，shortValue()，和byteValue()的 Number ，因此很明显，截断"旨在在某些情况下包括丢失重要的高阶位.

The wording "This may involve rounding or truncation" appears in the javadocs for the longValue(), shortValue(), charValue() and byteValue() of Number, so it is clear that "truncation" is intended to include loss of significant high order bits in some cases.

问题确实是，术语截断"通常意味着丢失低阶位. (这就是我30年前在数值分析课程中记住的方式. Wikipedia同意.)

The problem really is that the term "truncation" conventionally means loss of lower order bits. (That's how I remember it from my numerical analysis course, 30 years ago. And Wikipedia agrees.)

相比之下， JLS 5.1.3 描述相同的过程(缩小整数原始类型时)，如下所示:

By contrast, the JLS 5.1.3 describes the same process (when narrowing integral primitive types) as follows:

有符号整数到整数类型T的缩小转换会简单地丢弃除n个最低阶位以外的所有位，其中n是用来表示类型T的位数.

A narrowing conversion of a signed integer to an integral type T simply discards all but the n lowest order bits, where n is the number of bits used to represent type T.

是的，我同意javadoc不正确.提交错误报告.

So yes, I agree that the javadoc is incorrect. Submit a bug report.

注意

我最初删除它是因为我认为提交错误报告的建议可能是徒劳的(基于我过去使用文档错误报告的经验).但是@aioobe 已经提交了错误报告...(错误ID:

I had originally deleted this because I thought my suggestion to submit a bug report was probably futile (based on my past experience with documentation bug reports). But @aioobe has submitted a bug report ... (Bug ID: 7000825)

这篇关于在Number或BigInteger和BigDecimal(或这些API的文档中)中出现错误?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！