5 ms·
The bug isn't in your algorithm; the bug is in your language, which doesn't provide arbitrary-precision integer arithmetic by default.
by ScottBurson 9y ago
The bug isn't in your algorithm; the bug is in your language, which doesn't provide arbitrary-precision integer arithmetic by default.
- thebooktocome 9y agoBig integer by default is a terrible idea. Just look at Python 3.
- __s 9y agoPython 2 was bigint by default. Not even going to deconstruct your argument past that
- thebooktocome 9y agoI didn't say it wasn't...?
- deleted 9y ago[deleted]
- __s 9y agoI didn't say you didn't say it wasn't
- ScottBurson 9y agoIt works fine in Common Lisp. What's the problem with it in Python?
- e12e 9y agoCould you expand? The number tower is one of the things I happen to like about python 3, but apparently you think there's something wrong? Performance?
- ghayes 9y agoErlang has arbitrary length integers by default, and I've found it to be incredibly liberating.
- throwaway91111 9y agoI thought Erlang didn't even have random access. Might not be the best fit for an in-place quicksort.
- khedoros1 9y agoThe bug isn't in the language, you just disagree with some of the goals. It was designed for the compiler to be small and easy to write, with data types and operations that map directly to operations that most CPUs can perform.
- pishpash 9y agoThe bug is in the author's understanding of his choice of language. The language did a perfectly reasonable thing.
- deleted 9y ago[deleted]
- kazinator 9y agoStill, the formula low + (high - low)/2 keeps the integers smaller (assuming everything is positive). That is to say, it can work with larger values before requiring bignums compared to (low + high) / 2. On the other hand, it is more operations.