On 10/10/2010 8:04 PM, Raul Miller wrote: > Personally, I think correctness is best dealt with using > testing. If the result is not correct, the code is wrong. > If the code is wrong and the result is correct you need > additional tests. (But good modularity demands that the > tests be factored out of the production code.)
Raul, I am not sure what the topic is: the place of tests in developing code? I suppose a critical first question is, (1) what is the code supposed to accomplish? Then, (2) what are the tests isset and iselement for? Will they (3) be modified or supplemented as the project proceeds, and (4) removed as unnecessary when the project is complete? ---------------------------------------------- (1a) I describe Sets as a "Look what J can do!" project. "J can model the abstract theory of sets with finitely many elements as far as power sets and sets of ordered pairs!" The code may be a small "sets package" by analogy with "statistics package" or "accounting package" but without their usefulness. Mathematicians will be impressed if J can do a good job of representing elementary set theory and J can make it look easy. (1b) I am doing the project for the fun of figuring out a way to do it while remaining faithful to such abstract principles as "There exists only one empty set," and "If every element of A is an element of B and every element of B is an element of A, then A and B are one and the same set." Background: In abstract set theory there is an informal understanding that a set is like a collection and that "x is an element of y" means x is something belonging to the set y. Certain things are assumed about "set" and "is an element of", and you go from there. In a model of set theory you must be specific about exactly what a set is in that model, and exactly what "x is an element of y" means in that model. You try to be sure the model produces the results predicted by the abstract theory. (2) In my J model verb isset specifies that a set is a special kind of J list. Every J array may be an element, and verb iselement specifies exactly what it means to say array x is an element of set y . (3) Verbs isset and iselement may be modified as the model is developed, but (4) they are basic features of the model and will be in the production code. For large or complicated arrays possibly produced by code and not human hands, these verbs may be essential for determining whether an list is a set and whether an array is an element of a set. Kip On 10/10/2010 8:04 PM, Raul Miller wrote: > On Sun, Oct 10, 2010 at 6:14 PM, Kip Murray<[email protected]> wrote: >> In my model the verb isset tells which arrays are allowed to be sets. > > But you can have naturally occurring arrays which would > be recognized as sets when that was not the intention. > > Examples include: > > '123' -.L:0;:":i.10 > i.&.>#:2 > > And, this does not solve the related problem of using > the wrong set. > > Personally, I think correctness is best dealt with using > testing. If the result is not correct, the code is wrong. > If the code is wrong and the result is correct you need > additional tests. (But good modularity demands that the > tests be factored out of the production code.) > > (Though, granted, you can find advocates opposed to > modular design.) > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
