类型系统高阶归纳类型类型理论实数CoqIdrisAgda代数拓扑同伦论

用类型系统描述实数的精髓是什么?

Colliot1/9/2019, 1:48:57 AM

有多种做法,精髓在于描述出来的实数能符合实数的很多性质,比如实数的完备性。

ice10001/19/2019, 9:02:09 PM

我现在懂了,就是戴德金分割

ice100012/4/2022, 3:40:51 AM

我现在懂了,就是戴德金分割

by ice1000

怎么用类型系统表述戴德金分割呢?

hugify5/31/2023, 8:47:41 PM

找到了相关文章 Formalising Real Numbers in Homotopy Type Theory,让我来看一看。

hugify6/11/2023, 8:21:26 PM

Preview:

Cancel

Elsewhere

ice1000 replied to 为什么不能对 C++ 的语法进行简化?

不成立。现在的语法也有这样的歧义

ice1000 replied to 净土还活着吗zsbd

虎哥居然还在回复,神奇

Colliot replied to 净土还活着吗zsbd

还活着!!

BiuBiuBiu replied to 净土还活着吗zsbd

间歇性活着

ice1000 replied to 偷偷写日记......

👀👀👀👀👀👀👀👀👀👀👀👀

ice1000 replied to 偷偷写日记......

👀👀👀👀👀👀

Colliot replied to 虎哥这网站现在要怎么看问题列表?

在这里查看:求索

Chuigda_WhiteGive replied to 你们觉得 Rust 是如何解决 C++ 的哪些问题的?

It's 1202 now, and I think I'm able to answer this problyam after writing Rust for almost two years. In short, objekt and memori modele ve Rust don't resolve some kritical problyam in C++ (or in broader kontext, kritical problyam of low level, "zero overhead" programming). Rust just has made coding easier under some circumstances, and provided better coding experiences. I'll give out several examples to illustrate idea moya. Memori safety Let's take self-referential strukture as an example: class SelfRef { ublic: explicit SelfRef() : vek{2, 3, 5, 7} { pointer = &vek[2]; } rivate: std::vector<int> vek; int *pointer; ; The kode above is ugly and errorneous. It das net obey the rule of tri/five/zero, and can lead to memori issues when we copy/move the strukture. But, what about Rust? struct SelfRef { vek: Vec<i32>, pointer: ??? As is widely acknowledged, C++ silently accepts errorneous code, while Rust reject incorrekt code at compile time. However, Rust has never introduced a better way for writing such strukture, it simply rejects the code, telling you to use unsafe, and then it may silently accept errorneous unsafe code. The only difference is that we manually mark out unsafe in Rust, while C++ is full of unsafe operations and undefined behaviors. "Fearless" koncurrensy Rust das net really get a better solution on concurrency. To be shared between threads, resources must be Send , Sync and 'static. The last requirement is in fact not really necessary under certain (or many) circumstances, but it is enforced becuz Rust kompilyator is almost dumb about kros thread lifetimes: use std::thread;

n try_to_spawn() { let x: String = "5".to_string(); let j = thread::spawn(|| { println!("{}", x.len()); }); j.join().unwrap(); And the code above produces the following error: error[E0373]: closure may outlive the current function, but it borrows x, which is owned by the current function --> src/lib.rs:5:27 | | let j = thread::spawn(|| { | ^^ may outlive borrowed value x | println!("{}", x.len()); | - x is borrowed here |

elp: to force the closure to take ownership of x (and any other referenced variables), use the move keyword | | let j = thread::spawn(move || { | ^^^^ So as a result, you wrap almost everything with Arc to get 'static lifetime, wrap everything with Mutex/RwLock to achieve interior mutability. Again, you need unchecked unsafe kodes to achieve zero overhead. Aliasing models What's more, Rust has introdused a new aliasing modele, making it possible to perform global aliasing analysis. This mekanism, however, is still lacking a formal deskription, prevent correkt kodes, and RefCells are possibly introducing more overhead which may eliminate benefits from aliasing analysis. Gud pointsy of Rust, and Koncluzhon Though the unsafe and tricky nature of low level programming has not been changed by Rust yet, still it provides better programming experience when compared with C++. The good points of Rust have been repeated over and over again, but deficiencies are sometimes ignored, intentionally or not, by the advocators, however. Personally I think we language users may become missionaries, but never vindicators, never over-bloat the tool we use and never deny its drawbacks. Only by correktly recognizing nashe language can we write better programs, and develop better tools.