Re: [Pdkb-physics] Ideas for the mailing list.

[<s_a...@hu...>]

At Tue, 8 Feb 100 16:37:53 -0800 (PST), David Whitten <wh...@ne...> 
wrote:

>
>The PDKB provides a clear vocabulary and definitions that are useful 
>to
>describe situations where a computer program may need to model physics.
>
>I'll start out with an example from one of the list members:
>
><<
> 
>There are two basic types of thing in these physics: Objects, and Forces.
>Objects are affected by forces. objects are everything from walls, floors,
> and the kitchen sink. They can be destroyed, etc. Stored along with 
>them
>is basic information on their composition (say, wood), general structure
>(low cylinder, or a torus, or even a U shape. Things like that.), friction,
> mass, size, weight, heading, position, etc.
> 
>Forces are that which acts on the objects. An object will generally 
>have
>forces associated with it, such as gravity, or its magnetic polarity,
> rather
>than having forces freestanding. (although gravity would be such a force,
> I think.) The forces then interact with eachother... Say, we have a 
>large
>piece of iron. Someone runs current through it, which causes it to have
>a magnetic force. It then attracts most of the rest of the iron in the 
>room,
> including a metal support. The support, which was exerting an upwards 
>force
>on the roof, is pulled to the iron. The roof, with nothing to counteract
>its downward force, collapses.
> 
>>>
>
>As is my habit, I'll include all the defintions of PDKB constants I 
>use
>at the end of my posting.
>
>To start on his/her simple example, all the objects mentioned above

His, just so you know. :)

> are instances of #$TemporalThing.
>And to even interact, they must be #$cotemporal, as well as #$near.
>These restrictions will keep something that happened a decade ago
>from affecting our model physics happening now.
>And the #$near requirement keeps something happening a long way
>from these objects from affecting the event here.
>
>In fact, I think we can say the roof and support are both 
>#$above-Overhead the large piece of iron. Since #$above-Overhead is
>a #$genlPreds for #$above-Directly we know that anything we know
>about #$above-Directly would be true for  #$above-Overhead as well.
>and we also know that the roof is #$above-Directly the piece of iron
>and the support is too.  So when they collapse, it will be no surprise
>that the roof falls on top of the iron (presumably requiring them to
>do something to remove the roof if they want to get the iron and bring
>it somewhere else.)  
>
>This is the power of symbolic modelling, that we can set up rules
>about #$above-Directly and #$TransformationEvent, which this roof collapsing
>event clearly is an instance of, and get the general model for having
>to handle things that collapse on top of other things. This speeds coding
>and adds more robustness to our programs.
>

Very good, indeed. Only thoughts are... How to integrate this system into 
our MUD engine? At this stage, any requirements for special design are quite 
possible. We are using a module design... A module can export symbols to 
be called by JavaScript or other modules, it can produce + receive events,
 and it can 

I assume these notations are for use with MELD. This looks like a very powerful 
way to handle a "fuzzy" environment, such as a primarily text based MUD. 
Perhaps we can extend this to other things, as well...?

Sado
PHIZZ-HQM project leader


IMPORTANT NOTICE:  If you are not using HushMail, this message could have been read easily by the many people who have access to your open personal email messages.
Get your FREE, totally secure email address at http://www.hushmail.com.