That's exactly my point, of course. Reduction from requirements to physics is rarely logically abstracted. In other words, while you and I may be interested in some of the physical properties of hammers and rocks (namely, the ones that facilitate crushing), someone like Andy Warhol might be interested in other physical properties (the color of the materials from which they're made). [Queue some jabber about Tarski's Indefinability of Truth!]
If you logically abstract the physics engine, you can swap it out, at will (in principle, anyway), replace a coarse one with a finer one or one that implements an entirely different physics. Even though we _speculate_ that this can be done in principle, how often is it actually done? I submit that the eminent and immediate requirements set forth by any problem or task will prohibit, or at least limit, the extent to which the constructor will logically abstract. I.e. reduction is convenient, canalizingly convenient. Further, there's an ideological and methodological bias of "computer people" (perhaps any artisan, actually) to treat their building blocks as _the_ building blocks. Variation or substitution among those building blocks (like physics engines or reified rocks and hammers) requires an annoying willingness to play these abstraction games. The extent to which those of us willing to play the games are scorned or ridiculed by those who are unwilling, provides social pressure that positively reinforces the already present building block and reductionism bias. So, yes, you're being reasonable. Perhaps we _can_ do this. But we will not ... because we're sloppy ... perhaps even sloppy by evolutionary design. Practical reuse remains purely opportunistic. Marcus G. Daniels wrote at 04/18/2013 10:53 AM: > An object with high mass and volume, low acceleration vs. low mass, low > volume, and high acceleration? > Even if you have a type that simply tracks physical properties, it can > be embedded in other objects. > > data PhysicalProperties = PhysicalProperties Mass Volume Location > > data Hammer = Hammer PhysicalProperties > > data Rock = Rock PhysicalProperties > > or tagged instances.. > > data Tag = Hammer | Rock > > data PhysicalProperties = PhysicalProperties Mass Volume Location Tag > > hammer = PhysicalProperties 1 1 (0,0,1) Hammer > > rock = PhysicalProperties 0.5 0.5 (0,0,0) Rock > > mass :: PhysicalProperties -> Mass > mass (PhysicalProperties mass _ _) = mass > > isCrushed :: PhysicalProperties -> Bool > isCrushed (PhysicalProperties _ volume _) = volume < 1e-6 > > impact :: PhysicalProperties -> PhysicalProperties > > (Bool,PhysicalProperties,PhysicalProperties) > > If you want to have both physical realism and rules, then decouple them > using a physics engine. > Let the physics engine move the objects around but have rules embedded > in the objects be unaware of physical properties.. -- =><= glen e. p. ropella This body of mine, man I don't wanna turn android ============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
