<$BlogRSDUrl$>



Orbis non sufficit


Friday, August 15, 2008

Reschedule

Ok, due to lack of interest ski trip on those other dates has been rescheduled to:

Sat 23rd - Mon 25th August

Still at Hotham.
There will be annoying crowds but oh well. Staying till monday will show you how much better the weekdays are.

Let me know on facebook ASAP if those days work for you, coz it's pretty soon and I therefore have book accomodation ASAP if we are going to go those days. It will be hard to find somewhere already I imagine.

Go! Make yourselves free!


For interests sake, check out my program:
(aww, it killed my formatting, but oh well)
My commenting may seem excessive, but some of it is physics commenting not code commenting. It really doesn't do much yet.

%%%%|SECTION 1------------------------------|%%%%
%%%%| BEGIN QUANTUM GRAPH GENERATION |%%%%
%%%%|_______________________________________|%%%%

%So, this is the beginning of my quantum graph spacetime generator. Firstly
%we need a general method for creating a quantum spacetime state. This will
%simply involve generating some amplitudes for edges states and calculating
%the resultant subgraph amplitudes.

%I will need two arrays in which to store the amplitudes, an "off (|0>)"
%amplitude array and an "on (|1>)" amplitude array. Each array will be of
%size nxn (each edge joins one of n nodes to another of n nodes) The arrays
%will be symmetric with zeros on the diagonal if we disallow
%directionality, loops and multiple connections between nodes.

%Here we have some input paramenters
n=3


%There will be 2^nedges subgraph basis states (nedges =
%number of edge states = 2*T(n-1), where T(n) calculates the nth triangular
%number.

nedges = T(n-1)
nedgestates = 2*T(n-1)
nsubgraphs = 2^nedges

%Begin array definitions:

a = zeros(n,n); %empty array for storing "off" (|0>) amplitudes
b = zeros(n,n); %empty array for storing "on" (|1>) amplitudes

%test amplitudes. Note that these amplitudes totally determine the graph properties
%(equal probablity, no phase difference)
a = [sqrt(0.5)*exp(4i) sqrt(0.5) sqrt(0.5); sqrt(0.5)*exp(2i) sqrt(0.5) sqrt(0.5); sqrt(0.5) sqrt(0.5) sqrt(0.5)]
b = [sqrt(0.5) sqrt(0.5) sqrt(0.5)*exp(8i); sqrt(0.5) sqrt(0.5) sqrt(0.5); sqrt(0.5) sqrt(0.5) sqrt(0.5)]

%Additionally I want these amplitudes listed in a vector in increasing order
%for later use. i.e. I need them in the form (assuming K4),
%[a12 a13 a14 a23 a24 a34...], we leave out many entries that are zero or
%are symmetric to other entries in this vector. Most efficient way to store
%the info.

a_vect = ones(nedges,1);
b_vect = ones(nedges,1);
k = 1; %Initialise a_vect and k
for i = 1:n
for j = (i+1):n
a_vect(k) = a(i,j); %store this amplitude in the kth slot of a_vect
b_vect(k) = b(i,j); %store this amplitude in the kth slot of b_vect
k = k + 1; %go to the next slot in a_vect
end
end


%I also will have an array to store the amplitudes associated with each
%subgraph basis state |g>. There will be 2^nedges subgraph basis states
%(nedges = T(n-1), where T(n) calculates the nth triangular number. Note we
%raise 2 to this power because each edge may be in one of two states). I
%need to be quite careful about defining which subgraph is which to reduce
%later confusion. In the interests of this I will here define a
%conventional ordering of edge states which can be used to categorise the
%subgraph states in a manageable way.

%The convention is best demonstrated with an example:
%|K4> = a12.a13.a14.a23.a24.a34|0>|0>|0>|0>|0>|0>+...
% = a12.a13.a14.a23.a24.a34|G0>+...
% = c0|G0>+...
%i.e if we order the states so that the first index remains constant while
%the second increases through it's range, then the first increments up and
%we repeat, then we achieve a consistent ordering of edge states and can
%assign the decimal system value of the binary number represented by the
%edge state zeros and ones to that subgraph state. We can then store the
%amplitude of that subgraph in the array position corresponding to that
%number. (Note the binary number will be read from left to right, so the
%least significant bit corresponds to the lowest ordered amplitude).
%Finally, there is no zeroth array element, so we shall store all the
%amplitudes in the index position one higher than the binary number they
%are associated with, i.e. amplitude for subgraph zero is stored in
%position 1, subgraph 1 in position 2 etc.

c_vect = ones(nsubgraphs,1); %array to store subgraph amplitudes in

for k=0:(nsubgraphs-1) %Cycle through the possible subgraphs
out = dec2binvec(k,nedges); %convert the subgraph number (k) to decimal, using as many bits as there are edge states (nedges). The decimal value is stored as a vector (out) with the least significant bit in the lowest position.

for j = 1:nedges %cycle through the entries of out, a_vect and b_vect (length is nedges)
switch out(j) %see if this bit is zero or one
case 0
c_vect(k+1) = c_vect(k+1)*a_vect(j)%; %if this bit is a zero, multiply by "off" amplitude
case 1
c_vect(k+1) = c_vect(k+1)*b_vect(j)%; %if this bit is a zero, multiply by "on" amplitude
otherwise
disp('ERROR, badness with decimal to binary conversion')
end
end
end

%Alright, this seems to work properly.

%%%%|SECTION 1------------------------------|%%%%
%%%%| END QUANTUM GRAPH GENERATION |%%%%
%%%%|_______________________________________|%%%%

%%%%|SECTION 2------------------------------|%%%%
%%%%| BEGIN GRAPH ANALYSIS |%%%%
%%%%|_______________________________________|%%%%

Comments:
Matlab?
 
"Each array will be of
%size nxn (each edge joins one of n nodes to another of n nodes)"


forgive me if i'm just ignorant...but, i'm assuming n is a number, in which case shouldn't it read "each edge joins one of n nodes to another of (n-1) nodes", assuming a node can't join to itself
 
Yeah Matlab. And yes anonymous, you are quite right, however although I am not allowing "loops" in the graph I still have a space for them in that matrix, for convinience. The "loop" entries will just all be zero. It's not just a waste of space tho, there are some matrix operations I need so I have to store it like that.

As a further note, having actually put some non-trivial values of n (number of nodes in my graph) into this thing (we're talking n=10, still pretty small), it seems that Matlab kind of dies. The variables go off the scale, it's a bit terrible. I need something like 250,000,000 Gb of memory to store the c_vect vector (without anything even in it) (it has phenomenally many entries and the index counter breaks anyway)
It seems I need to figure out a better way to do it or this whole thing ain't gonna work.
 
i was only anonymous because i don't have my own blogger site thing. from now on, you may call me avid reader ;)


yours affectionately,

avid reader
 
Post a Comment

This page is powered by Blogger. Isn't yours?