OFSET Planet (English only)

Dr. Geo II 11.06 is ready for download. The release come with version for Linux/Windows/MacOSX and XO OLPC kid laptop. Read the change log to know more about the fixes and features.

You can watch the video presentation of Dr. Geo II 11.06:

Download the video

Trinity term (the 3rd) has just started in Oxford, and I (Wybo) have just handed in two 5000-word papers.

The first paper is about circadian (24-hour scale) time-effects on Hacker News. Its main hypothesis is that the time at which people arrive on the site (greatly) impacts whom they are most likely to interact with. This because replies that make very similar points as previous replies to the same post, are generally not appreciated very much, and visitors thus can only (productively) reply to relatively new posts (not older than 2 hours).

Some time-pressure effects were indeed found, both on the micro-scale of interactions between prolific users (more than 25 posts in 40 days), and on the aggregate level, in 3-hour time-windows, where there was greater reciprocity and transitivity (friends of friends becoming friends). Even the phased introduction of daylight saving time between the US and UK (UK is 2 weeks later) was found to have a measurable impact on the community-structure.

Circadian rhythms thus do have an impact, even if a small one, on the reply-relationships that form (see the paper for limits and possible alternative explanations).

A very short video of the network over a day (aggregate for 40 days), and its fragmentation by time, can be seen below:

<object height='278' width='450'><param name='movie' value='http://www.youtube.com/v/NFbzLrqcwW4?hl=en&fs=1&ap=%2526fmt%3D22'></param><param name='allowFullScreen' value='true'></param><param name='allowscriptaccess' value='always'></param><embed allowfullscreen='true' src='http://www.youtube.com/v/NFbzLrqcwW4?hl=en&fs=1&ap=%2526fmt%3D22' allowscriptaccess='always' type='application/x-shockwave-flash' height='278' width='450'></embed></object>

In addition - specifically for this blog-post - I graphed the best time to reply to comments, and the best time to create threads, both in terms of their expected ratings (the average ratings). This data was from just before karma-ratings for comments were hidden. See the graphs below:

Average ratings for replies (posts that are comments at any level in the thread) created at each hour of day (in UTC). Notice how little variation there is.

Average ratings for threads created at each hour of day (in UTC). Again notice the very modest variation.

As can be seen there is not really a best time to post, because ratings are roughly constant during the day (though 19:00 UTC is not the worst time and there are some more variations during the week (especially Saturday evenings in US timezones are lower rated)).

This relative lack of variation is (some) evidence against concerns about overnight threads standing less of a chance, that were expressed in this HN thread.

A possible reason for there being so little variation, is that when more people visit and create threads, threads are on the homepage for shorter periods (turnover is higher), and thus about the same number of people see, and rate them at any time. See how the gap in thread-longevity precedes the peak creation-period in the graphs below.:

Threads created at each hour.

Time on the frontpage for threads created at each hour (and on the frontpage for at least one hour).

The paper can be downloaded here (30mb, pdf, lot of HQ images). The tools (in Ruby 1.8) used in the research are available here (though they are literally a bit rough around the edges). And the full anonymized dataset (to the extent that removing users nicknames is sufficient, yaml file format) can be downloaded here.

The second paper was about how an online global advisory parliament employing proxy-voting as its voting-mechanism, could improve political decision-making. And secondly it is about what methods might be employed to make it more likely to attain critical mass, such as integrating it with Facebook, and making it follow the agenda of real parliaments & summits rather than setting its own.

Critical mass in thread-based platforms/forums is my thesis-topic. More on this later, but a taste of what I am working on can already be had from this JS + HTML 5 canvas, agent-based simulation of users posting on a forum.

As of this summer I will be working for Academia.edu, based in downtown San Francisco, California.

Academia.edu is a Facebook/LinkedIn for academics, and one that might very well change the way scholars communicate and work. Besides social networking functionality, it also offers features specific to the academic world, such as commenting on papers, following research-interests, and it has more in the pipeline. Academia currently has over 270.000 users, a couple of million in funding, and is rapidly growing.

The people behind Academia are great. My H1B visa just came through. And as some I talked to might have heard earlier, the (decent) job-offer was made a couple of months ago. So Silicon Valley it is :-)

In the meantime Hilary term (2nd term) has just ended in Oxford.

Besides it having been another splendid 8 weeks at the Oxford Internet Institute, it was intense, and I learned a lot. Mini-conferences, seminars, and lectures by world-class speakers, as well as good dinners, walks through Magdalen deer park, and debates (and even a ball) at the Oxford Union, again complemented the experience: In all, academic life as it should be :-) (& my grades have not been bad so far).

We’ve just had our last exam (in statistics), and apart from my thesis on critical mass (+ thesis-seminars of next term), there are two large essays left to write (on the impact of timezones in online communities, resp. on critical mass in online politics) before the start of next term (so we don’t have much of a break ;-). But I am looking forward to writing them…

The smaller essays I wrote so far were on the validity of online surveys, the opportunities posed by online experiments (both summative = for grades), on the digital natives debate, and finally one on why people contribute to online political discussion forums. Not that anybody would want to read these :)

Finally, I might be committing a few minor updates to LogiLogi soon (don’t have as much time to develop as I used to).

Comparing the sizes of the DrGeo II (Smalltalk) and Dr. Geo 1.1 (C++) releases, the former weights about 23MB and the later 1MB. It is an important difference, but we are not comparing the same things...

