Friday, January 31, 2014

Day 10 : Connection Counter is ticking!!

A few hours ago, finally got the connection counter to work without the need of having to use 'global', and shifted the connection modifiers to strong signals for now. However, this proves the possible modularity of the model. Over the weekend, I'll port it out some way (maybe a wrapper ?) to actually the implement aforementioned modularity and make it easily accessible.
Now I'm going to treat myself, consume a relatively large amount of candies and watch 'A Beautiful Mind' tor the N-th time. So Long.

p.s. - after working on Naiad, I can see a difference in myself where I actually care also about the quality of the code.

Day 9 : different connection -lists

Yesterday, I separated out the connections in two categories, and kept playing with it for a while.
While it still doesn't say much, but it's interesting to look at the connections, and it actually makes sense that some agents, while not densely connected, are critical for connecting two parts of the network (eg., Kite- graph) .

However, a new impediment arose. "Global" is giving me a hard-time,and the next day or two shall be spent fixing that. I'm also thinking about taking a break, and studying some Swedish over the weekend, for apparently no reason at all. So Long. 

Wednesday, January 29, 2014

Day 8 : setter/getter removed

Finally, the time was up, so I decided to go for an alternate approach and got rid of the setter/getters. Now the connection-counter can be modified through an external script, although only unitary changes at a time are possible, and i intend to keep it that way since it should be useful when we get around to computing ranks.
Not much else done today. tomorrow, I should start changing some logic in the distance, and probably make (at least) two categories of connections, weak and strong. So Long.

p.s. - made some graphs this morning to see how "rand" is working. This output shows 100 agent-nodes in a scatter histogram. 

Tuesday, January 28, 2014

Day 7 : 2-D distance metric, issues with Setters

As planned previously, I moved the connection generation from random to a 2-dimensional distance based on belief values of the nodes.

On the other front, a bit more research gave me the idea of "mimic" behaviour amongst nodes, but it needs a proper formulation, and it is still further down the road. What I need to do immediately is focus more on the implementation. It's irritating that it's been over 24 hours and I could not get the setter-getter to work as I want it to.
Decision time, 24 hours more, then I switch to alternate approach. In the mean time, code files have unresolved dependency for the "Main" control module, so they are not yet updated. So Long.

Monday, January 27, 2014

Day 6 : Connections

