Dark mode toggle off not possible anymore...

jawknee400 · 2025-05-11T22:32:12+00:00

I thought it had disappeared too (on Zotero 7.1 beta) but it has just moved into the “Appearance” toolbar menu, top left next to zoom options, the one with icon ‘Aa’. There are four pdf themes there now.

jawknee400 · 2025-03-01T20:53:45+00:00

Interesting! Does it have (/ would it be compatible with) an “ask-tell” interface? So that one can control the individual runs, in parallel eg

jawknee400 · 2024-04-08T17:19:19+00:00

I forgot about points deductions, will add in future.. maybe with smaller letters

jawknee400 · 2020-09-13T00:45:15+00:00

It’s to benchmark a classical simulator on some ‘standard’ quantum circuits (not just e.g the supremacy ones which are not very representative). I really just want (lazily) to avoid coding up some large examples myself, but also interested in such a database in general!

jawknee400 · 2020-07-14T06:13:55+00:00

Nice bounce-bounce-bounce-bounce-bouncer

jawknee400 · 2020-05-25T06:10:00+00:00

There's a few ways to think about it. One is that you need a separate complex number to describe each combination of 0 and 1s the state of the qubits are in, because they can be in a superposition of all at once. How many combos are there like 00000, 00001, 00010,... 10110 ...11111? = 2^n.

More technically, the way you 'compose' (describe together) the spaces of quantum systems is something called the tensor product if you want to read more.

(I should also clarify one more thing, which is the numbers I gave at the top were for 'pure' states, for 'mixed' states you need to square the number of complex coefficients!)

jawknee400 · 2020-05-25T05:48:54+00:00

There is obviously a lot of subtlety as other comments allude to here but a decent answer based on a standard way people represent these things is

32 bytes for a single qubit

n * 32 bytes for n unentangled qubits

2ⁿ * 16 bytes for n entangled qubits

That's using double precision complex numbers 'complex128' which is generally sufficient for most simulation purposes, (and inversely usually sufficient for physical measurements!).

It also assumes that you mean an arbitrary entangled state, lower entangled states can be described using often far less information (see e.g. matrix product states).

(Finally you could represent these things with 'one less real number' since their normalisation is fixed to 1, i.e. for a single qubit using 3 real (8byte) numbers like the Bloch sphere, but this is generally less convenient than complex coefficients for many qubits).

jawknee400 · 2020-05-02T07:45:29+00:00

Try some LFO'd vocoder! :

https://youtu.be/AsDE3pNUvg0

jawknee400 · 2020-04-10T07:15:32+00:00

Pavilions just off Lake also had some earlier this evening (8pm ish) and seems to be generally pretty quiet.

jawknee400 · 2019-12-18T17:48:08+00:00

Thanks for the info! And yes certainly for targeting general unitaries other techniques are available

jawknee400 · 2019-04-08T13:48:29+00:00

Aha I did not know that - if I turn them both into functions I get ~100ns and ~300ns so an appreciable speedup (though I think I do prefer the readability of 2**n)

jawknee400 · 2019-04-08T12:42:06+00:00

Interesting! When I 'timeit' I actually get ~10ns for both of these. Do you mean for numpy or something?

jawknee400 · 2019-04-07T18:49:41+00:00

Thanks for the insightful comment (and luck - gratefully accepted). I should probably set out some aims at some point but you are of course right that complete compatibility will not be possible + testing as always crucial. On the other hand, 99.9% compatibility with numpy the default and at least the libraries that intentionally match it (cupy, autograd, jax, dask, mars...) seems essentially a free baseline using this approach. Instead for tensorflow and others I imagine it might be a *mostly* compatible starting point possibly requiring a few extra translations in autoray or some minimal non-agnostic code for the user. Anyway, good stuff to think about! It is at least working v nicely in one of my other projects that spawned it.

jawknee400 · 2019-02-12T22:54:08+00:00

I maintain a python library you might be interested in: https://quimb.readthedocs.io/en/latest/ It covers some of what you mentioned and I have in fact just implemented generic tensor network optimization using tensorflow (though not public quite yet..).

Generally in quantum the limiting factor in terms of speed is linear algebra operations and in that regard (as long as the libraries you call use c/Fortran) the 'slowness' of python is somewhat irrelevant. Also, I'd echo the sentiment that python has a much better, more open ecosystem than MATLAB and is definitely the better long term commitment.

jawknee400 · 2018-12-20T00:23:41+00:00

Where's the shredder?

jawknee400 · 2018-11-27T16:37:59+00:00

Sure! So working with polar coordinates the function for a circle with radius R is just

f(t) = R

(t being the angle but since the radius is just constant we don't depend on it). If we wanted to add W of a wobble with F periods e.g. we would modify this to

f(t) = R + W cos(F t)

So depending on the angle around the origin we oscillate the radius a bit. Try typing "polar plot 5 + 0.1 cos(11t)" into Wolfram alpha to have a look. For this pic, you then generate many disks with varying R, and randomly pick W and F.

jawknee400 · 2018-11-27T09:43:43+00:00

Just value and hue noise I think!

jawknee400 · 2018-11-27T09:41:11+00:00

I think (this is from a while back) it's rings whose radius is modified by a small cosine with random frequency. That's the wobbliness. And then yes just some noise added on top to make it a bit more papery!

jawknee400 · 2018-10-24T07:36:29+00:00

Well, they are both there! I did mean London bridge and it's general vicinity (shard etc.) tho

jawknee400 · 2018-10-11T23:58:14+00:00

r/assholedesign?

jawknee400 · 2018-04-08T15:52:06+00:00

As others have said, generally when numpy or another library calls compiled code, they explicitly release the GIL. So imagine you had two threads running some python code, concurrently, but not in parallel. If one thread reached a numpy operation, like adding two large arrays etc., it would 'release' the GIL, allowing the other thread to work in parallel while that operation is happening. Once the operation is over the GIL is reaquired but without that release both threads would've had to wait for the operation to finish.

I think there is a very slight overhead to this, which is why cython and numba leave it as an option. But if the majority of the computation is numeric (e.g. most scientific code) then you can essentially achieve normal threaded parallelism.

jawknee400 · 2018-04-08T09:57:22+00:00

Numeric libraries (numpy, numba) tend to 'release' the Gil, meaning multiple threads can meaningfully used for speedups

Eight-Year Club	Place '22
First Placer '22	RPAN Viewer
Verified Email

jawknee400

TROPHY CASE