With Dr. Geo II, in 23MB we have the executable, the source code of Dr. Geo itself, the source code of the Smalltalk language and environment, the developer tools with source code editor, compiler, inspector and debugger. THe only sources not included is the small VM C version, but don't worry most if it is Smalltalk code converted to C.

So if we want to compare fairly, we should add a fews tools to Dr. Geo 1.1:

• the Emacs editor 22-30MB
• Glibc 3MB
• Glibc-dev 1MB
• GCC 5MB
• G++ 1.5 MB
• GDB 2.5 MB
• Misc libraries, mostly shared ones so we can not count, expect for the -dev versions, anyway forget about it there are numerous

The total is now well above 40 MB, and I did not include the sources of GCC, GDB, EMACS, in DrGeoII we also have the source of the Smalltalk environment...

If Dr. Geo was written in JAVA, the addition will be around 100MB for the JRE then ECLIPSE, 120MB. What will be the number ? More than 220MB, without again including the source code of Java itself...

After all Dr. Geo II is a pretty neat and small distribution. Oh and yes Dr. Geo II's 23MB counts for three OS Linux/Mac/Windows... To test for real

The Greenpeace Guide to Greener Electronics ranks the 18 top manufacturers of personal computers, mobile phones, TVs and games consoles according to their policies on toxic chemicals, recycling and climate change.

Nokia is ranked #1, that's the way to be a cool company! Sony is #2, Apple #9. Damn shit! Stop spending millions in brain washing marketing, just spend millions to produce better product.

Dr. Geo comes with a few power tools related to programming. Since its first incarnation, Dr. Geo is enriched with open doors to let the user explores new way to use Dr. Geo. The first version of Dr. Geo was developed in C++, with that version the power tools came under the form of a Scheme interpretor embedded in Dr. Geo. This Scheme was GNU Guile and it gave freedom to write script or programmed sktech with the scheme language.

This language was interesting to write beautifully mathematically described interactive sketch. For example a nice recursive defined construction:

(new-figure "Spirale")

(define (square p1 p2 p3 p4 n)
  (let* ((s1 (Segment "" extremities p1 p2))
         (s2 (Segment "" extremities p2 p3))
         (s3 (Segment "" extremities p3 p4))
         (s4 (Segment "" extremities p4 p1))
         (A (Point "" on-curve s1 1/10))
         (B (Point "" on-curve s2 1/10))
         (C (Point "" on-curve s3 1/10))
         (D (Point "" on-curve s4 1/10)))
     (send A masked)
     (send B masked)
     (send C masked)
     (send D masked)
     (if (> n 0)
       (square A B C D (- n 1)))))

(lets Point "M" free 5 5)
(lets Point "N" free -5 5)
(lets Point "O" free -5 -5)
(lets Point "P" free 5 -5)

(square M N O P 30)

One problem was the programming environment; indeed the user must use an external text editor and try to interpret the figure within Dr. Geo. In case something went wrong, the feedback was low and it was not possible to fix the code directly from Dr. Geo. As of today other interactive geometry software are proposing programming feature. For example, CARMetal is now proposing the Java Script language to write programmed figure with an external text editor.

I noted an additional problem: the binding between the scripting language and the language used to write the interactive geometry software prevents full transparency and inter-coupling between the internal geometric model and the effect the user wants to achieve with the scripting language.

With the new Dr. Geo II, I addressed both problems.

First, Dr. Geo II and user scripting use the same language and environment: Smalltalk. From Dr. Geo II script it is therefore trivial to use 100% of the geometric model interface. Very recently a math teacher explained me he wanted to compute the closest point on a line to an arbitrary point. When browsing the model source code directly from the Dr. Geo II application itself (with the class browser), he found out the closestPointTo: polymorphic method, and he wrote:

|figure a b d m p|
figure:=DrGeoCanvas new.
a:=figure point: (-2)@1.
b:=figure point: 3@3.
d:=figure line: a to: b.
d color: Color blue.
m:=figure point: 1@(-1).
p:=d mathItem closestPointTo: (m mathItem point).
p:=figure point: p.

Next, when writing the script, the user enjoys the full Smalltalk development machinery: class browser to write script, debugger to execute step by step faulty script, inspector to examine geometric item internal state. All the machinery is accessible directly from Dr. Geo II itself. The 11.03 release will contain in the world menu entries to these tools.

As I found out users want and can dig deeply into the Dr. Geo II model, it appeared the users want to programmatically define point whose coordinates are updated with an arbitrary piece of Smalltalk code. This idea is very neat as it push on step further the concept of user power tools. The previous code sample showed how to compute the coordinates of a closest point. Nevertheless, it is a one shot calculus, when the user modifies the resulting sketch with the mouse, the closest point is not updated any more. Therefore we need to teach Dr. Geo II how to update this point. To do so we just use block closure and we pass the block to the point definition. Each time Dr. Geo needs to update the sketch, it will execute this block of code. So if we modify just a little bit the previous example, it will look like:

|figure a b d m p|
figure:=DrGeoCanvas new.
a:=figure point: (-2)@1.
b:=figure point: 3@3.
d:=figure line: a to: b.
d color: Color blue.
m:=figure point: 1@(-1).
p:= figure 
   point: [:parents | parents first closestPointTo: parents second point]
   parents: {d . m}.

More about Dr. Geo II can be found in its documentation http://documentation.ofset.org/drgeo2/fr.

Enjoy!