This morning, I went around and implemented a separate view level for the connections, and through a separate function, the fate for every possible connection is randomly chosen (using Matlab's inbuilt "randi"), going through a complexity of (n*n!).
Although not optimised, it's the most elegant model I could think of so far, as it gives a fair chance to every possible connection, without having to face the hassle of repetitions. As usual, the code is updated in the repository.

Next Up: 
  • Increment/Decrement
    • Change the Degree of the agent node (attribute - NumOfConnections) when a connection is made or severed.
    • For this, I am currently pondering on how to connect the two views. I will use setter-getters for the Node properties, it's a well accepted method and needs no advocacy. I'll try to have that as a part of the script that generates the connections, or invoke both from a separate script.
So Long. 

Saturday, January 25, 2014

Day 5 : Matlab Begins

I started porting the network to Matlab, and after doing some reading, I decided to go with classes and separate *.m functions for EVERYTHING. Not sure if this much modularity will be needed, but I hate working with long, undocumented code.

I created a basic class for agent nodes, having 2 belief values, and 1 enterprise membership, and also provided a method to generate and initialise the nodes. Each node randomly gets assigned one of the four enterprises, and two random values for belief.
So far, everything has been updated in the repository.

Next step : Assign connections. 
  • Option 1.
    • From a node-view. i.e., for EachAgent, randomly pick/assign number of connections, and generate those unique connections. but this screws up for bi-directional connections, which is important for my purpose, otherwise, the whole network would be like a big group  of people stalking each other. Which, while interesting, is a bit creepy, and let's say is "Out of Scope" for now.
  • Option 2.
    • From a connection-view, i.e., from a combination of random n-square (non-unique) possibilities for n-agent nodes, generate the unique connections. This seems the way to go. However, I should think a bit more about it.
So Long.

p.s. - While at the Spring Premiere at the Student Union last Friday, it occurred to me that it is not the best way to go analysing human networks without accounting for the social events, where the interactions between the nodes are much more likely to happen, and also to be different. 
Somehow, I should try to simulate this effect based on some Events. Something to think about and discuss with the mentor. Plus, "Simulated drunk people at a party" always looks good on the resume!! 

Thursday, January 23, 2014

Day 4 : Belief achieved, so to speak.

This morning, or rather afternoon, while waiting impatiently for my lunch, I realised that I should not go with random distance values. So I initiated the nodes with belief values and computed the distance between adjacent nodes on a One-dimensional scale as difference between the belief values (b1). It's still crude, but a sample output for 100 nodes looks like this.

Next Step : Move distance computation to Two-dimensions.
So Long.


Wednesday, January 22, 2014

Day 3 : Away from Euler, in the pits of Networking

As predicted, I have been away from the plan, and Euler Problems. Mostly been busy sleeping and catching up with the thesis work.
So I have decided to switch, and try to optimise the code for thesis as I go on, and use this blog as a running documentation for the same.

After spending 3 days fixing EPD, everything finally works, and I have decided to write prototypes for testing my hypotheses in Python, small, notebook-style scripts, and then port them to Matlab to suit the requirements for School.
I started out by making a basic list, using Evernote, obviously, and it looks like this.
To start out, I created a basic weighted node, and I realise I'll need an attribute "weight" (to act as distance) for each connection. As initially thought, I could just use the difference in the "belief values" for this weight, but I'd like to see what happens with random weights.

The Basic Network with 100 nodes and 200 random edges looks like this. The dotted lines are less than 0.5 strength while the dark ones are stronger than 0.5.


Interesting Observation :- It's funny that I am writing in a "Day X" format, because mostly these entries are made late at night. The Irony!!

Saturday, January 18, 2014

Euler : Day 2

As expected, it's weekend, and productivity went flying out the window. However, I did solve Problem 6 and 7 before signing off for the night.
Interesting observation : Time complexity went down from 2.04 sec to 0.6 s when switched from while loop to use of range function for a basic level primality test.

Now it's time to go meet the new arrivals today, let's see if I can squeeze in a few solutions as well. So Long.

Thursday, January 16, 2014

Euler : Day 1

So I solved Problem 1 - 5 today. Choice of environment was obvious for me, Python within EPD on Win7.

Interesting observations, after the second problem, I decided to check for execution times, and basic clock stamps satisfy me.  I should try and keep up with the optimisation practises to bring these times down much as possible.

However, an ethical dilemma arises regarding problem 5. I directly did the math in my head to start with a product value for all primes less than 20. It is not wrong, but to have a more generic code, I should leave it to the program to find out the primes and calculate the number. It's not significant for an upper limit of 20, but that will definitely change as this limit goes up.
Presently, Execution time is 0.06 ms, and can't say I am unhappy with that.

Oh yes, I am trying not to use any libraries, to keep stuff minimalistic, for as long as I can. Let's see how long I can keep that up.  So Long.

Ready, Set, Go

As the last semester of school approaches (yes, I still have this weekend to enjoy life as I know it), there has been a feeling somewhere in the depths of my tummy, STUFF NEEDS CHANGE.
Charmed by the society going on and blissfully keeping up with their resolutions, I went ahead and made a list. It looks like this :


  • Pin-up Notice Board : CHECK 
  • Glass Board and Markers : pending, out of budget
  • Comfortable Chair : CHECK
  • Proper, Clean work area away from the bed : CHECK
  • Proper Schedule : pending, awaiting official instructions from school
  • Eating Habits (less coffee, more not-coffee) : pending, awaiting divine intervention
So, after having acquired the props, another week went by while I continued to live happily. Finally, keeping up with the traditional rocket-principal, and after consuming whole lot of chocolate and caffeine, some inspiration and structure showed up last night. 

The original, planned notice board was nicely hanging above the bed, then a friend decided to give me another one, which is currently somewhere under the bed for the lack of availability of a nail and hammer. But the chair is unexpectedly awesome, an amazing (belated) Christmas gift from some friends. 

Stuff happened, to keep practising basic skill, I took up to Project Euler . Presently, since I have some time, it should be doable, as the self-imposed limit is 5 questions a day, which I will document here, and also at this repository

Not pushing things too far, I realise this routine will be tough to follow on weekends, but it should help redirect the time spent on the computer from shows to code practice. But as always with life, we shall see.