Re: [office] Formula: test cases

[robert_weir@us.ibm.com]

I guess I'm looking out there and see
a trend over the years, where with programming, we once did our code, then
wrote the test cases, and then wrote the documentation.  But then
we progressed to things like Literate Programming, JavaDoc, assertions,
Extreme Programming, etc., and learned the virtues of moving the test and
documentation activities earlier into the engineering process, and of integrating
those artifacts into the source code where it is more likely to be kept
up-to-date.  So self-testing, self-documenting code is the norm now.
 The next step forward from this may be self-testing specifications.

What does this mean for standards?  Well,
it doesn't necessarily mean anything.  Standards conventions are conservative.
 The fact that ISO standards are available in digital format at all
is perhaps as much progress as we can hope for in one lifetime.  But
the benefits of having integrated test cases in the standard is motivated
by the observation that such approaches have proven to have great usefulness
in other areas.  That is where this is coming from.

-Rob

Patrick Durusau <patrick@durusau.net> wrote
on 03/29/2007 05:26:07 PM:

> Rob,
> 
> robert_weir@us.ibm.com wrote:
> 
> >
> > An interesting example of how others have approved this problem
is the 
> > functions in XPath 1.0.   Here's how James Clark describes
the round() 
> > function:
> >
> > "Function: number round(number)
> >
> > The round function returns the number that is closest to the
argument 
> > and that is an integer. If there are two such numbers, then the
one 
> > that is closest to positive infinity is returned. If the argument
is 
> > NaN, then NaN is returned. If the argument is positive infinity,
then 
> > positive infinity is returned. If the argument is negative infinity,
> > then negative infinity is returned. If the argument is positive
zero, 
> > then positive zero is returned. If the argument is negative zero,
then 
> > negative zero is returned. If the argument is less than zero,
but 
> > greater than or equal to -0.5, then negative zero is returned."
> >
> > I always liked that definition.  Very complete. It is just
text, with 
> > no test suite, but the text is mainly a verbose English enumeration
of 
> > text cases.  Why not rwrite it as:
> >
> >
> > "The round function returns the number that is closest to
the argument 
> > and that is an integer. If there are two such numbers, then the
one 
> > that is closest to positive infinity is returned.
> >
> > Examples:
> >
> > round(NaN) = NaN
> > round(Inf) = Inf
> > round (-Inf) = -Inf
> > round(0) = 0
> > round (-0) 0
> > round (0.25) = -0"
> >
> > Isn't this just a difference of notation and one that is much
easier 
> > to read?  Interestingly in other parts of XPath, explicit
examples are 
> > given, such as in the definition of substring().
> >
> >  If needed we could probably write a Python script that
would take all 
> > of the test cases and generate English sentences for each one.
 But is 
> > that an improvement?
> >
> Err, well, I am supposed to be reading the formula proposal carefully
> but I guess I can take a break to reply. ;-)
> 
> Sure, if you pick your examples carefully, then a "test case"
can appear 
> to be clearer than a normative expression in English.
> 
> But, note that your "test cases" enumerates the entire range
of possible 
> values.
> 
>  From the "test cases" that I have examined in the
proposal, that is not 
> the case. That is they enumerate some "test" values and
specify a result.
> 
> That isn't the same thing as abstractly specifying the rule for an
> entire range of values.
> 
> I am not wedded to the notion of expressing all the rules in English.
> But then I have spent a lot of time with markup theory proposals and
so 
> prior experience may color my perception of what is clearly expressed.
;-)
> 
> Hope you are having a great day!
> 
> Patrick
> 
> 
> > -Rob
> >
> >
> > Patrick Durusau <patrick@durusau.net> wrote on 03/29/2007
12:48:50 PM:
> >
> > > Bruce,
> > >
> > > Bruce D'Arcus wrote:
> > >
> > > >
> > > > On Mar 29, 2007, at 12:26 PM, Patrick Durusau wrote:
> > > >
> > > >>> This seems like a reasonable point, and the
crux of the matter.
> > > >>>
> > > >> Well, a reasonable point but not really the crux
of the matter.
> > > >
> > > >
> > > > By this I mean the central question is whether formulas
constitute a  
> > > > special case of sorts that would justify the approach.
That, it 
> > seems  
> > > > to me, *is* the crux of the matter. General rules only
work for  
> > > > general cases.
> > > >
> > > Oh, OK, I stand corrected. Sorry, did not understand that
to be your 
> > point.
> > >
> > > Hmmm, well I doubt this is the first time that formulas
(or other math
> > > functions) have been specified. I will check with the usual
suspects
> > > (standards bodies) and see what I can turn up. Most of that
stuff tends
> > > to be unavailable online but I will see what I can turn
up.
> > >
> > > Hope you are having a great day!
> > >
> > > Patrick
> > >
> > > PS: Would standards by mathematical associations count?
Not ISO but
> > > certainly similar in character.
> > >
> > > --
> > > Patrick Durusau
> > > Patrick@Durusau.net
> > > Chair, V1 - Text Processing: Office and Publishing Systems
Interface
> > > Co-Editor, ISO 13250, Topic Maps -- Reference Model
> > > Member, Text Encoding Initiative Board of Directors, 2003-2005
> > >
> > > Topic Maps: Human, not artificial, intelligence at work!
> > >
> > >
> >
> 
> -- 
> Patrick Durusau
> Patrick@Durusau.net
> Chair, V1 - Text Processing: Office and Publishing Systems Interface
> Co-Editor, ISO 13250, Topic Maps -- Reference Model
> Member, Text Encoding Initiative Board of Directors, 2003-2005
> 
> Topic Maps: Human, not artificial, intelligence at work! 
> 
>