Physical vs Abstract

Maybe it’s a life-long diet of science fiction, but I seem to have written some trilogy posts lately. This post completes yet another, being the third of a triplet exploring the differences between physical objects and numeric models of those objects. [See Magnitudes vs Numbers and Real vs Simulated for the first two in the series.]

The motivation for the series is to argue against a common assertion of computationalism that numeric models are quintessentially the same as what they model. Note that these posts do not argue against computationalism, but against the argument conflating physical and numeric systems.

In fact, this distinction doesn’t argue against computationalism at all!

The first post considered the difference in how the two system types represent information. Physical systems have physical properties: size, mass, charge, velocity. Numeric systems map arbitrary numbers to those properties — the mapping step being a crucial part of such systems.

The second post considered the different physicality of the two systems. In real objects the physical system is the enacted system. In numeric systems the physical system is distinct from the (abstract) enacted system.

In this post I close with some general observations about abstractions and numeric models.

§

Here I take the term abstraction to have a similar sense to the terms description and design.

[The terms description and design have similar senses to me. (A design is a description, and a description can act as a design.) The difference seems mostly in their intended use, but description seems the more generic term.]

Specifically, the abstractions I mean have high information content — they are complete descriptions or designs. Examples are: the text of a book, a computer algorithm, a blueprint, sheet music, etc.

This is in contrast to the sense of abstraction similar to the terms icon or cartoon. That is, something with significantly less information content than what it represents. Examples are: computer icons, simplified maps and diagrams, cartoons, many forms of art, etc.

So abstractions here are high-content descriptions, and they are — or can easily be — expressed in various ways numerically.

A simulation is a dynamic abstraction run over time. Specifically, it uses numerical processing to turn an input number stream into an output number stream.

For example, a simulation of a airplane might output numbers reflecting how (virtual) air flows over its (virtual) surfaces during the flight. Or a simulation of a bridge might output numbers reflecting how it reacts to different (virtual) loads.

[Note that while there is a non-physical aspect to all information, any description (abstraction, simulation, etc) obviously must have a physical instance of some kind in any application. In practice, information is always reified.]

§ §

The first observation involves where abstractions come from and how they relate to their physical instances.

Consider a blueprint (let’s say of a doghouse).

On the one hand, we can imagine a doghouse and draw a blueprint that defines our conception. We can use the blueprint to build an actual doghouse, so in this case the abstraction comes first.

On the other hand, we might already have a doghouse, in which case we can measure it and make a blueprint that describes that doghouse. We can use it as a design to build new doghouses, but in this case the physical object came first and the abstraction second.

That second blueprint can be either a faithful description or we can embellish it (or remove bits). Then doghouses made from the blueprint will be different from the original.

Almost certainly the first ever “blueprint” (probably just a rough idea) for a doghouse was based on observing that dogs like shelter and scaling down our own ideas about shelters.

So the first definition of a doghouse was likely based on abstracting physical reality to derive a description.

Which led to a design.

Such designs have to be constructed to be roughly physically isomorphic to the original concept of “dog shelter” (i.e. walls, roof, door, etc), because doghouses are physical and designs don’t keep the rain off.

§

Contrast that with what are often called information (processing) systems.

I think that term is broad and even misleading. Any living system, and a number of non-living ones (from radios to computers), can be said to process information.

In this context, by information processing system, I mean the information is numeric and the processing is logical and probably algorithmic. Further that the numbers used have an arbitrary user-defined mapping to meaningful semantics.

In other words, the common conception of a (digital) “computer.”

For such systems, the description almost always comes first — often at a high conceptual level. This is refined into an actual design. (The same applies to the text of a story as well as any software.)

These sorts of systems are fully described by information because they are just information. It’s easy to have a numeric model of something that’s already a numeric model.

A crucial difference here is that information systems are defined by their abstraction, whereas physical systems can be described by abstractions.

§ §

The second observation picks up where the previous one left off.

On the one hand, there is a numeric model of a physical system. In contrast, there is a numeric model of an abstraction.

If, for example, we want to make a numeric model of a simple calculator we have two choices: Model the calculator’s physics, or model the calculator’s abstraction.

We can do both here because calculators are based on abstractions — as discussed above, they are defined by this abstraction, they are information processing systems.

They are also physical objects that operate according to physical laws, so we can also model those instead.

