DIY: Physical Random Number Generators & Double Slit Experiment

One of the benefits of Quantum Computing is their ability to generate truly random numbers.

Since classical computers are deterministic machines, governed by algorithms, they are inherently predictable. Therefor any number generated by a classical computer, even if it seems complex is actually based on a set of conditions or algorithm, which therefor makes it a “pseudo random number”, rather than truly random.

To generate truly random numbers you need to rely on a physical processor or phenomena that are unpredictable, examples of this include radioactive decay, electronic noise or even atmospheric noise.

Since QC is essentially based on a physical process and the probabilistic nature of quantum mechanics, its qubits can exist in a superposition state, this means they can represent a combination of 0 and 1 simultaneously, this state/property can be harnessed by QRNG (Quantum random number generators) to produce truly random numbers.

As a fun project, I decided to build a small physical QRNG using an Arduino, laser diode, beam splitter and two photo resistors. The basic premise is that you pulse the laser, it sends a wave/particle (both!) through the beam splitter, 50% of the time it should hit one of the two photo resistors, providing you with a random string of “1”s or “0”s.

While a very simple, basic and small example, it is a fun experiment. Check out OpenQbit.com if you would like to build your own. To make this a little easier, I laser cut a template/outline for the beam splitter for holding each of the components.

Enjoy Randomness? Check out these blog, sites, references: http://www.reallyreallyrandom.com

Non Quantum RNG generator using zener noise: http://www.reallyreallyrandom.com/zener/breadboard/

Nice video explaining the seed variables used and middle squares: https://www.khanacademy.org/computing/computer-science/cryptography/crypt/v/random-vs-pseudorandom-number-generators

Generating Random Numbers with QisKit & IBM Quantum Hardware

Generating true random strings using classical computers is not as easy as you may think. Unlike deterministic processes that follow specific algorithms and patterns, achieving true randomness poses a challenge in the realm of classical computing. Classical computers operate based on predetermined instructions and logical operations, which inherently lack the inherent unpredictability required for true randomness.

In contrast, true randomness involves an element of unpredictability that goes beyond the deterministic nature of classical computing. Attempts to generate random strings on classical computers often involve algorithms that simulate randomness, but these are ultimately constrained by the deterministic nature of the underlying hardware and software. read more

Generative Art Resources

During the NFT hype, generative art got a lot of attention due to its ability to programmatically, and algorithmically generate designs and art. These are a few resources I used and developed digging a little bit deeper into the subject.

Skill Share Course: https://www.skillshare.com/classes/Programming-Graphics-I-Introduction-to-Generative-Art/782118657

  • Coding Train by Daniel Shiffman — one of the authors of Processing. A talented and cheerful teacher who will change your perception of teaching.
  • Awesome Creative Coding on Github — most useful links on your way to becoming a generative artist
  • Openprocessing — place when you can find and share works using P5.js and Processing
  • Programming Graphics от Joshua Davis — the best motivating creative coding course in the web (in my humble opinion)
  • read more

    Glowforge Notes

    We have owned a Glowforge since their introduction and it has been a fun tool to work with. Here a few of my notes on cutting various materials, some acronyms and details which I found useful on this learning journey.

    Terminology 

  • GF: Shorthand for “GlowForge”. There are two types of GF: basic and pro. They differ in the size of material that can be processed and the power of the laser.
  • PG: Shorthand for “Proofgrade”™. PG material is provided by GF and is already calibrated for cut/score/engrave. The table below is for manual (not PG) material on a GF Basic.
  • Laser: The ‘Pro’ version has a 45W CO2 laser. The basic (my version) has a 40W CO2 laser. The laser power impacts the ‘Power’ setting. (50% of 45W is not the same as 50% at 40W.)
  • Speed: Value from 1 to 1000. 30% speed is 300. (The forums sometimes call this “zooms” as it zooms around.) NOTE: GF changed the scale during their beta period. If you see instructions prior to Aug 2017 that use very slow speeds (e.g., 15 for speed), then it’s likely the old scale. Using those slow speeds on the new GF will likely cause a fire.
  • Power: Value from 1 to 100. 20% power is 20. With a 40W laser, 20% power is about 8W. (The forums sometimes call this “pews” as in “pew pew pew!” You might have someone say “I used 800 zooms and 50 pews.” The terms ‘zooms’ and ‘pews’ came about because GlowForge doesn’t provide units.) Keep in mind, power is not necessarily linear! And the intesity will drop with age (just like any light bulb).
  • LPI: Lines per inch. Mostly for graphics/engraving. Defaults to 225. Use higher value to prevent rastering. At around 300LPI, the engraving dots overlap. 225 is good for draft, but will raster. 340 has no noticable rastering on most materials. At super high 1355LPI, you might see numberical error in the rastered graph that looks like a pixel shift. I’d avoid anything over 600LPI.
  • Flashback: When the laser cuts through, it may create sparks off the crumbtray’s metal. These sparks can create burns, or flashback, on the back of the material. Lowering the amount of power (or increasing speed) reduces flashback.
  • Kerf: The laser burns away material. The kerf is the gap created by the laser. More power creates a wider kerf. Some materials melt or burn back (e.g., foam or paper), creating a wide kerf.
    • On really hard material, just assume the kerf is 0.002″ (0.05mm).
    • In general, kerf on PG hardwood is about 0.002″, and 0.002-0.022″ in general.
    • PG Medium Maple has a kerf around 0.008″.
    • PG Draftboard has a kerf around 0.002″ (use 0.05mm – 0.06mm; 0.05 is barely loose; 0.055mm is good).
    • PG Acrylic has a kerf around 0.002″ (0.05mm).
    • Zebrawood, Purpleheart, and other really hard woods have a kerf around 0.002″ (0.05mm).
    • For inlays: Take half the kerf from the outside material (small hole) and half the kerf from the inside material (fill hole). Increase the inside/fill material’s size by this amount. If the outside material is flexible (e.g., wood) and you want a really tight fit, increase the size of the inside/fill material by another 0.001″. For inflexible (acrylic, hardwoods), you might add 0.0005″ for a really snug fit.
    • Inlay: Acrylic in Medium Maple: Increase acrylic by 0.020. Using 0.015 can be finger-pressed in but also pops out easily. Using 0.017 can still be popped out. However, if 0.020 doesn’t fit in the first time, then first put in 0.017 and then pop it out. That will stretch the hole just a little so the 0.020 fits tightly and will never come out.
    • Inlay: Acrylic in Medium Draftboard: (TBD) Increase acrylic by 0.025. The kerf from draftboard is larger than a hardwood like medium maple.
    • read more

  • Cost to Deploy a Contract on the Ethereum Network

    The cost of your deployment is based on 5 things, with a 6th affecting the estimated cost of deployment:

    The flat fee of 32k gas. The CREATE op code, which is called during contract creation, costs a fixed 32k gas. This is of course on top of the 21k gas of a normal tx. Note: During contract creation from an EOA (non-contract address), the CREATE opcode isn’t explicitly called. The return value of the tx is actually used to create the contract, but the fixed 32k fee is the same. The amount of bytecode in the compiled contract. More bytecode means more storage, and each byte costs 200 gas. This adds up very quickly. Note that inherited parent contracts are also included in the bytecode. The TX data. All the bytecode your sending as tx data costs 68 for non-zero bytes and 4 for zero bytes. The code actually runs before creation of the contract, e.g. the constructor of the contract. If the constructor requires a lot of computation to generate the bytecode, then it’ll be even more expensive. The gas price. The higher gas price you use, the higher it will cost. See  

    ethgasstation.info read more