Monthly Archives: January 2011

Nearly there, Idoru


Could someone ever be able to mess up the Big Bang through observing it ?

I’ve had the chance to watch the episode “What Is Reality?” from BBC series, Horizon, yesterday. Very cool stuff ! I think it’s still possible to catch up with that on the BBC iPlayer.

The episode goes through open questions concerning quantum reality, its bizarre properties – to say the least – and recent years developments. The famous two-slits experiment, elegantly described by Prof. Anton Zeilinger, opened the episode and my attention stayed glued to it throughout. Although, I’d already known about such experiment (Young, 1801), I think I grasped more profoundly what it entails, this time. Apparently, Feynman once said that “if you wish to confront all of the mysteries of quantum mechanics, you have only to study quantum interference in the two-slit experiment”. I couldn’t help going after more details on the Internet about it straight at the end of the episode. …’cause of the appealing inquisitive way it had been presented, I suppose – a detective-like sort of way. It somehow allowed the idea that there were still room for improvement in unfolding the mystery.

The experiment is conceptually simple. A laser is put in front of a wall with two vertical slits on it, right opposite the laser. There’s another wall (screen) behind the one with the slits on and when the laser shoots the photons, one by one, the pattern taking shape on the screen in the back, because of the photons passing through the slits, unexpectedly differs from what we would expect. Moreover, once the scientists tried to detect what slit each photon was passing through before landing on the back screen, the pattern switched to a ballistic one, which is the one we would’ve expected in the first place, before attempting the photon route detection. Check out Wikipedia (double slit experiment) to get the nitty-gritty.

Quite incredibly, the scientists’ act of determining what route the photons had taken, played a role in the produced results. In other words, the attempt to find the route the photon (or proton or molecule) went before bashing against the rear wall, would alter the result of the experiment dramatically …to the point, that actually there were two experiments. One, with observation, giving the ballistic pattern as result, and the second one, without observation, that returns a diffraction pattern on the back screen as if the particle’s doubled itself while passing through the two slits at once behaving like a wave.

The following scientist in the programme picked up on that, explaining that the photon doubled the reality it was in instead of doubling itself. Explanation even harder to digest which implies another frame of knowledge/beliefs wrapping up the one we commonly use and feel at ease with. Coming back to the experiment, it’s like the particle was spread over the entire distance Laser -Back Screen (covering more routes, also) throughout the experiment. Property that is called “nonlocality”.

My little research didn’t take much to end up on something even more interesting (Wikipedia). Wheeler’s “delayed choice”s conceptual experiment, built on top of the 2 slits one and verified in 2007(!) asks, what if we detected the particle after coming out of one of the slits to see which slits it has just taken? No way, the experiment would once again collapse in the ballistic situation even though the decision to detect its route was decided after it had left the laser. It’s like the photon acted retroactively. It’s baffling, I know, but that also means the particle was “spread” in time also, during the experiment. That thing felt ahead of time, so to speak, that the scientist would try to catch it and consequently opted for the ballistic fashion before the decision was taken! That means that the there’s also a property of nontemporality, and I think that that is what teleporting entangled particles is about – another recent quantum gift. Anyway, these nonlocality/nontemporality properties actually quantum-lock the experiment.

Anyway, this observation thing …it’s quite difficult to swallow. At the end of the wiki-page there’s also a mention to an article written by physicists that claim that by observing the stars we could collapse them to a certain state. The next logical, although imaginative, step is ask What if we were able to take a clear look at the Early three minutes’s big bang?
Would there be the possibility to collapse it to a certain state only through the sole observation of it? Are we already “observing” the result of someone else’s previous observation?

I now look at the anthropic principle in a new light and it makes some sort of sense. I can’t believe what I’ve just written.

Love and kisses, Zaphod ;)

A way of inserting new rows using UTC_TIMESTAMP() in a DOUBLE (or BIGINT) as primary key

Recently I needed to implement a sort of queue system in a database. The PHP/MySQL script had to record new user-generated entries with a primary key based on when they were created. The problem was that UTC_TIMESTAMP(), by itself, isn’t granular enough to generate unique keys for calls requested within less than a second from each other – and, even if it was that granular, there would always be the remote eventuality of unpredictable primary key overlap (and consequent data loss) hanging over the system. So, I thought I’d keep the UTC_TIMESTAMP() value for the overall time in the primary key and append extra figures to it in order to make the key unique no matter how close two requests were. The appended extra figures represent only a correction value to the sampled datetime and are unrelated to any time measurement.

In this example, I use 2 extra-digits which account for a maximum of 100 new possible rows that can be inserted within the same second. Such limit can be extended. The column id (primary key) is a DOUBLE, here.

After trimming off the two UTC_TIMESTAMP() top digits from 2011, which leaves us with the stub “11” standing in for the year 2011, the result gets then multiplied by 100 to make room for the 2 extra-digits on the right handside. Below, it’s shown how to do that.  3 is just an example, any number between 1 and 99 will do.

SELECT (100*(UTC_TIMESTAMP()-2e13)+3);;

Someone might argue that taking the 2 top digits off makes this method work fine only up until the year 2099. Yep, that’s correct.

Let’s now go through the details of how to insert new rows with the composite key datetime + adjustment.

I need to insert a first row in the table since this example wouldn’t work without an entry’s id to compare with and I don’t want to slow down the Server’s digestion with verifying away a condition planned to be used only once and never again, at least on what I was working on then.

INSERT INTO tbl (id,data,notes) VALUES (100*(UTC_TIMESTAMP()-2e13),'test', '');

Then, it follows the snippet that generates appropriate consecutive primary keys.

INSERT INTO tbl (id,data,notes) VALUES (
(100*(UTC_TIMESTAMP()-2e13))>(SELECT id FROM tbl AS t ORDER BY id DESC LIMIT 1),
'add data',
'add notes');

The calculation of the primary key is carried out through the MySQL function IF(expr1, expr2, expr3).

The function IF(expr1, expr2, expr3) can be probably better grasped by adding some more words to it, IF(test expr, test-passed expr, no-pass expr). Better? By the way, that’s a function IF(*,*,*) not a statement IF which is different.

The conditional function, in the snippet, simply says “IF the UTC_TIMESTAMP-based key isn’t greater than the last one found in the table then someone else must’ve already created it”, so now my new key will be the last one which is already there plus 1. In this way, I’m sure that the new primary key will be unique regardless of the new entries created so far, within the same second.

You will have noticed that subqueries have also been used in the snippet above, and, as you probably know, subqueries like that can sometimes be a bit fussy to deal with because of the restrictions imposed on them. Renaming the column id FROM tbl “AS t” does the trick and makes it all hold together. Without it, an You can’t specify target table for update in FROM clause error would pop up.
Check this out for more details about subquery-restrictions.