591–600 of 772 posts
Not a very deep CS-y one, but still one of my favourite data structures: Promise Maps. It only works in languages where promises/futures/tasks are a first-class citizen. Eg JavaScript. When caching the result of an expensive computation or a network call, don't actually cache the result, but cache the promise that awaits the result. Ie don't make a Map but a Map > This way, if a new, uncached key gets requested twice…
Not a very deep CS-y one, but still one of my favourite data structures: Promise Maps. It only works in languages where promises/futures/tasks are a first-class citizen. Eg JavaScript. When caching the result of an expensive computation or a network call, don't actually cache the result, but cache the promise that awaits the result. Ie don't make a Map but a Map > This way, if a new, uncached key gets requested twice…
Anybody knows if there is similar pattern for Python's asyncio?
Struct of arrays (also called MultiArrayList in Zig), instead of storing big structs in an array you store each field in a separate array and if you need to fetch the full struct you reconstruct it from the arrays. The benefit is that the arrays items memory size is smaller and has no padding, it also increases cache locality.
records = {
time: [1000, 1001],
price: [20, 25],
volume: [50, 15]
}
records = [
{ time: 1000, price: 20, volume: 50 },
{ time: 1001, price: 25, volume: 15 }
]
// not a big difference with 2 records, but for xxxx records...Not a very deep CS-y one, but still one of my favourite data structures: Promise Maps. It only works in languages where promises/futures/tasks are a first-class citizen. Eg JavaScript. When caching the result of an expensive computation or a network call, don't actually cache the result, but cache the promise that awaits the result. Ie don't make a Map but a Map > This way, if a new, uncached key gets requested twice…
Anybody knows if there is similar pattern for Python's asyncio?
https://docs.python.org/3/library/asyncio-future.html#asynci...
Cache-Oblivious Data Structures: https://cs.au.dk/~gerth/MassiveData02/notes/demaine.pdf A vaguely related notion is that naive analysis of big-O complexity in typical CS texts ignores over the increasing latency/cost of data access as the data size grows. This can't be ignored, no matter how much we would like to hand-wave it away, because physics gets in the way. A way to think about it is that a CPU core is like a…
I saw an amazing presentation on Purely Functional Data structures with a really approachable and understandable proof on ho w a particular structure was asymptotically constant or linear time (I believe), and then followed up by saying that in practice none of it worked as well as a mutable version because of caching and data locality. Oh well.
Not a very deep CS-y one, but still one of my favourite data structures: Promise Maps. It only works in languages where promises/futures/tasks are a first-class citizen. Eg JavaScript. When caching the result of an expensive computation or a network call, don't actually cache the result, but cache the promise that awaits the result. Ie don't make a Map but a Map > This way, if a new, uncached key gets requested twice…
FYI, if you plan to do this in ASP netcore, combine with AsyncLazy for the most optimal results https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/b...
Not a very deep CS-y one, but still one of my favourite data structures: Promise Maps. It only works in languages where promises/futures/tasks are a first-class citizen. Eg JavaScript. When caching the result of an expensive computation or a network call, don't actually cache the result, but cache the promise that awaits the result. Ie don't make a Map but a Map > This way, if a new, uncached key gets requested twice…
readonly foo = bar.pipe(
switchMap(v => doTask(v)),
shareReplay(1),
);
readonly foo = bar.pipe(
map(v => doTask(v),
shareReplay(1),
switchMap(v => v),
);
async someEventHandler(userInput) {
this.bar.next(userInput);
const result = await firstValueFrom(this.foo);
…
}
Earlier quoted context omitted.
I decided to try implement get_gray_xy. I am wondering how you can generalise it to any number of loops and apply it to nested loops of varying sizes, that is if you have three sets and the sizes are 8, 12, 81. Wikipedia says graycodes can be found by num ^ (num >> 1) a = [1, 2, 3, 4] b = [2, 4, 8, 16] indexes = set() correct = set() print("graycode loop indexes") for index in range(0, len(a) * len(b)): code = index…
Here is the implementation of get_gray_xy that I used: static uint64_t deinterleave(uint64_t x) { x = x & 0x5555555555555555; x = (x | (x >> 1)) & 0x3333333333333333; x = (x | (x >> 2)) & 0x0f0f0f0f0f0f0f0f; x = (x | (x >> 4)) & 0x00ff00ff00ff00ff; x = (x | (x >> 8)) & 0x0000ffff0000ffff; x = (x | (x >> 16)) & 0x00000000ffffffff; return x; } static void get_gray_xy(uint64_t n, uint64_t *x, uint64_t *y) { uint64_t gra…
I would like to generalise it for sets of different sizes. Maybe it's something different to a gray codes which you taught me today, it feels that it should be simple.
Maybe someone kind can step in and help me or I can ask it on Stackoverflow.
I need to think it through.
At one point in time I was reading a section on Intel's website of cache optimisation using a tool that shows you the cache behaviour of the CPU and column or row major iteration it had a GUI. I found it very interesting but I cannot seem to find it at this time. I did find some medium article of Cachediff.
Also ROPE, a string allowing for prepends, substrings, middle insertions and appends [2]
[0] http://cr.yp.to/critbit.html
[1] https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.96....
Not a very deep CS-y one, but still one of my favourite data structures: Promise Maps. It only works in languages where promises/futures/tasks are a first-class citizen. Eg JavaScript. When caching the result of an expensive computation or a network call, don't actually cache the result, but cache the promise that awaits the result. Ie don't make a Map but a Map > This way, if a new, uncached key gets requested twice…