3 ms·
One of the things I love about Lisp is that i+1 is always greater than i. You can work hard to make that not be true, but that's the default and IMHO it's the p
by dreamcompiler 3y ago
One of the things I love about Lisp is that i+1 is always greater than i. You can work hard to make that not be true, but that's the default and IMHO it's the proper default.
- eru 3y agoWell, that's the case for signed integers in C as well. (But only on a technicality: because every program where that breaks is not technically C, and the compiler is allowed to assume this doesn't happen.) I suspect the Lisps you talk about use arbitrary sized integers by default? Python also has that default. It's a good default. If you want to optimize for size and want an integer of limited size, like a 64 bits or so, you should explicitly specify.
- MathMonkeyMan 3y agoYep, the [numerical tower][1]. Python's int is a bignum, but in Scheme you even have rationals built in. There's a notion of which numeric values are "exact" and which ones are "inexact" (i.e. floating point). [1]: https://en.wikipedia.org/wiki/Numerical_tower https://en.wikipedia.org/wiki/Numerical_tower
- eru 3y agoI remember the numerical tower from Scheme. That was an interesting concept. (Though mathematically, you might want something with a more complicated structure than a tower. Eg p-adic numbers would sit below integers, next to rational numbers, but not below them.) Python has rational numbers in the standard library. They are easy to use there, too.
- astrange 3y agoThis is dangerous for security, because now your math operations are no longer O(1) and might allocate memory.
- nlitened 3y agoI think, if security is involved, one would still need to do overflow checks in the exact same places, so nothing is gained and nothing is lost.
- ack_complete 3y agoMight allocate a _lot_ of memory. I've actually seen a case where some fatfingered a comparison in Python as a << b instead of a < b, and allocated gigabytes of memory on a server.
- dreamcompiler 3y agoSide channels are hard to prevent in all languages because of compiler optimizations, out-of-order execution, branch prediction, speculative execution, loop unrolling, eliding operations, register renaming, using the FPU under the sheets for ordinary integers, clock throttling, cache usage, rowhammer, etc. Modern mostly-hidden, mostly-proprietary architectural execution models are hell for security and side channel prevention. We need chips from 1984 with Ghz clocks if we want good security.
- astrange 3y agoOh, this isn't (mainly) about sidechannel leaks. It's about DoS attacks.
- eru 3y agoIf you want to harder your code against timing attacks, you need to actively work hard, instead of just relying on some operations taking O(1). (I don't even know whether your processor does regular multiplication and division in O(1)?)
- astrange 3y ago