Once upon a time there was this small tidbit of information. A datum. Pronounced useful and thrown onto the disarray that is known as the world wide web. The datum, lonely, remained stationary - lonely - disconnected.
The datum wanted friends, so it tweeted to everyone. Messages of it's loneliness. It got a few followers. They were bots.
The datum remained in obscurity. It knew it's self worth, but it felt like the web didn't want to mesh to it. That the spiders never got to it as no-one extended a filament for the spider to traverse.
The datum, lonely, gained a group on Face Book. No-one joined it's group - who would want to be fans of this small morsel of useful information? It was as though the datum was banned from the web. But how could useful information be banned thought the datum.
Until it linked to related datum. Extending itself for a solitary, useful, datum to an interconnected set of data whose combination is infinitely more useful as the datum now relates itself historically to previously related datum, and to similar datum discussing the same subject at the same time but from different point of views.
The datum, now part of the data that makes up the web, became accepted and linked to. No longer solitary.
As information - out of context - without any means to learn of the context, is useless to the user, even if it applies to the current situation.
Wednesday, August 12, 2009
Tuesday, August 4, 2009
Introducing Topics
Each word, carefuly chosen, concisely reflects the material of the main matter without burderning the reader with details while providing a miniature conclusion based on a fraction of the information. That is the type of introduction I strive to write, however selecting words is a much more laborious process than my imagination would allow me to believe possible.
These missing introductions are the plague of the posts within this blog -- immediate ideas are written ignoring the final structure of the document. Ignoring the road map that is the introduction.
Once finalized, the introduction will scope the text, keeping it in order and coherent. Ensuring that minute details are presented in order as defined by the macroscopic view of the topic presented in the introduction.
I need to finalize the introduction to my thesis.
These missing introductions are the plague of the posts within this blog -- immediate ideas are written ignoring the final structure of the document. Ignoring the road map that is the introduction.
Once finalized, the introduction will scope the text, keeping it in order and coherent. Ensuring that minute details are presented in order as defined by the macroscopic view of the topic presented in the introduction.
I need to finalize the introduction to my thesis.
Sunday, August 2, 2009
Opinion of `Harry Potter and the Half Blood Prince' Movie
To be honest, I didn't expect much when I went to see the movie. From what I heard here and there, however there are many glowing reviews of the movie online. However, I didn't expect what came out of the movie - as such the following impression could as well be due to missed expectations (which I believed to have kept low) and not to a movie that missed it's mark.
I've read, and enjoyed, all of the Harry Potter books - the first being my favorite. Each book sets out a puzzle. May it be finding out who the evil teacher is, discovering who a given person is, finding a specific person, etc. And once the puzzle is solved -- at the last minute of course -- does the story come to an end, usually through some battle. As well, the puzzle has plenty of tracks to send the three protagonists off course, and the school-year keeps them occupied.
Upon watching the movie, something didn't feel right. The characters were there, however there was this 'puzzle' component that was missing. Of course there was a search for who the `Half Blood Prince' was, and what Malfoy was doing, and the final memory from Slughorn. There were no false roads - everything was straight-forward and clear.
I understand this movie is supposed to serve as a bridge to the other two, albeit it feels like they simplified it for the sake of making the last two better. Every major component is there, but not fleshed out. There are puzzles, but no false paths that can be deciphered until the next movie.
The movie finished off as a bridge to the next, whereas the book went out with a bang aided by a battle at Hogwarts castle between students+teachers versus death eaters with Malfoy and Dumbledore discussing amidst the chaos while Harry is stuck underneath his invisibility cloak immobilized by Dumbledore; this one had Dumbledore die and death eaters proudly running off and only killing Dumbledore. Maybe my favorite scene in the book - absent in the movie.
The other scene in the book that I can clearly recall - was that of Moaning Myrtle screaming "murder" after Harry hits Draco with the spell 'sectumsempra'. In the book - there is consequence for Harry - and Snape clearly goes for the book. In the movie, in practically the next scene Harry resolves to get rid of the book - and he just walks away from a bloodied Draco letting Snape tend to Draco's wounds.
In the end, it wasn't a bad movie, neither was it as good as it's predecessors in my opinion. My opinion has nothing to do with the quality of the movie's visuals or audio (which are superb - I wouldn't expect anything less from a big budget movie) but the chosen content. This seems to be because two scenes that I associated as memorable from the book were missing from the movie.
I've read, and enjoyed, all of the Harry Potter books - the first being my favorite. Each book sets out a puzzle. May it be finding out who the evil teacher is, discovering who a given person is, finding a specific person, etc. And once the puzzle is solved -- at the last minute of course -- does the story come to an end, usually through some battle. As well, the puzzle has plenty of tracks to send the three protagonists off course, and the school-year keeps them occupied.
Upon watching the movie, something didn't feel right. The characters were there, however there was this 'puzzle' component that was missing. Of course there was a search for who the `Half Blood Prince' was, and what Malfoy was doing, and the final memory from Slughorn. There were no false roads - everything was straight-forward and clear.
I understand this movie is supposed to serve as a bridge to the other two, albeit it feels like they simplified it for the sake of making the last two better. Every major component is there, but not fleshed out. There are puzzles, but no false paths that can be deciphered until the next movie.
The movie finished off as a bridge to the next, whereas the book went out with a bang aided by a battle at Hogwarts castle between students+teachers versus death eaters with Malfoy and Dumbledore discussing amidst the chaos while Harry is stuck underneath his invisibility cloak immobilized by Dumbledore; this one had Dumbledore die and death eaters proudly running off and only killing Dumbledore. Maybe my favorite scene in the book - absent in the movie.
The other scene in the book that I can clearly recall - was that of Moaning Myrtle screaming "murder" after Harry hits Draco with the spell 'sectumsempra'. In the book - there is consequence for Harry - and Snape clearly goes for the book. In the movie, in practically the next scene Harry resolves to get rid of the book - and he just walks away from a bloodied Draco letting Snape tend to Draco's wounds.
In the end, it wasn't a bad movie, neither was it as good as it's predecessors in my opinion. My opinion has nothing to do with the quality of the movie's visuals or audio (which are superb - I wouldn't expect anything less from a big budget movie) but the chosen content. This seems to be because two scenes that I associated as memorable from the book were missing from the movie.
Sunday, July 12, 2009
Perceived Flaw with Java
There are several things that annoy me about Java. Same goes for C# and similar languages. Albeit - I do respect the "code-behind" feature of C#.
The flaw is not security, it's not performance, it's not syntax, it's the encouraged methodology. And I'm not complaining about the inner classes used to implement interfaces to receive events (although that could be a rant on it's own). It's a philosophy that developers must break out of.
Getters and setters - I'm looking at you!
Nothing wrong with getters and setters? Hmm - let's delve deeper into the perceived problem. A getter allows code to extract values from a class, and a setter allows us to set values into a class while performing a bit of error correction. Sounds good so far.
But there's an ominous problem here - and it appears to affect most OOP languages. The getters and setters - when used improperly (happens more often than not) - bypasses the elegant concept that a class' public methods are simply a gateway to get something to happen and that the underlying implementation can change at will.
Classes should perform a (limited) set of actions and the getters/setters should reflect not the underlying implementation but what the user of the class is expecting. So often I've seen getters/setters for questionable things that clearly indicate how the underlying implementation must function. Functions made public for the sake of having them accessible by any other class (since it was convenient).
And XML serialization is making this worse, using reflection to get at the class internals by assuming variables will each have a "getValue" and a "setValue". The holy-grail of OOP - modular components that can be changed independent as long as they retain the same behavior diminishes as the getters/setters imply an implementation.
I could argue for C-style header files. However, that wouldn't make a difference - it's a method that I feel Java makes worse.
For example - for most problems - if posed correctly - can be very simple and elegant. Composition of this simpler problems using classes that expose simple interfaces can keep the program as a whole simple. However, in reality at times, it's a free-for-all with overly complex function calls... (a big picture view is required to get anything done)
Maybe I'm ranting for nothing? Maybe things need to expose their complexity?
Wednesday, June 24, 2009
Taming Time
Tick-tock the clock counted down. Tick-tock it sounded. Tick-tock it resonated down the hall.
Workers count the tick-tocks. Workers know there are a fixed number every day. Workers eagerly await their freedom.
Time is evil. Time slows down for people who do not enjoy themselves. Time lengthens the tick-tocks for the workers.
Supervisor counts the tick-tocks as well. Supervisor hopes a worker misses a tick-tock. Supervisor despises time for it's negative effect on people.
And throughout the day, supervisor tries to keep people productive, time attacks the bored workers, all of whom are listening in to the tick-tocks from the clock.
Workers count the tick-tocks. Workers know there are a fixed number every day. Workers eagerly await their freedom.
Time is evil. Time slows down for people who do not enjoy themselves. Time lengthens the tick-tocks for the workers.
Supervisor counts the tick-tocks as well. Supervisor hopes a worker misses a tick-tock. Supervisor despises time for it's negative effect on people.
And throughout the day, supervisor tries to keep people productive, time attacks the bored workers, all of whom are listening in to the tick-tocks from the clock.
Tuesday, June 16, 2009
Highly Parallel Programming Self Reminders
Threads, that's the topic of the day. Very simple? I've been experimenting with ways to distribute my code, and I've come to a few simple conclusions:
Hide Threading: Threading should be done by the underlying API. And this underlying API's threads should block so they aren't squandering CPU resources. This means that whenever the given threaded component is used, it will use CPU resources as needed.
Worker Threads: Have a few dedicated threads for the heavy lifting - and choose the number of threads based upon the number of cores that are available. All other threads should be in a nearly permanently blocked state. This means that your worker threads won't compete with the resources of the other threads.
Document: Knowing what's thread-safe is critical to writing code that won't fail in the long run.
Queues: Use a queue structure to send messages between threads. This means that a thread won't block immediately if another thread doesn't reply immediately.
Cache: Be aware of it, and code expecting the CPU to have a cache. Programs written in Java, as well as in C will benefit from being aware of the cache and the underlying structure of the system's memory. For multi-core processors, this can be the source of a speed boost (eg. L2 cache is shared among cores on Core2Duos).
Compress: Do you really need all that data to travel across the bus? Minimize data transfer when possible by reducing the number of bits needed to represent the data.
Benchmark: You don't know the ultimate gain in speed. Test your theories -- preemptive optimization may actually hurt the performance of the application. Overflowing the bus degrades performance, btw.
Use What You Need: If a single core gets the job done - then use a single core. Distributing a problem has overhead - programmer wise as well as speed-of-execution wise.
Have a Game Plan: The most important part. Know how things will be structured overall. If you can't see the whole structure in your mind, consider alternatives as it might be too complicated.
Extra thoughts as of February 24, 2015:
Tasks: Use task managers to handle multi-threading when possible. For example Grand Central Dispatch in OS X will automatically manage the number of available threads based upon available CPU across all applications.
Task Stealing: Tasks, described as a series of interdependent operations based on data transformations, allow tasks to focus on recently touched data. Task stealing, if I recall, is quite optimal and allows another core to steal tasks when it is idle from those assigned to other CPUs. Look at Cilk and Intel Thread Building Blocks as concrete implementations.
Asynchronous: I believe the OpenGL API provides an example of what to strive for in terms of APIs. Writing serial code and logic is easy, parallel is hard. Shouldn't the API run in parallel while giving the illusion of sequential execution?
Hide Threading: Threading should be done by the underlying API. And this underlying API's threads should block so they aren't squandering CPU resources. This means that whenever the given threaded component is used, it will use CPU resources as needed.
Worker Threads: Have a few dedicated threads for the heavy lifting - and choose the number of threads based upon the number of cores that are available. All other threads should be in a nearly permanently blocked state. This means that your worker threads won't compete with the resources of the other threads.
Document: Knowing what's thread-safe is critical to writing code that won't fail in the long run.
Queues: Use a queue structure to send messages between threads. This means that a thread won't block immediately if another thread doesn't reply immediately.
Cache: Be aware of it, and code expecting the CPU to have a cache. Programs written in Java, as well as in C will benefit from being aware of the cache and the underlying structure of the system's memory. For multi-core processors, this can be the source of a speed boost (eg. L2 cache is shared among cores on Core2Duos).
Compress: Do you really need all that data to travel across the bus? Minimize data transfer when possible by reducing the number of bits needed to represent the data.
Benchmark: You don't know the ultimate gain in speed. Test your theories -- preemptive optimization may actually hurt the performance of the application. Overflowing the bus degrades performance, btw.
Use What You Need: If a single core gets the job done - then use a single core. Distributing a problem has overhead - programmer wise as well as speed-of-execution wise.
Have a Game Plan: The most important part. Know how things will be structured overall. If you can't see the whole structure in your mind, consider alternatives as it might be too complicated.
Extra thoughts as of February 24, 2015:
Tasks: Use task managers to handle multi-threading when possible. For example Grand Central Dispatch in OS X will automatically manage the number of available threads based upon available CPU across all applications.
Task Stealing: Tasks, described as a series of interdependent operations based on data transformations, allow tasks to focus on recently touched data. Task stealing, if I recall, is quite optimal and allows another core to steal tasks when it is idle from those assigned to other CPUs. Look at Cilk and Intel Thread Building Blocks as concrete implementations.
Asynchronous: I believe the OpenGL API provides an example of what to strive for in terms of APIs. Writing serial code and logic is easy, parallel is hard. Shouldn't the API run in parallel while giving the illusion of sequential execution?
Sunday, April 19, 2009
Cocoa Formatters
Every time I play with Cocoa, I'm reminded of how much I enjoy the framework. It's elegant, easy to use, and usually provides a small, elegant solution to whatever I'm trying to accomplish.
Now here's what I wanted: Something that would only allow numbers to be entered within a text box while retaining compatibility with 10.4 (to code/test on my PowerBook).
My first instinct was to jump to interface builder, and link up a NSNumberFormatter to the NSTextField, launch the app, and watch what happens. Let's say I wasn't that impressed... The NSTextField would hog input until the input was valid. And I didn't want to update a text box like I used to do. I only wanted valid input as keys were pressed, not something that the user (myself) would have to think twice about as they try to comprehend an error message.
So, trolling the documents I found a nice method "setPartialStringValidationEnabled:". This is nice. Would do exactly what I wanted with minimal effort - wait, only available in 10.5...
So overloaded NSTextField in objective C, and tried to intercept the keyUp and keyDown messages from NSResponder. Hoping that if I removed all non-numerical keys from the stream, my little NSTextField would - hopefuly - not get filled with data. It didn't work.
However, NSTextField is just a front-end to NSTextFieldCell. So simply replacing the NSTextFieldCell at runtime with my own super-classed machination should work. Should. It didn't respond to NSResponder. A very interesting thing, but where does the input come from. Cocoa should be easy - there ought to have an easier way to do this - one that wouldn't make the developers from Apple cringe (if ever they were to see it).
So - again another look at NSFormatter. MacOS, since 10.0, supports a method called 'isPartialStringValid:' for subclasses of NSFormatter. After reading the docs a bit, I implemented a simple formatter where this method would only return NO. And behold, it was impossible to type anything in the NSTextField! Success!
So here's the complete implementation of my subclass of NSFormatter. It simply only allows numbers of the form [+,-][0-9]*[.]+[0-9]*. For rounding reasons, I've limited the number of digits to 12 and used doubles for storage:
Now here's what I wanted: Something that would only allow numbers to be entered within a text box while retaining compatibility with 10.4 (to code/test on my PowerBook).
My first instinct was to jump to interface builder, and link up a NSNumberFormatter to the NSTextField, launch the app, and watch what happens. Let's say I wasn't that impressed... The NSTextField would hog input until the input was valid. And I didn't want to update a text box like I used to do. I only wanted valid input as keys were pressed, not something that the user (myself) would have to think twice about as they try to comprehend an error message.
So, trolling the documents I found a nice method "setPartialStringValidationEnabled:". This is nice. Would do exactly what I wanted with minimal effort - wait, only available in 10.5...
So overloaded NSTextField in objective C, and tried to intercept the keyUp and keyDown messages from NSResponder. Hoping that if I removed all non-numerical keys from the stream, my little NSTextField would - hopefuly - not get filled with data. It didn't work.
However, NSTextField is just a front-end to NSTextFieldCell. So simply replacing the NSTextFieldCell at runtime with my own super-classed machination should work. Should. It didn't respond to NSResponder. A very interesting thing, but where does the input come from. Cocoa should be easy - there ought to have an easier way to do this - one that wouldn't make the developers from Apple cringe (if ever they were to see it).
So - again another look at NSFormatter. MacOS, since 10.0, supports a method called 'isPartialStringValid:' for subclasses of NSFormatter. After reading the docs a bit, I implemented a simple formatter where this method would only return NO. And behold, it was impossible to type anything in the NSTextField! Success!
So here's the complete implementation of my subclass of NSFormatter. It simply only allows numbers of the form [+,-][0-9]*[.]+[0-9]*. For rounding reasons, I've limited the number of digits to 12 and used doubles for storage:
@implementation X_NumberFormatter
- (BOOL)isPartialStringValid:(NSString *)partialString newEditingString:(NSString **)newString errorDescription:(NSString **)error
{
int x;
int l = [partialString length];
BOOL foundDecimal = NO;
int curPostDecimal = 0;
for (x=0; x
{
unichar curChar = [partialString characterAtIndex:x];
if (!(curChar >= '0' && curChar <= '9') && curChar != '.' &&
!(x ==0 && (curChar == '+' || curChar == '-')))
return NO;
if (curChar >= '0' && curChar <= '9')
{
curPostDecimal++;
if (curPostDecimal > 12)
return NO;
}
if (curChar == '.')
{
if (foundDecimal)
return NO;
foundDecimal = YES;
}
}
return YES;
}
- (BOOL)getObjectValue:(id *)anObject forString:(NSString *)string errorDescription:(NSString **)error
{
*anObject = [NSNumber numberWithDouble:[string doubleValue]];
return YES;
}
- (NSString *)stringForObjectValue:(id)anObject
{
if (![anObject isKindOfClass:[NSNumber class]])
return nil;
return [NSString stringWithFormat:@"%1.12g", [anObject doubleValue]];
}
@end
Subscribe to:
Posts (Atom)