| | Ed:
"We'd probably get physically attacked and, since you no longer take potent anabolic steroids, I'd step up and be your bodyguard. I could hit them over the head with a poster-board displaying decades of invariant satellite temperature recordings at 8-10km altitude. Better yet, we could get Jules to come with us as security. That would keep the audience at bay, while we uproot a spurious-but-much-advertised 98% consensus of professional climatologists. Ah, but I don't want to get ahead of myself."
As an old man, I'd appreciate that; we could decide later who was Don Quixote, and who was Panza, but one thing would be for sure: in this batshit crazy tribe, we'd be tilting at windmills, complete with wind, be it man-made CO2 enhanced warming or not.
What do you call an environmentalist at an IPCC convention opening up his own personal can of "lightly carbonated" Red Bull and releasing freshly generated CO2 into the atmosphere?
Impatient, with a slight buzz.
re: Agent based modeling of rational actors... don't know. You've probably seen this, but I'd start here and look for mention of similar application of the toolsets.
http://en.wikipedia.org/wiki/Comparison_of_agent-based_modeling_software
There's an attempt to feature rate them in this compendium, only one is 'green' across all three headings, but that may not be important to you application.
You using the Eclipse IDE for Java? The current releases are quite usable. (Wasn't always the case, early attempts used to be quite klunky; but IDEs always were a convenience, not a necessity. Pure Java SDK doesn't require any IDE...)
Have you programmed in another non-OOP language prior? There is -always- a lexical/syntactical learning curve to pick up a new programming language, but there is a separate jump with OOP -- a paradigm change. The lexical/syntax details are the easiest to pick up(and generally aren't even taught in many 'programming' courses. Those are RTFM, usually on your own.) The real area of focus has to be on the programming paradigm itself-- that which carries between languages(unlike syntax/lexicon.) That is/was the biggest hurdle with OOP -- not because it is/was complicated, but because the world is/was filled with so much noise about what OOP is/was-- including what follows.
You will -really- need to pick through the poop to pull out the peanuts. But it really does boil down to a handful of concepts useful for characterizing families of behavior. It's inevitably described with terms like "encapsulation" and "polymorphism"... but eventually you boil those down to the use of terms "_has_a" and "_is_a," where every object "_is_a" at least something, and yet through either inheritance or implementing a interface, might also quite logically be a something else in a rational taxonomy. (A 'Mom' is_a 'Woman' is_a 'Person', and the actor/object 'Mom' has the behaviors of 'Mom' and 'Woman' and 'Person' and now I is_a misogynist for saying that..) Yet she might be carrying a 'Purse' which is neither a 'Mom' nor a 'Woman' nor a 'Person'; she has_a 'Purse' and can have access to the properties and actions and behaviours that a 'Purse' can provide, but she _isa 'Mom' and 'WOman' and 'Person' and can also deliver the actions and behaviours and properties that a 'Mom' or 'Woman' or 'Person' can provide.
I recommend you glom onto the _isa _hasa paradigm of looking at OOP code; one of the first things I do when trying to come up to speed on a third party development is to grasp the overall _isa/_hasa model, to understand the local forest. Most OOP environments lend themselves to this kind of analysis; it is one of the big plusses of OOP, it kind of forces complex applications to be discoverable, but you need to be wearing your _isa/_has filters and look for the relationships.
So when defining a 'Woman', the concept 'Person' is extended with the actions and properties that make a 'Person' a 'Woman', and when the concept 'Mom' is defined, is extended with the properties that make a 'Woman' a 'Mom.' But that is just a definition; a particular instance of a 'Mom' is assigned properties that may be unique to that instance of the concept 'Mom' Two instances of a 'Mom' might both be 'is_a' Mom, but they are unique instances. (This raises an interesting question in this type of modeling; to the level that concepts are modeled, how do we define 'equal?' Are instances 'equal' when all of their properties have the same values, such that their behaviours are identical in every application, or are they still unique instances even when their properties are all the same? In the real world (TRW), we never say they are the same instance, even when we say they are 'identical twins' with the same education and job skilss and weight and height and IQ and ... because ultimately we know that at some level they are still unique; so this issue of 'equal' only comes up in imperfect modeling of real things... we are not fully modeling every feature. We can get around this by defining a guaranteed unique identifier that kind of wraps up all the unmodeled properties and behaviours and declares 'this is yet a unique instance, even if all explicit properties are the same. At most it can be equivalent to another instance. In nuts and bolts implementation details, there is still the knowledge that the instance memory address is unique, but that can be an inconstant/fluid means of identity, can change over time in some languages, and so is not a good means of maintaining 'identity.' Anyway, issues like 'identity' are not as trivial as they sound when the implementation details intrude on our models of reality, and need to be understood when we apply the concept 'are equal' in our modeling languages.
In the early 90's, there used to be an early Object Oriented Programming (OOP) language called 'Actor.' It was a precursor to Java, early days of OOP. I'm not saying go look it up, it's just that, with some irony, it was actually called 'Actor.' What persists between an attempt like 'Actor' and java or c-sharp is not any lexicon or syntax, but a kind of modeling paradigm independent of lexicon or syntax. Why I point that out is, although the lexicon and syntax is crucial, it is not central; you should try to focus on the central paradigm, the story of the forest, and then implement the trees using the local syntax/lexicon.
regards, Fred
|
|