数据类型简明指导
数据类型简明指导
共有{82}条精彩评论
日期不是基于 EPOCH 吗？
Excel： 1900
视窗（传统）和 NTFS：1601
Windows（现代）、.NET 和 SQL (DATETIME2)： 0001
SQL (DATETIME): 0001 1753
DOS 和 Zip 和 FAT：1980
TL;DR: https://xkcd.com/927/
其实是 Excel，有一次我不小心点错了格式，才有了这个想法
1753 从何而来？
现在的国际统一历法开始广泛使用的第一个日期–整个英帝国从儒略历转为格奥尔格历。
在 1753 年之前，很多地方的日期都会相差几天。
有趣的是，这也是税收年度经常在奇怪的日子开始的原因–因为人们暴动，说他们要在不存在的日子里被征税，税收结束日期被推后了。
参考资料：
https://en.wikipedia.org/wiki/Calendar_%28New_Style%29_Act_1750
Sybase 无法进行格雷戈里/儒略转换，因为在转换过程中跳过了天数，所以他们选择了转换后的年份，这样就无法在日期字段中表示缺失的日期范围。
有人知道 time_t 吗？
1970-01-01 00:00:02
在 C 标准中，time_t 的值是未定义的。唯一可以保证的是它是一个算术类型。
SPSS：08/15/1582（当我发现它时，这个问题让我大吃一惊）。
今年开始使用公历。我猜这就是它显眼的原因。但不确定日期。
天哪，当我们开始在月球上做事情时，关于日期时间的讨论就会一发不可收拾了
不在 Excel 中
这家伙太棒了。
在 VBA 中不也一样吗？
这取决于语言和系统。在处理大日期范围时，Epoch 的功能非常有限。
请查看 Y2K38 问题。
2038 问题是一个 32 位问题，而不是纪元问题
… 为什么是 “降票”？这要看你说的 “大日期范围 “是什么意思了，但你说的大日期范围肯定是指比经典 Unix Epoch 所能提供的 68 年更大的日期范围。它最终会被 64 位 time_t 值所取代，但这是另一种类型，简直就是计算时代的终结。
是的，旧的纪元标准有一些局限性。但这并不意味着它不好。就像做其他事情一样，要根据工作需要选择合适的工具。
如果你需要比秒更高的精度，或者需要存储时区偏移数据。你可以选择不同的日期类型。
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
是的，所有（相当小的）整数都可以无误表达
从数学家的角度来看，所有数字都是相当小的数字。
💀（我爱它😆)
大整数浮点数会出现精度误差吗？我认为最合理的做法是，即使您将某物定义为浮点数，也只有在实际出现小数时才会出现浮点错误，因为即使定义为浮点数，也没有理由像定义浮点数那样定义整数。我也不太懂这些东西，我只是个类型脚本开发人员。
是的。对于 32 位浮点数，无法表示的最小正整数是 16,777,217。
….the JavaScript / TypeScript 的数字类型只是一个 double（64 位浮点数），因此它也有另一个人所描述的问题，但阈值更高（大约是 9 quadrillion，而不是 1680 万）。如果需要检查正在处理的整数是否被精确表示，可以使用 MAX_SAFE_INTEGER 等函数和常量来处理。如果需要无限大的整数，还有 BigInt 类型。
整数的问题在于它有一个极限。当整数过大时，就不能再增加了。一个 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 大得多的整数，只要你能接受超过一定限度的误差。
你是好意，但 0*21 = 0
不，它们是正确的。这就是他提到尾数中隐含 1 的原因。全零尾数代表 1。
(尾数的隐含前导位为 0 的变位除外）
二进制不是数据类型
我来这里就是要说这个。可能是指字节对象。二进制只是另一种数据类型（通常是 int 或字符串）的字节表示。
我认为他们的意思是以 10 为基数的整数和以 2 为基数的二进制数
它们是表示字符串这种相同数据类型的不同方法，底层数据始终是二进制的
2 基本上可以用所有浮点格式表示，所以你不会得到 1.9999….
在数学上，1.9999…. = 2
只有在 .99 无限重复的情况下才会出现这种情况，而浮点数的情况不可能如此，因为它存储数据的位数是有限的。1.99999999999999 不等于 2，只等于 1.99……重复
在数学上，x = x + 1（通常？
这是运算符定义的问题（在数学和编程语言中）。
这不是无稽之谈，而是一个错误的陈述。因为 x == x + 1 就是错误的。
不，范姆。如果你问纯数学专家，他们会告诉你不同的坐标系。最基本的坐标系是极坐标，例如，用纬度、经度和与地心的距离来表示你在地球的哪个位置。在这种情况下，如果你在经度 x 处，绕地球一周，那么你最终会到达相同的位置 x。
如果他们开始谈论非欧几里得空间。别跑 太迟了 在非欧几里得空间你是跑不掉的。
我有预感会有这样的事情发生，所以才在括号里加上了 “通常”，笑死我了
如果 x 接近无穷大，那么我认为这是真的
大多数无穷大都不是这样。不过你的思路是对的。
不对。日期格式不对。我们的格式完全是无政府状态。你想从大单位到小单位。这很有道理，或者至少从小到大
从大到小，易于排序： 1900-01-02
完全是我喜欢的方式。但从大到小也不错，虽然不受欢迎，但也不坏。尤其是当你看到美国人把所有东西都混在一起的时候
这只是一个琴弦代表。在引擎盖下，它只是一个整数（我认为这是一个笑话）
约会真伤人。
二进制不是数据类型
浮点数可以准确表示 2 的任意幂次
布尔型无法进行加法运算
不，在 IEEE754 标准中，任何 2 的幂次都完全可以表示。
有没有一种语言允许布尔加法，而不是为了简化计算而把布尔加法变成整数加法？
另外，浮点数也是错误的，但我想这是个玩笑。
布尔 “加法 “通常只是 “或”，乘法是 “和”。这是旧式学术文献中的常用符号，在 C 语言中也可以使用，在 C 语言中布尔型是整数，假值为 0，任何其他值都为真。
如果 0 以外的任何值都是真值，我们能否写出这样的值，即当我们做加法或乘法时，溢出会使结果为 0，所以真 * 真 = 假？
可以，发生这种情况的几率非常非常小。
是的，但你需要非常小心。
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 运算。
没错，这就是笑话。
这个想法有两个来源：
1) 我的孩子很傻： “爸爸，一加一是多少？” “二？” “不，11！”
2）有一次，我从一个第三方应用程序的数据库中做报告，很郁闷，我想知道为什么我没有得到本应计算为零的数据结果，直到我发现我认为是整数的数据实际上是浮点数。
你的孩子会 javascript？
从技术上讲是 C，因为所有非零值都是真值
我不明白为什么不行：
int main() { bool x = true + true; }
在哪个疯狂的世界里，把 1 加 1 就能得到 2 月 1 日？
我知道一个设计很差的系统可能会把它理解为从纪元算起的天数（或者至少看起来是这样，它可能在引擎盖下做的是秒或毫秒），但有哪个系统会这样做，而且还拥有真正的数据类型（当然，你可能会在电子表格中做这种愚蠢的事情，但你会在那里做二进制和布尔数学吗）？
布尔类型也是一种特例–只有当你把 int 假装成布尔类型时，它才会起作用（这可能是因为当时的情况，也可能是后来的历史原因）。
如果你真的有一个布尔类型，它应该不起作用。
浮点型–对于 2（但不是 3）应该完全没问题
这不是 2 月 1 日，而是 1 月 2 日。这又是一个来自美国的 “曲线球”。
我专门给这个帖子降了票，因为这是美国的垃圾 MM/dd/yyy 格式。
3 可以，1/3 不行。
而且没有二进制数据类型。它与 int 相同
这取决于语言–在 Python 中，字节字符串是一个字面形式
b” x00″ != “ x00”
是的，但那是一个字符串。他把二进制当成了数字。但因为计算机是在二进制的基础上工作的，所以每个数字/整数都是二进制的
浮点数确实有 2 的特定值，但没有 1.9 的特定值……
以月/日/年为单位哭泣
不会，整数编码为浮点数时相加不会出错。只有非整数值才会出现错误。
我的意思是，从技术上讲，1.999……确实等于 2，因为在这两个数字之间不存在 1.999……< x < 2 这样的数字。< x < 2.
日期和浮点数？
每当我需要生成 excel 时，我都会将日期列改为 1900-01-01，然后再加 2，真不知道为什么在 excel 中格式化普通日期字符串会这么难。
位。1 + 1 = 0
技术上？是的。
二进制不是数据类型…
2.00000000007
我唯一不明白的是 Float…
也许我错了，但字符串 s = 1+1 不就是 ASCII 表中十进制代码为 2 的字符吗？
浮点数没有”……”
布尔值 1+1=0 因为它是一个 xor
对于某些计算机上的某些语言。
二进制不应该是 01 吗？
B’01 = 1 B’10 = 2 B’11 = 3
不是吗？你还是从 0 开始，所以 0 是 0，1 是 1，然后 2 是下一个最高数字 10。01 在二进制中仍然只是 1。
发表回复