§

There is a third choice, which is that we can model the calculator’s behavior (or functionality). This treats the calculator as a black box and seeks to replicate its input-output mapping without reference to internals.

With something as simple as a calculator, an analysis of behavior is likely to pick out the abstract definition, making them essentially the same thing.

But there are systems (the brain being one of them) where a functional analysis can be distinct from an actual system definition. Given that the latter requires a thorough understanding of the system, when it comes to the brain, it’s possible a functional analysis of mind is easier than figuring out a putative defining abstraction of mind.

§

It’s usually much easier to model the abstraction (or functionality) — that’s what every calculator app does. Even physical calculators often use a single general purpose chip that runs a calculator program (i.e. a model of its behavior).

It’s much harder to model the calculator as a physical object, because we have to model the physics at a fine enough grain to capture the system behavior that interests us.

I explored these approaches in a simpler system in the Full-Adder “Computing” post.

In brief: A full-adder (a logic circuit), like a calculator, is also fully defined by its abstraction, so implementing that abstraction is very easy. (The post has links to some code samples.)

On the other hand, implementing a simulation of its physical behavior is a much more involved proposition (as the code samples show).

§

Now consider modeling a tree.

We don’t have a defining abstraction for a tree, but by examining lots of trees we might derive an abstract description of a tree, but it doesn’t seem likely there is a abstract definition of a tree for us to find (such a definition would need to be able to instantiate any kind of tree — as a description applies to any kind of tree).

A functional analysis seems possible, and we can always simulate the physics at some useful level. Depending on our needs, one or the other likely suits them

The point of these descriptive models, as opposed to design models, is that their purpose is to help us understand the system they model. Such models include airplanes, earthquakes, space orbits, weather systems, and a great deal more.

In some cases, these models do lead to designs. Models of aircraft or cars, for example, are built with both understanding and construction in mind.

The point is there are different ways to approach a numeric model: the underlying abstraction; a functional model; a physics simulation.

It also illustrates how abstract designs lead to physical systems and how physical systems lead to abstract descriptions — which can be refined to designs for new physical systems, and the cycle repeats!

§ §

Bottom line is that I see a lot of daylight between physical systems and numerical simulations of those systems:

  • They are different because of the nature and content of the information they process — physical properties vs arbitrary numbers.
  • They are different because physical causality is bounded by physics but virtual causality is anything the programmer wants it to be.
  • They are different because physical systems are unified causally but numeric simulations have both that unified physical causality plus an implemented virtual causality.
  • They are different because the physical and the abstract are different.

But maybe it’s just me. 😀

Stay real, my friends!

About Wyrd Smythe

The canonical fool on the hill watching the sunset and the rotation of the planet and thinking what he imagines are large thoughts. View all posts by Wyrd Smythe

2 responses to “Physical vs Abstract

  • Wyrd Smythe

    This post makes an effort to define some terms, abstraction, description, design, simulation, and I’d like to extend that in the context of the conversation JamesOfSeattle and I were having in the previous post.

    Description is the most general to me — all the others are kinds of a descriptions. A description can be vague (“he was talk, dark, and handsome”) or precise (a blueprint). The idea is so general that about all we can say is that a description is information about something else. (“Information” being an even more general category.)

    As mentioned in the post, the descriptions of interest here are ones with high information content.

    Abstraction is also a general term, and it’s very similar to description. But all abstractions are descriptions while not all descriptions are abstractions. The difference is that, to me, an abstraction implies a reduction. Something about an abstraction is reduced from what it describes. The abstraction of an algorithm is its flowchart with no reference to implementation. Abstractions of physical objects, say a house or tree, are usually cartoon-like in some sense — they reduce the object to signifying properties.

    Design is a more specific term. A design describes how to create something. A blueprint describes how to build a doghouse (assuming the builder brings building ability along with materials). An algorithm describes a set of steps for a process.

    Definition is also a specific term, but more generic than design. (All designs define, but no all definitions are designs.) A design has more a “blueprint” sense while a definition includes other forms of precise description.

    • Wyrd Smythe

      Thus, in this view, an algorithm cannot define a physical neuron, because it does not allow construction of a physical neuron — it only defines steps to take to simulate its behavior numerically. It is an abstraction that describes the behavior of a physical neuron.

And what do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: