Re: [FRIAM] Fwd: ABM
Well, for the knowledgeably ignorant among us... what the heck is 'object oriented' programming anyway. All the code looks like code to me, and other than having a few more sub-routines I don't understand the purpose or design of... what's changed other than standardizing a few protocols across platforms? Phil Henshaw .·´ ¯ `·. ~~~ 680 Ft. Washington Ave NY NY 10040 tel: 212-795-4844 e-mail: [EMAIL PROTECTED] explorations: www.synapse9.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marcus G. Daniels Sent: Friday, June 01, 2007 4:06 PM To: The Friday Morning Applied Complexity Coffee Group Subject: Re: [FRIAM] Fwd: ABM Douglas Roberts wrote: I still can't help but feeling that in general, *way* too many words are being used to describe ABM (and IBM) methodologies. The underlying concept of object-oriented software design as the basis for ABM simulation architecture is just so straight forward and intuitive that I am repeatedly amazed at how people continue to make such a big, mysterious deal out of it. For some reason many ABM enthusiasts feel the need to introduce basic programming and computer science to their peers in their own peculiar and impoverished language. Why OOP gets embraced in particular completely baffles me and much of it is inappropriate for modeling. (e.g. rigid inheritance) I suspect it has to do with the need many perceive to learn and use toolkits. FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
Re: [FRIAM] Shift happens
Phil Henshaw wrote: Learning in an endless classroom where the teacher give out % increases in homework every day, however, tends to eventually destabilize. Teacher gonna grade it all? nature has a real easy method of grading... Badly engineered things break, and unsustainable behaviors fail, species die, etc. Nature can have hard constraints and in some sense an absolute grading scale. On the interfaces of social systems, though, there is no choice but to grade on a curve (e.g. the job market is only as good as the people in it). FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
Re: [FRIAM] Fwd: ABM
Here's a couple of sites that could be worth checking out Phil: http://www.google.com/search?hl=enq=object+oriented+programmingbtnG=Google+Search http://en.wikipedia.org/wiki/Object-oriented_programming Robert On 6/2/07, Phil Henshaw [EMAIL PROTECTED] wrote: Well, for the knowledgeably ignorant among us... what the heck is 'object oriented' programming anyway. All the code looks like code to me, and other than having a few more sub-routines I don't understand the purpose or design of... what's changed other than standardizing a few protocols across platforms? Phil Henshaw .·´ ¯ `·. FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
Re: [FRIAM] Evoc workshops this summer
Sounds neat, and amazingly inexpensive too! I couldn't tell from the blurbs which side of 'the great debate' they fall on though. That a 'diagram' is at the center of design has long been a matter of popular awareness in the tales of the 'napkin sketch' that informed the design of many a great masterwork. It would be the same for the 'napkin sketch' in which a programming idea is first conceived too. As I see it these iconic diagrams provide a pivotal question, really, guiding the creativity of a small then growing team of people who end up producing an instrument of instructions (aka 'the drawings' or 'the program') for a group of builders (or users) to take different pieces of and carry out the design intent each in their own way. I hope evoc isn't missing that aspect of 'the diagram', as a reference point for an expanding learning process involving many contributors exploring an environment with it. I'm mentioning this, not only because design and natural system growth processes have lots in common as learning processes. I also spent the last year covering for the world's leading parametric modeling package because it was quite incapable of showing more than one level of complexity. It experienced extreme ballooning file size and programming time when we stepped over the line, and therefore could not show how anything connected. The program engineers put sort of a wall where they made the software's own method of connecting things with no regard to materiality that would have been quite pointless to try to break. I think the 'magic' of the diagram generally is not in how it's followed, but how it's not! :,) There are marvelous applications for these new tools, but they'll never be good at representing the many inherent scales of complexity of anything real, and the survivors of the shakeout will be those that stick with what they do well and learn to collaborate with others. Phil Henshaw .·´ ¯ `·. ~~~ 680 Ft. Washington Ave NY NY 10040 tel: 212-795-4844 e-mail: [EMAIL PROTECTED] explorations: www.synapse9.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Guerin Sent: Friday, June 01, 2007 5:11 PM To: friam@redfish.com Subject: [FRIAM] Evoc workshops this summer Two former UNM Architure students, Aric Grauke and Derrick Ballard, will be conducting what looks like a fun series of workshops this summer. Check them out! http://evoc.us/workshops.htm -Steve --- -. . ..-. .. ... - .-- --- ..-. .. ... [EMAIL PROTECTED] www.Redfish.com 624 Agua Fria Street, Santa Fe, NM 87501 mobile: (505)577-5828 office: Santa Fe, NM (505)995-0206 / London, UK +44 (0) 20 7993 4769 FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
Re: [FRIAM] Fwd: ABM
I don't seem to be receiving all of the messages on this thread, which makes it a bit difficult to follow who said what. It appears from the below that somebody (Marcus? Surely not!) was grumping about OOP as an ABM implementation framework. Agents in an ABM are (or should be*) software objects that correlate to their real-world counterparts at a level of resolution that is defined by the requirements of the problem to be solved by the simulation. Once implemented, these software agents interact with other agents in the model at a level of resolution and granularity that is again defined by the model requirements. This is how my colleagues, and in fact most other ABM developers that I know have been developing ABMs for quite a while. We have found that OO methodologies are best suited to ABM implementation, as compared to, say FORTRAN, COBOL, PL-1, Pascal, LISP, assembly language, or whatever your particular favorite procedural programming language happens to be. Whether or not you prefer C++, Java, Charm++, Lisp+Colors, Lisp+CLOS, or whatever your favorite OO development environment is was not the focus of my original claim that OO methodologies embody the essence of ABM design best practices. The point was that in order to implement in software simulation agents that are corollaries of real-world objects at some defined level of granularity, you need an object oriented software development environment. (Duh! ;-o)) Issues such as how an OO environment implements OO features, such as inheritance, method overloading, containment, data members and typing, function members, and all the other tricks of the OO trade that allow the developer to use polymorphism to create a suite of agents that can satisfy the analytical requirements of the completed ABM was intended to be the topic of some other flame war! ;-} --Doug -- Doug Roberts, RTI International [EMAIL PROTECTED] [EMAIL PROTECTED] 505-455-7333 - Office 505-670-8195 - Cell [*Footnote from the (or should be) above: I know people who have written applications with no object-oriented technologies at all, using FORTRAN or C, (or worse, purely procedural Java) and who claim to have developed an ABM. I contend, that while they may have developed a really neato simulation, it isn't an ABM. Where are the agents? Rows of an array? Elements of a struct? An array of structs? I really don't think so. Sure, you can emulate an OO environment in C with structs and function pointers, and you can even call it an OO implementation. But it's not. And please, let's save the topic of object-oriented FORTRAN for its own special flame war!] On 6/1/07, Prof David West [EMAIL PROTECTED] wrote: it is perhaps inappropriate to comment on a discussion before posting an introduction (as I was asked to do when I joined the list) but I cannot resist. (I will post an intro tonight.) As an unmitigated object bigot I would claim that there is nothing in agents (or aspects for that matter) that did not exist in objects as objects were supposed to be. The fact that objects were hijacked and emasculated by C++ (later Java) and data modelers (UML) explains much of the bafflement: perhaps. On Fri, 01 Jun 2007 14:05:44 -0600, Marcus G. Daniels [EMAIL PROTECTED] said: Douglas Roberts wrote: I still can't help but feeling that in general, *way* too many words are being used to describe ABM (and IBM) methodologies. The underlying concept of object-oriented software design as the basis for ABM simulation architecture is just so straight forward and intuitive that I am repeatedly amazed at how people continue to make such a big, mysterious deal out of it. For some reason many ABM enthusiasts feel the need to introduce basic programming and computer science to their peers in their own peculiar and impoverished language. Why OOP gets embraced in particular completely baffles me and much of it is inappropriate for modeling. (e.g. rigid inheritance) I suspect it has to do with the need many perceive to learn and use toolkits. FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
[FRIAM] ABM - OO
On Fri, 01 Jun 2007 19:09:05 -0600, Marcus G. Daniels [EMAIL PROTECTED] said: Prof David West wrote: As an unmitigated object bigot I would claim that there is nothing in agents (or aspects for that matter) that did not exist in objects as objects were supposed to be. Ideally, agents ought to have the ability to function as individuals without coordination through schedulers, top down event loops, etc., the ability to change their functioning over time (change their set of active methods or implementations of them), and the ability to move around and adapt to an environment. Seems to me multithreaded CLOS has all this, but not all of that is thanks to objects. So how were objects supposed to be? Fully autonomous, intelligent, virtual computers. Intelligence included meta-intelligence (reflection). Of course this was a metaphor and and all implementations (including Smalltalk and Self) fell somewhat short in the early years. When ParcPlace finally realized that Java was a threat and not just a toy they released their lab technology that made the metaphor 95% realizable, but people had already stopped listening. An object should function as an individual (classes, class hierarchies were a kludge to facilitate semi-efficient implementation), should contain within itself the ability to work with other objects to obtain resources (memory, bus, cpu), handle its own message queuing, add/delete functions and knowledge at run-time, move, and adapt. A Smalltalk expression should be a first class object, hence be modifiable at run-time (through the actions of itself or other objects) and a Smalltalk program should be nothing more than a first class ordered collection - also modifiable at run-time. The only dependency to non-objectiveness is reliance on an intepreter - which can be extremely small and efficient. Objects should be able to interact with bare hardware and not rely on OS or other environments - like the Smalltalk image. I would content that all of this was possible in the nineties in Smalltalk. Not much of it has been utilized outside of the European Squeak (Alan Kay and Dan Ingalls rewritten Smalltalk) community. davew FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
Re: [FRIAM] Fwd: ABM
On Fri, 01 Jun 2007 19:09:05 -0600, Marcus G. Daniels [EMAIL PROTECTED] said: Prof David West wrote: As an unmitigated object bigot I would claim that there is nothing in agents (or aspects for that matter) that did not exist in objects as objects were supposed to be. Ideally, agents ought to have the ability to function as individuals without coordination through schedulers, top down event loops, etc., the ability to change their functioning over time (change their set of active methods or implementations of them), and the ability to move around and adapt to an environment. Seems to me multithreaded CLOS has all this, but not all of that is thanks to objects. So how were objects supposed to be? Fully autonomous, intelligent, virtual computers. Intelligence included meta-intelligence (reflection). Of course this was a metaphor and and all implementations (including Smalltalk and Self) fell somewhat short in the early years. When ParcPlace finally realized that Java was a threat and not just a toy they released their lab technology that made the metaphor 95% realizable, but people had already stopped listening. An object should function as an individual (classes, class hierarchies were a kludge to facilitate semi-efficient implementation), should contain within itself the ability to work with other objects to obtain resources (memory, bus, cpu), handle its own message queuing, add/delete functions and knowledge at run-time, move, and adapt. A Smalltalk expression should be a first class object, hence be modifiable at run-time (through the actions of itself or other objects) and a Smalltalk program should be nothing more than a first class ordered collection - also modifiable at run-time. The only dependency to non-objectiveness is reliance on an intepreter - which can be extremely small and efficient. Objects should be able to interact with bare hardware and not rely on OS or other environments - like the Smalltalk image. I would content that all of this was possible in the nineties in Smalltalk. Not much of it has been utilized outside of the European Squeak (Alan Kay and Dan Ingalls rewritten Smalltalk) community. davew FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
Re: [FRIAM] Fwd: ABM
Rather than attempt a definition, per se, consider when and where you can observe differences between OO and say procedural programming. At the level of post compilation / interpretation instructions - none, can't be. At the level of a single statement or expression - very minimal, syntax and idiom. At the level of a collection of statements (program) - far fewer lines of code (order of magnitude or more), no explicit loop constructs, zero case statements, no nested-IF statements, very few IF statements at all, no type declarations, etc. At the level of modularization - very different distribution of code across a set of objects than across a set of modules, no centralized control (master control module, main routine, etc.). At the level of conceptualization - major differences in how objects are identified and specified. Complete absence of data - Everything is an object! davew On Sat, 02 Jun 2007 10:13:19 -0400, Phil Henshaw [EMAIL PROTECTED] said: Well, for the knowledgeably ignorant among us... what the heck is 'object oriented' programming anyway. All the code looks like code to me, and other than having a few more sub-routines I don't understand the purpose or design of... what's changed other than standardizing a few protocols across platforms? Phil Henshaw .·´ ¯ `·. ~~~ 680 Ft. Washington Ave NY NY 10040 tel: 212-795-4844 e-mail: [EMAIL PROTECTED] explorations: www.synapse9.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marcus G. Daniels Sent: Friday, June 01, 2007 4:06 PM To: The Friday Morning Applied Complexity Coffee Group Subject: Re: [FRIAM] Fwd: ABM Douglas Roberts wrote: I still can't help but feeling that in general, *way* too many words are being used to describe ABM (and IBM) methodologies. The underlying concept of object-oriented software design as the basis for ABM simulation architecture is just so straight forward and intuitive that I am repeatedly amazed at how people continue to make such a big, mysterious deal out of it. For some reason many ABM enthusiasts feel the need to introduce basic programming and computer science to their peers in their own peculiar and impoverished language. Why OOP gets embraced in particular completely baffles me and much of it is inappropriate for modeling. (e.g. rigid inheritance) I suspect it has to do with the need many perceive to learn and use toolkits. FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
Re: [FRIAM] Fwd: ABM (Object-Oriented)
That WIKI definition http://en.wikipedia.org/wiki/Object-oriented_programming will leave you confused if youre learning OO for the first time. Heres a hard physical-sciences analogy: * In physics, you have Statics and Dynamics. * In biology, you have Anatomy and Physiology. * In molecular biology, you have Structure and Function. * In languages, you have Nouns and Verbs. * In chaos theory, you have the system (e.g. a differential equation), and its phase space http://en.wikipedia.org/wiki/Phase_space . * In general, you have the part that doesnt change, and the part that does. In computers, you also have the part that doesnt change. Depending on the vernacular context, these static parts are called a Types, Structures, Schema, Address locations, Code/Instruction Libraries, and Classes. You also have the part that does change. Again, depending on the circle of nomenclature, these dynamic parts are called Values, State, Execution/Run, and Objects. When talking about code, the actual instructions are the static part, and stored in memory (or disk). The actual execution of this code is the dynamic part and run by a processor (or virtual runtime environment). A dynamic part always presupposes a static part. You cannot understand a VERB unless a NOUN is implied. One must study anatomy first before physiology; numbers before functions; etc. Programming languages, like mathematics, is a method for humans to transmit these concepts and ideas to other humans via an alphabet or symbolic scheme. Compilers transform programming languages into that which a computer can understand. This is how computational science goes one step further than mathematics. All languages (programming, mathematical, and natural) must model both the statics and the dynamics of their system when describing it. Natural languages combine nouns and verbs to get sentencestheir smallest unit of information. Programming languages combine structures and code to get functions. A subroutine is a function with no return value. Different naturally languages have different syntax. German ends sentences with verbs. English puts them closer to the beginning. Programming languages have similar analogies too. Structured programming languages (Pascal, C, FORTRAN, LISP) begin with functions that operate on specific structures (called parameters). They are verb-oriented in nature. Object-oriented programming languages (Java, C#, CLOS) begin with structures (called classes) that send messages to methods. They are noun-oriented in nature. In a structured programming language, I might write: FLIP(Pancake, Quickly) In an object-oriented programming language, I would write Pancake.FLIP(Quickly) For an English analogy, we have an obvious noun (the subject) called Pancake. Theres a verb: To Flip. We have parameters that we pass in to the function call to modify its behavior. If the parameter is a constant, like Quickly, we call it an adverb. If it is another object, we call it a direct object, or indirect object, or prepositional objectdepending on its English use. Properties of an object are called adjectives. When you see a declaration in code that looks like this (regardless of whether its structured or OO): int i = 5 to declare an integer called i that contains the value 5, int is the class (or structure, or type) and i is the object. 5 is the initial state of the object. If you want to convert this number to a string in a structured programming language, you might write this: ToString(i) To do the same in an object-oriented language, youd write i.ToString() Its all syntax! Just like there is nothing in English I cant say in German, theres no system modeled in an object-oriented programming language that I cannot express in a structured programming one. In case you read articles on the net, here are some vocabulary use cases: * Classes store the static non-changing parts of a system in memory (or disk). Classes contain static structures (or types) called fields or attributes, and static code called methods. * Objects are classes that are being run by the processor (or the virtual runtime environment). Their fields (called properties) have actual values (the dynamic parts). This is why we say that objects have state. * The same class can be copied into memory multiple times (called instances, or just objects) each being submitted to a processor and each having different state. This is why we say that objects have identity. * Every method in a class operates on a specific object instance of it. This is why we say that objects have behavior. When a method is executed, it is called a message. * Static methods; dynamic messages. Static fields (or attributes); dynamic properties. Static types (or schema); dynamic state. To understand ABMs, like understanding anything, I suggest this
[FRIAM] introducing dave west
Hello FRIAM community, My name is dave west. Some relevant factoids about me: My undergraduate education was in Asian Philosophy (mostly Buddhism and Taoism and their intersection) and Mysticism at Macalester College in St. Paul Minn. I have been a professional software developer since 1968 and an academic since 1988. Returned to school in 1985 at the University of Wisconsin at Madison, earned MA in cultural anthropology, MS in computer science, and a Ph.D. in Anthropology (de facto cognitive science with a dissertation committee of three anthropologists, two computer scientists, psychologist, and linguist). First use of complexity ideas was in my doctoral dissertation -1988 - where I was proposing a model of cognition called vTAO (virtual Topographic Adaptive Organism). First publication was in AI Magazine (1989), a two part article on metaphors of mind. Became an academic at University of St. Thomas (St. Paul, MN - not Virgin Islands alas) advanced to Professor, move to NM to start new program in IT at New Mexico Highlands (just in time for them to go bankrupt and deal with a string of interim presidents). Finally succeeded in starting a radically different software degree only to have Manny Aragon arbitrarily cancel it in order to get rid of carpetbagger faculty. Currently working with the College of Santa Fe to create fundamentally (some of the radical differences at Highlands will wait a few years at CSF) different program in software development, including BA degree in software dev, MBA in software dev (will eventually be an MFA), and a MBA in technology transfer and innovation management. Book published, Object Thinking, by Microsoft Press Professional, 2004 Book underway, Developing Systems, (reinventing software development using complexity metaphors if not theory, agility, and art) have attended two Friday AM meetings about two weeks ago, will be back again next week. davew FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
Re: [FRIAM] Fwd: ABM
Douglas Roberts wrote:
Agents in an ABM are (or should be*) software objects that correlate
to their real-world counterparts at a level of resolution that is
defined by the requirements of the problem to be solved by the
simulation. [..]
As a practical matter, most object oriented programming involves stuff
that either acts or is acted upon.
I'm not very happy with that -- all these ad-hoc assignments to state
variables in objects. A simulation that does the same thing with
transformations of objects (including singletons like some shared space)
is a description of a process that is closer to math. Clear inputs and
outputs and specific mechanisms in between the two.
[*Footnote from the (or should be) above: I know people who have
written applications with no object-oriented technologies at all,
using FORTRAN or C, (or worse, purely procedural Java) and who claim
to have developed an ABM. I contend, that while they may have
developed a really neato simulation, it isn't an ABM. Where are the
agents? Rows of an array? Elements of a struct? An array of structs?
I really don't think so.
Throw in some #omp for's above the loops on a parallel machine to get
non-determinism..
#include stdio.h
#include stdlib.h
#define MOSTFUEL 100
typedef struct agent { int work; int fuel; } agent_t;
void init (agent_t *agent) {
agent-work = 0;
agent-fuel = rand () % MOSTFUEL;
printf (agent %p has %d units of fuel\n, agent, agent-fuel);
}
void step (agent_t *agent) {
if (agent-fuel 0) {
printf (agent %p working\n, agent);
agent-work++;
agent-fuel--;
} else {
printf (agent %p out of juice\n, agent);
}
}
main ()
{
int N = 10;
int steps = 50;
int i, j;
agent_t *agents = malloc (sizeof (agent_t) * N);
if (!agents) abort ();
for (i = 0; i N; i++) init (agents[i]);
for (j = 0; j steps; j++)
for (i = 0; i N; i++) step (agents[i]);
return 0;
}
Sure, you can emulate an OO environment in C with structs and function
pointers, and you can even call it an OO implementation. But it's not.
For example, an Objective C compiler just converts [obj msg] in user
source code into implicit C calls of sendMsg(obj,msg). sendMsg is just
an ordinary C function that uses a hash to get the right function
pointer. Then there is a bit of bookkeeping to set up the lookup
tables. Yes it could all be done in C with a few coding conventions,
such as with http://users.pandora.be/stes/compiler.html
And please, let's save the topic of object-oriented FORTRAN for its
own special flame war!]
Fortran 2003 seems like it could be a fine programming language for
agent models. It has all the common OOP features. An argument for
Fortran, I suppose, would be superior numerical performance. I doubt
it would be that big of a win, though, due to the fact that agent codes
tends to be rate limited by memory latency and CPU indirect mispredicts,
more than poor code generation of particular loops.
Consider the features of an implementation like this:
http://www.lahey.com/lf71/netwtpr1.htm
e.g.
module
! Define a type (class) called Greyhound that extends
! the Dog class defined in C# code below, and is part of
! the VirtualDog namespace
type, extends( VirtualDog%Dog ), namespace( VirtualDog ) :: Greyhound
contains
! Declare a class method (procedure); the 'pass'
! attribute makes it an instance (dynamic) procedure
procedure, public, pass :: Bark
end type Greyhound
contains
! Define the Bark method that overrides the inherited
! class' method; i.e., give the Greyhound its own bark
subroutine Bark( this )
! Declare the passed-object (hidden argument in the
! call statement) as the same type as the class
class ( Greyhound ) :: this
print *, BOW WOW (Fortran Dog)
end subroutine Bark
end module
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
lectures, archives, unsubscribe, maps at http://www.friam.org
Re: [FRIAM] ABM - OO
Prof David West wrote: Objects should be able to interact with bare hardware and not rely on OS or other environments - like the Smalltalk image. With the resurgence of virtualized instruction sets, e.g. Java and .NET, and good hardware/software support via VMware, Parallels, KVM, and Xen, perhaps we can hope to see more high performance implementations of OOP as it was meant to be.. The Right Thing running fast bare on the hardware (almost). Just bought 16 GB of RAM for less than $2k. On a related topic, check out VMware Workstation 6 which now has trace and replay. No more guessing how to reproduce conditions that led to a model (or whatever) getting in to a weird state. Just back up! FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
Re: [FRIAM] ABM - OO
re: performance. Dave Thomas' company Object Technology International developed Smalltalk technology for embedded systems with real time performance equal to C code. He sold OTI to IBM and his technology became Visual Age Smalltalk, Va-Java, and Eclipse with another division of IBM utilizing the embedded technology. Noury Bourqadi in France is doing some very interesting things with tiny VMs running on hardware for highly distributed mini-platform (cell phones) networks. On Sat, 02 Jun 2007 14:02:52 -0600, Marcus G. Daniels [EMAIL PROTECTED] said: Prof David West wrote: Objects should be able to interact with bare hardware and not rely on OS or other environments - like the Smalltalk image. With the resurgence of virtualized instruction sets, e.g. Java and .NET, and good hardware/software support via VMware, Parallels, KVM, and Xen, perhaps we can hope to see more high performance implementations of OOP as it was meant to be.. The Right Thing running fast bare on the hardware (almost). Just bought 16 GB of RAM for less than $2k. On a related topic, check out VMware Workstation 6 which now has trace and replay. No more guessing how to reproduce conditions that led to a model (or whatever) getting in to a weird state. Just back up! FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
Re: [FRIAM] Fwd: ABM
On Sat, Jun 02, 2007 at 01:37:02PM -0600, Marcus G. Daniels wrote: Fortran 2003 seems like it could be a fine programming language for agent models. It has all the common OOP features. An argument for Fortran, I suppose, would be superior numerical performance. I doubt it would be that big of a win, though, due to the fact that agent codes tends to be rate limited by memory latency and CPU indirect mispredicts, more than poor code generation of particular loops. The legendry performance of Fortran is due to its restrictive interpretation of arrays and variable in Fortran77 - all variables are staticly allocated rather than stack allocated, arguments are never aliased, everything has to be expressed as a loop over an array of simple data types. Come Fortran 90 or Fortran 2003 which adds a lot of interesting features to the language that C++ or Java has, and performance is not so easy to attain, unless one restricts oneself to the Fortran 77 subset. It is certainly possible to achieve equivalent performance in C++ to Fortran 77 code. However, it is not as easy to do so - it tends to require a good understanding of C++ and how compilers optimise codes. Cheers -- A/Prof Russell Standish Phone 0425 253119 (mobile) Mathematics UNSW SYDNEY 2052 [EMAIL PROTECTED] Australiahttp://www.hpcoders.com.au FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
