427 karma · joined November 11, 2015
One question to PyPy developers: CPython 3.5 [1] introduced math.gcd which uses Lehmer's algorithm [2], are there any plans to include it in PyPy, too?
[1] https://bugs.python.org/issue22486 [2] https://en.wikipedia.org/wiki/Lehmer%27s_GCD_algorithm
- Why the chose stack-based VM, rather than register-based one?
- I see the docs mention Float128 type, is this a real possibility? What it their opinion on having Float128?
- there doesn't seem to be any support for ADC instruction ("add with carry") which would be very useful for implementing multi-precision numeric types. Are the plans to support ADC and the like or not? How to implement, say BigInt, with WebAssembly?
- maybe I misunderstood but when adding two integers result in an overflow, does it trigger the "trap"? I mean, lot of time (e.g. modular arithmetic) one does what fast "wrap around" (i.e. modulo 2^INT_SIZE) in integer types. Is this behaviour (of C) going to stay in WebAssembly?
Btw., there is also https://github.com/openresty/sregex which you might find interesting.
And, impressive work on the regex engine!
Other sorting techniques may be faster. For example, using radix sorting, you can sort n word-sized integers by scanning the data a few bits at a time. Each scan can be done in linear time, and the number of scans depends on the word length w. Hence, the time for radix sorting is proportional to nw. Here, it’s easy to make a mistake. On most computers, w is a small number (typically 32 or 64), and you might be tempted to state that radix sorting is a linear time sorting algorithm. Not so. The algorithm will only work if w ≥ log n. If not, you wouldn’t even be able to store the numbers. Since each memory address is a word consisting of w bits, the address space won’t accommodate n numbers if w < log n. Hence, in the unit-cost RAM model, radix sort also runs in time proportional to n log n.
Also, does anyone know if PCG is in use somewhere today?