Saturday, February 6, 2016

Sweetgum Fruit

I was out volunteering at a local math competition and wandered around a bit after the event. I stepped into a little courtyard and found a mess of these little guys and had to take a few photos. I didn't do any editing aside from some minor cropping and rotation -- I usually play around with color and sharp/focus, and go a little crazy with the image filters -- because I really loved the way the colors turned out.
Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

~~~~

Sunday, December 27, 2015

We conceive of limits to variation in animal behaviors and morphology. When we deduce something about the constraints acting on the development of an organism and on the evolution of a species we must distinguish between two kinds of observed limits. The first kind is a limit due to actual biological limitations, whether on embryological development, lack of viability (i.e., animals having the variation die before they can reproduce), or lack of fecundity. The second kind is a limit on what we as scientists can actually observe due to lack of a fossil record either for the animal as a whole or for the specific variation in question, or due to limitations in our methods or devices. The upshot of this difference is that the first kind of limit is fit for building our philosophy of nature while the second kind is misleading and has the power to render our predictive tools worthless.

There are, of course, mitigations to the perfidy of the second kind of limit. For instance, we can determine in some cases that a variation, such as a distinctive birdsong sung by an ancient bird, would not be visible to our tools. In addition, constraints determined in one area may depend on constraints in another area which confound limits of the second kind. Ultimately, these ways of thinking lead to the practice of integrating heterogeneous models of living systems into a single model. The hope is that there is a dependence between parts of the system which constrain those variations which cannot be constrained through observation. In the limit, this approach frees us entirely from the "black swans" since it produces an emulation of reality. In the real world, however, where computational limitations prevent perfect copies of reality, there may yet be independent pockets of variability that we will always fail to pick up either in observations or in our models.

~~~~

Friday, December 11, 2015


Colored Square. © 2015, by Mark W.
~~~~

Monday, July 20, 2015

Kinds of tests

These are my thoughts on software testing terminology. Some of these tests have definitions that float, and I want to get down my definitions, so that I can refer to them and refer people to them if there's any uncertainty about what I mean.
Integration test
A test of the boundary between components. An integration test in project A for components B confirms that the interface A expects of B matches up with the interface that B provides. Such tests make sense whenever component B is not available to A's developer at the time that she writes A.
Unit test
A test of the primary functionality of a component and of the edge cases and error modes of the component. The component for which a unit test is written should not have untested sub-parts -- in other words, the unit test assumes that below the level of abstraction at which the test is performed, all components perform perfectly. It may be necessary to make "perfect" sub-parts (e.g., "mock" objects) to effectively test at the desired level of abstraction.
Acceptance test
A test of a component against customer requirements. These are tests which must be passed for acceptance of the component by the customer.
Formal test
A test of the mathematical abstraction of the software component against known failure modes which can be formally proven to occur, not occur, or possibly occur under a class of inputs.

~~~~