|
|
When this note was originally conceived, I used "framework" in reference to the tacit context relied upon in the presentation of algorithms and also of mathematics. I have elsewhere used "toolcraft" to signify the orientation to a particular technology, especially with regard to the tools used in production of computer programs in a given community.
In looking through my notebooks from that time, I find no clues to how I meant "structure" to be understood. The sense of "mathematical structure" does not seem to apply. It could, but I don't see how that figures in the context where algorithms and programs are considered different. That's where this topic arose originally.
What is clear from where these terms are used in related notes is that frameworks are tacit and structures have the tacit made explicit. Either way there are incidental matters that need to be recognized as merely-incidental, and tacit matters that cannot be avoided.
In my notes, I said "Consider that we arrange a way for data types to always be typical of their class." In this case, I meant that data of a type is not divorced from the class for which it represents an instance.
I do think that is the key. By structure I meant the data values not being separated from their type. The structure within which a value is understood is inseparable from the instance of a value.
This may be equivalent to considerations of abstract data type. I'm not entirely certain of that. But that can be sufficient for now.
Below are some extracts that may provide more sense of this.
-- Dennis E. Hamilton
Seattle, Washington
2014-03-31
The usual statement of an algorithm relies on a supposedly pre-existing framework. There is an implicit framework. It is useful to notice (1) how much of it we take for granted in reading an algorithm's description and (2) how much the author of this description takes for granted about what needs to be said and what can be left as understood.
...
Every expression of an algorithm has baggage. This includes assumptions about the existence of orderings, the assumption of 0-origin indexing, the use of natural numbers for indexes, and the stability of the objects involved. That the algorithm is effectively carried out atomically, while itself being composed of definite steps, is a key assumption in almost all expression of algorithms. This is part of the framework.
Then there is the simple use of ordinary language along with borrowing of mathematical objects and notations, all more framework for expressing algorithms.
...
Consider that the level of abstraction for statements of algorithms might need to be improved.
One way is to notice that the objects appealed to in the statement of the algorithm might be at the wrong level of abstraction. A large part of the baggage might be a consequence of the level at which certain entities, such as ordered lists, are dealt with, in contrast with assumptions about indexing over storage structures, for example.
Another approach is to make reliance on abstract elements explicit rather than tacit. What we might get to is a form of expression of algorithms that can be taken as concrete, given a representation of the abstract elements.
...
Consider that we arrange a way for data types to always be typical of their class.
n010204b: Framework versus Structure [latest]
n010204c: Initial Notes
n010204a: Diary & Job Jar
n020201: Manifest Abstractions
n020202: Homage to the Bit
n020205: Programs Are Rarely Algorithms
n020207: What's an Algorithm?
 |
|
created 2002-12-07-22:39 -0800 (pst) by
orcmid |