Hamming numbers for O(N) speed and O(1) memory

Question

Disclaimer: there are many questions about it, but I didn\'t find any with requirement of constant memory.

Hamming numbers is a numbers 2^i*3^j*5^k, whe

Answer 1

First thing to consider here is the direct slice enumeration algorithm which can be seen e.g. in this SO answer, enumerating the triples (k,j,i) in the vicinity of a given logarithm value (base 2) of a sequence member so that target - delta < k*log2_5 + j*log2_3 + i < target + delta, progressively calculating the cumulative logarithm while picking the j and k so that i is directly known.

It is thus an N^2/3-time algo producing N^2/3-wide slices of the sequence at a time (with k*log2_5 + j*log2_3 + i close to the target value, so these triples form the crust of the tetrahedron filled with the Hamming sequence triples ¹), meaning O(1) time per produced number, thus producing N sequence members in O(N) amortized time and O(N^2/3)-space. That's no improvement over the baseline Dijkstra's algorithm ²  with the same complexities, even non-amortized and with better constant factors.

To make it O(1)-space, the crust width will need to be narrowed as we progress along the sequence. But the narrower the crust, the more and more misses will there be when enumerating its triples -- and this is pretty much the proof you asked for. The constant slice size means O(N^2/3) work per the O(1) slice, for an overall O(N^5/3) amortized time, O(1) space algorithm.

These are the two end points on this spectrum: from N¹-time, N^2/3-space to N⁰ space, N^5/3-time, amortized.

---

¹ Here's the image from Wikipedia, with logarithmic vertical scale:

This essentially is a tetrahedron of Hamming sequence triples (i,j,k) stretched in space as (i*log2, j*log3, k*log5), seen from the side. The image is a bit askew, if it's to be true 3D picture.

edit: ² It seems I forgot that the slices have to be sorted, as they are produced out of order by the j,k-enumerations. This changes the best complexity for producing the sequence's N numbers in order via the slice algorithm to O(N^2/3 log N) time, O(N^2/3) space and makes Dijkstra's algorithm a winner there. It doesn't change the top bound of O(N^5/3) time though, for the O(1) slices.