【程序员搞笑图片】数据类型简明指导

你也许感兴趣的:

共有 82 条讨论

    1. Excel: 1900

      视窗(传统)和 NTFS:1601

      Windows(现代)、.NET 和 SQL (DATETIME2): 0001

      SQL (DATETIME): 0001 1753

      DOS 和 Zip 和 FAT:1980

      TL;DR: https://xkcd.com/927/

      1. 其实是 Excel,有一次我不小心点错了格式,才有了这个想法

        1. 现在的国际统一历法开始广泛使用的第一个日期–整个英帝国从儒略历转为格奥尔格历。

          在 1753 年之前,很多地方的日期都会相差几天。

          有趣的是,这也是税收年度经常在奇怪的日子开始的原因–因为人们暴动,说他们要在不存在的日子里被征税,税收结束日期被推后了。

          参考资料:

          https://en.wikipedia.org/wiki/Calendar_%28New_Style%29_Act_1750

        2. Sybase 无法进行格雷戈里/儒略转换,因为在转换过程中跳过了天数,所以他们选择了转换后的年份,这样就无法在日期字段中表示缺失的日期范围。

      2. 有人知道 time_t 吗?

        1970-01-01 00:00:02

        1. 在 C 标准中,time_t 的值是未定义的。唯一可以保证的是它是一个算术类型。

      3. SPSS:08/15/1582(当我发现它时,这个问题让我大吃一惊)。

        1. 今年开始使用公历。我猜这就是它显眼的原因。但不确定日期。

      4. 天哪,当我们开始在月球上做事情时,关于日期时间的讨论就会一发不可收拾了

    2. 这取决于语言和系统。在处理大日期范围时,Epoch 的功能非常有限。

      请查看 Y2K38 问题。

      1. 2038 问题是一个 32 位问题,而不是纪元问题

      2. … 为什么是 “降票”?这要看你说的 “大日期范围 “是什么意思了,但你说的大日期范围肯定是指比经典 Unix Epoch 所能提供的 68 年更大的日期范围。它最终会被 64 位 time_t 值所取代,但这是另一种类型,简直就是计算时代的终结。

        1. 是的,旧的纪元标准有一些局限性。但这并不意味着它不好。就像做其他事情一样,要根据工作需要选择合适的工具。

          如果你需要比秒更高的精度,或者需要存储时区偏移数据。你可以选择不同的日期类型。

  1. 2 没有细微误差,加两个 1 也是一样:IEEE-754 只是使用 ±m*2e-127 来存储浮点。只有在试图添加/表示无法用这种方法表示的数字时,才会出现错误。(m 有一个隐含的 1:1001 => 1.1001)举个例子1 + 1 = 2:0 01111111 000.. (1) + 0 01111111 000.. (1) = 0 10000000 000.. (2)→ 1*2128-127 = 21 = 2编辑:最后一行用 1 代替 0,因为隐含 1

    1. 是的,所有(相当小的)整数都可以无误表达

      1. 从数学家的角度来看,所有数字都是相当小的数字。

      2. 大整数浮点数会出现精度误差吗?我认为最合理的做法是,即使您将某物定义为浮点数,也只有在实际出现小数时才会出现浮点错误,因为即使定义为浮点数,也没有理由像定义浮点数那样定义整数。我也不太懂这些东西,我只是个类型脚本开发人员。

        1. 是的。对于 32 位浮点数,无法表示的最小正整数是 16,777,217。

        2. ….the JavaScript / TypeScript 的数字类型只是一个 double(64 位浮点数),因此它也有另一个人所描述的问题,但阈值更高(大约是 9 quadrillion,而不是 1680 万)。如果需要检查正在处理的整数是否被精确表示,可以使用 MAX_SAFE_INTEGER 等函数和常量来处理。如果需要无限大的整数,还有 BigInt 类型。

        3. 整数的问题在于它有一个极限。当整数过大时,就不能再增加了。一个 32 位带符号的 int 永远不会大于 2,147,483,647 – 2^31-1。如果你想让它变大,你… 不能。你的 32 位数字会碰到 20 亿左右的区域,你需要更多的位数。

          然而,浮点数在到达某个点后,仍然可以变大,只是需要接受一点点误差。每个可以表示为 24 位 int 的整数都可以完美地表示为 IEEE 754 32 位浮点数(又称 “单精度 “或 “如果你只要求浮点数,通常会得到什么”)…… 但是,当数值达到 16,777,215 (2^24-1)时,仍然可以继续增大 – 至少在一段时间内,可以四舍五入到最接近的偶数。

          没有一种 32 位 int 格式可以表示 1 和 200 亿。不过,32 位 IEEE 754 浮点数可以表示 “正好是 1 “和 “200 亿,再加上几千”。你所偏离的数值也仅限于你试图表示的数值的某个百分比(或更少)。百分比取决于使用的位数,32 位浮点数的百分比很低,而 64 位浮点数的百分比则低得惊人。

          浮点数不仅可以表示非整数。浮点数还可以表示比同等大小的 int 大得多的整数,只要你能接受超过一定限度的误差。

      1. 不,它们是正确的。这就是他提到尾数中隐含 1 的原因。全零尾数代表 1。

        1. (尾数的隐含前导位为 0 的变位除外)

    1. 我来这里就是要说这个。可能是指字节对象。二进制只是另一种数据类型(通常是 int 或字符串)的字节表示。

      1. 我认为他们的意思是以 10 为基数的整数和以 2 为基数的二进制数

        1. 它们是表示字符串这种相同数据类型的不同方法,底层数据始终是二进制的

  2. 2 基本上可以用所有浮点格式表示,所以你不会得到 1.9999….

    1. 只有在 .99 无限重复的情况下才会出现这种情况,而浮点数的情况不可能如此,因为它存储数据的位数是有限的。1.99999999999999 不等于 2,只等于 1.99……重复

      1. 这是运算符定义的问题(在数学和编程语言中)。

        这不是无稽之谈,而是一个错误的陈述。因为 x == x + 1 就是错误的。

      2. 不,范姆。如果你问纯数学专家,他们会告诉你不同的坐标系。最基本的坐标系是极坐标,例如,用纬度、经度和与地心的距离来表示你在地球的哪个位置。在这种情况下,如果你在经度 x 处,绕地球一周,那么你最终会到达相同的位置 x。

        如果他们开始谈论非欧几里得空间。别跑 太迟了 在非欧几里得空间你是跑不掉的。

        1. 我有预感会有这样的事情发生,所以才在括号里加上了 “通常”,笑死我了

      3. 如果 x 接近无穷大,那么我认为这是真的

        1. 大多数无穷大都不是这样。不过你的思路是对的。

  3. 不对。日期格式不对。我们的格式完全是无政府状态。你想从大单位到小单位。这很有道理,或者至少从小到大

    1. 从大到小,易于排序: 1900-01-02

      1. 完全是我喜欢的方式。但从大到小也不错,虽然不受欢迎,但也不坏。尤其是当你看到美国人把所有东西都混在一起的时候

    2. 这只是一个琴弦代表。在引擎盖下,它只是一个整数(我认为这是一个笑话)

  4. 二进制不是数据类型

    浮点数可以准确表示 2 的任意幂次

    布尔型无法进行加法运算

  5. 不,在 IEEE754 标准中,任何 2 的幂次都完全可以表示。

  6. 有没有一种语言允许布尔加法,而不是为了简化计算而把布尔加法变成整数加法?

    另外,浮点数也是错误的,但我想这是个玩笑。

    1. 布尔 “加法 “通常只是 “或”,乘法是 “和”。这是旧式学术文献中的常用符号,在 C 语言中也可以使用,在 C 语言中布尔型是整数,假值为 0,任何其他值都为真。

      1. 如果 0 以外的任何值都是真值,我们能否写出这样的值,即当我们做加法或乘法时,溢出会使结果为 0,所以真 * 真 = 假?

        1. 可以,发生这种情况的几率非常非常小。

        2. 是的,但你需要非常小心。

          C 语言中的很多溢出都是未定义的行为。为了让编译器进行优化,它可以对某些类型的溢出为所欲为。如果是带符号的整数,编译器就可以为所欲为–这允许编译器进行大量优化,并加快代码速度。例如,如果你不在乎溢出,”a+10>20 “和 “a>10 “是一样的,但第二个代码去掉了一个加数。

          有符号 int 的溢出是未定义的行为。但是,对于无符号 int,溢出是有定义的(算是吧–官方说法是 “模数包装”,而不是溢出)。无符号 int 会从 UINT_MAX 翻转到 0… 但对 UINT_MAX 的唯一要求是,它必须在 limits.h 中提供,并且至少是 65535 或更大。如果你依赖于它正好是 65535,你可能会在运行代码时遇到问题。最终,你可能需要跳过一些不必要的障碍。

          当然,你也可以选择更简单的方法:排他或或 XOR。XOR 是一种布尔运算,如果两个值不同,则为真;如果两个值相同,则为假。TRUE XOR TRUE = FALSE,而 TRUE XOR FALSE = TRUE。方便的是,计算机已经可以像做加法一样自然地进行 XOR 运算。

    2. 没错,这就是笑话。

      这个想法有两个来源:

      1) 我的孩子很傻: “爸爸,一加一是多少?” “二?” “不,11!”

      2)有一次,我从一个第三方应用程序的数据库中做报告,很郁闷,我想知道为什么我没有得到本应计算为零的数据结果,直到我发现我认为是整数的数据实际上是浮点数。

    3. 从技术上讲是 C,因为所有非零值都是真值

    4. 我不明白为什么不行:

      int main() { bool x = true + true; }

  7. 在哪个疯狂的世界里,把 1 加 1 就能得到 2 月 1 日?

    我知道一个设计很差的系统可能会把它理解为从纪元算起的天数(或者至少看起来是这样,它可能在引擎盖下做的是秒或毫秒),但有哪个系统会这样做,而且还拥有真正的数据类型(当然,你可能会在电子表格中做这种愚蠢的事情,但你会在那里做二进制和布尔数学吗)?

    布尔类型也是一种特例–只有当你把 int 假装成布尔类型时,它才会起作用(这可能是因为当时的情况,也可能是后来的历史原因)。

    如果你真的有一个布尔类型,它应该不起作用。

    浮点型–对于 2(但不是 3)应该完全没问题

    1. 这不是 2 月 1 日,而是 1 月 2 日。这又是一个来自美国的 “曲线球”。

    2. 我专门给这个帖子降了票,因为这是美国的垃圾 MM/dd/yyy 格式。

    3. 而且没有二进制数据类型。它与 int 相同

      1. 这取决于语言–在 Python 中,字节字符串是一个字面形式

        b”x00″ != “x00”

        1. 是的,但那是一个字符串。他把二进制当成了数字。但因为计算机是在二进制的基础上工作的,所以每个数字/整数都是二进制的

  8. 浮点数确实有 2 的特定值,但没有 1.9 的特定值……

  9. 不会,整数编码为浮点数时相加不会出错。只有非整数值才会出现错误。

  10. 我的意思是,从技术上讲,1.999……确实等于 2,因为在这两个数字之间不存在 1.999……< x < 2 这样的数字。< x < 2.

  11. 每当我需要生成 excel 时,我都会将日期列改为 1900-01-01,然后再加 2,真不知道为什么在 excel 中格式化普通日期字符串会这么难。

  12. 也许我错了,但字符串 s = 1+1 不就是 ASCII 表中十进制代码为 2 的字符吗?

  13. 浮点数没有”……”

    布尔值 1+1=0 因为它是一个 xor

  14. 对于某些计算机上的某些语言。

    1. B’01 = 1 B’10 = 2 B’11 = 3

    2. 不是吗?你还是从 0 开始,所以 0 是 0,1 是 1,然后 2 是下一个最高数字 10。01 在二进制中仍然只是 1。

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注