【程序员搞笑图片】数据类型简明指导
你也许感兴趣的:
- 33 种编程语言的 UUIDv7 实现
- 【外评】Rust,你错了
- 【外评】为什么人们对 Go 1.23 的迭代器设计感到愤怒?
- 华为自研编程语言“仓颉”来了!鸿蒙应用开发新语言,性能优于 Java、Go、Swift
- 【外评】JavaScript 变得很好
- 【外评】华为发布自己的编程语言 “仓颉”
- VBScript 废弃:时间表和后续步骤
- 【外评】BASIC 编程语言 60 岁了
- 【外评】为什么 ALGOL 是一种重要的编程语言?
- 【程序员搞笑图片】如果的话
日期不是基于 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”