the gulf between bog-standard and actually good OO?
in [OOP]
|
Prev: Call for Paper The International Journal of Computer Science (IJCS)
Next: CFP with Extended Deadline of Mar. 21, 2010: The 2010 International Conference on Computer Graphics and Virtual Reality (CGVR'10), USA, July 2010
From: Nilone on 6 Mar 2010 04:09 On Mar 6, 10:43 am, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > My first education is AI (pattern recognition, machine learning, > uncertainty model, that awful stuff, you know). I do *not* buy swarm > intelligence, agents, genetic algorithms etc. It is a snake oil, sorry > don't want to offend anybody. What is your opinion of the following: http://ti.arc.nasa.gov/projects/esg/research/antenna.htm
From: Dmitry A. Kazakov on 6 Mar 2010 04:45 On Sat, 6 Mar 2010 01:09:00 -0800 (PST), Nilone wrote: > On Mar 6, 10:43�am, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: >> My first education is AI (pattern recognition, machine learning, >> uncertainty model, that awful stuff, you know). I do *not* buy swarm >> intelligence, agents, genetic algorithms etc. It is a snake oil, sorry >> don't want to offend anybody. > > What is your opinion of the following: > > http://ti.arc.nasa.gov/projects/esg/research/antenna.htm [OT on] It looks interesting, but does not alleviate my scepticism. They do not describe the fitness function. In the case of an antenna it might be simply enough to express the quality of an antenna as a number. Which is good, because in most cases there is no explicit fitness function, so you even cannot tell if the mutation was any good, which is essential for the brute force random search, which in essence a genetic algorithm is. (As an example consider a GUI program written genetically. The fitness function would be a coverage test, mutations would be random changes in the code. (:-)) So I think they succeed because of a simple fitness function and a narrow number of variants. Even so, there is still problem with the genetic code (chosen voluntarily, does it describe all possible antennae?), mutations applied (not bound to the fitness function), the effects of mutations (unpredictable, unbound. What is the probability to get a better antenna after a mutation? How big is the distance in the quality space between the parents and a child?) Basically there is no any reason (except per luck) why learning should converge to anything useful. Maybe it happened to them. Did it? Is the antenna found optimal, suboptimal, how close to the theoretical optimum is it? If they tried random seeds, would they find a solution quicker? The main objection is that it is not an engineering, it is "try and see", not a technology. [OT off] OO being permanently bashed as unsound is much more engineering and science than this stuff. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: S Perryman on 5 Mar 2010 23:38 johnzabroski(a)gmail.com wrote: > 2. Petri nets are inherently non-deterministic. Petri nets are deterministic. Otherwise you cannot have "firing" . The order of arrival of tokens on places, is what is non-deterministic. Regards, Steven Perryman
From: S Perryman on 5 Mar 2010 23:43 Dmitry A. Kazakov wrote: > On Fri, 05 Mar 2010 18:13:44 +0000, S Perryman wrote: > Broadcasting is asynchronous 1-n messaging. OOPL rather deploy peer-to-peer > synchronous messaging. The vital advantage of 1-1 synchronous messages > (calls) are: > 1. you can pass individual parameters. (Ant messages lack parameters > altogether); The amount of pheromone (especially under attack) is conceptually parametric. Of course one can also argue that this is merely the same message repeatedly sent at increasing frequency, and response based on the frequency. Regards, Steven Perryman
From: Daniel T. on 7 Mar 2010 10:15
"Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote: > On Fri, 05 Mar 2010 09:46:25 -0500, Daniel T. wrote: > > raould <raould(a)gmail.com> wrote: > > > On Mar 4, 1:21�am, Nilone <rea...(a)gmail.com> wrote: > > > > > > > > > * the old hierarchical breakdown of procedures in structured > > > > > programming vs. the peer relationship that should be used in > > > > > oo. i don't even know how to visualize these, it would be > > > > > great to see a small toy code example of the difference. > > > > > > > > The theoretical models will help you visualize. �I don't know > > > > what code example would illustrate the issues well. �Post > > > > something you're familiar with, and we can discuss and criticize > > > > possible designs. Distrust animal and vehicle based examples. > > > > > > unfortunately i'm so not understanding the topic yet that i don't > > > even have an example i could post. by visualize i meant have an > > > example of it i can work through in my head. like, i can work > > > through an example of single dispatch java vs. multiple dispatch > > > in my head since i've written that code enough times. > > > > > > my vague sense of it so far comes from reading Lahman's blog, that > > > it is in particular about control-flow, rather than about, say, > > > type hierarchy. which i can in some ways i think i understand > > > (like, many conditional tests can be re-coded into the object > > > hierarchy, to replace the conditional with polymorphism) but i > > > suspect i'm not fully groking it. > > > > Here is a simple quote that might help. "In OO programs, objects > > tend to tell other objects what happened, instead of telling them > > what to do." > > Well, I see no difference if action is a simple function of state. To > tell the object "do X" is same as to tell it "we are in the state, > where you will do X." The above misses the point. In OO you don't tell the object "we are in the state where you will do X," you tell the object "we are in this state"; what the object does with that information is its business. > There could be a difference in an asynchronous system, or when > participants had some intelligence making their own decisions in same > states, but neither is typical to a well-designed OO program. Such ideas are not typical period. Most of a program should not be implemented in an OO way, most of a program should be implemented using modular techniques. |