Mathematica 9 is now available
Services & Resources / Wolfram Forums / MathGroup Archive
-----

MathGroup Archive 2012

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Regression Testing of Graphics: some questions

  • To: mathgroup at smc.vnet.net
  • Subject: [mg128113] Re: Regression Testing of Graphics: some questions
  • From: James Stein <mathgroup at stein.org>
  • Date: Mon, 17 Sep 2012 00:19:48 -0400 (EDT)
  • Delivered-to: l-mathgroup@mail-archive0.wolfram.com
  • Delivered-to: l-mathgroup@wolfram.com
  • Delivered-to: mathgroup-newout@smc.vnet.net
  • Delivered-to: mathgroup-newsend@smc.vnet.net
  • References: <20120916072514.963746863@smc.vnet.net> <CAEtRDSdVCZx6P9gsqKf0u5Nnc2haJEZmqko=M6fCW=UCXiW6BA@mail.gmail.com>

Bob Hanlon asks why use cut-and-paste, and shows an example where it
is not needed.
However, his example is given in the context of a single cell; a
single execution within a single notebook.
This has nothing to do with regression testing. Quoting Wikipedia:

"Regression testing is any type of software testing that seeks to
uncover new software bugs, or regressions, in existing functional and
non-functional areas of a system after changes, such as enhancements,
patches or configuration changes, have been made to them. The intent
of regression testing is to ensure that a change, such as a bug fix,
did not introduce new faults.[1] One of the main reasons for
regression testing is to determine whether a change in one part of the
software affects other parts of the software."

To clarify the situation I tried to pose:

In July, the function 'graf', given an explicit set of arguments, was
known to produce a correct result.
We wish to write a regression test that will be run in future, perhaps
run once every month.
The regression test will run independently of whatever happened in
July; the computer will have been rebooted many times, packages used
by 'graf' may have been updated, even Mathematica and the computer's
OS may have changed.
Does 'graf' still give the correct result for that same explicit set
of arguments?

In September, we need to run this expression:
     test [ graf [ arguments ] , resultFromJuly ]
The question is, what exactly IS the "resultFromJuly" ?

This is why, it seems to me, that cut-and-paste is required, or some
other "trick".
A possible "trick" would be to write a routine, call it 'g2s', which
represents a Graphic object as a string.
   ( for example:  g2s [ x_ ] := x // InputForm // ToString  )
You could then write
   test [ g2s [ graf [ arguments ] ] , resultStringFromJuly ]

This trick has two unfortunate results:
1. The strings are typically much larger (in terms of notebook space
for their representation) than the graphic results themselves, so the
test may occupy many dozen lines, thanks to 'resultStringFromJuly'.
2. The call to test no longer clearly (visually) represents the
intended correct result.


On Sun, Sep 16, 2012 at 6:32 AM, Bob Hanlon <hanlonr357 at gmail.com> wrote:
> Why use cut-and-paste?
>
> graf := ListPlot[{1, 2, 2, 3},
>    ImageSize -> Tiny];
>
> previousResult = graf;
>
> Head[previousResult]
>
> Graphics
>
> previousResult === graf
>
> True
>
> test[expr_, ansr_] := expr === ansr;
>
> test[graf, previousResult]
>
> True
>
>
> Bob Hanlon
>
>
> On Sun, Sep 16, 2012 at 3:25 AM, James Stein <mathgroup at stein.org> wrote:
>>
>> To my surprise, if you copy a Graphic  from a notebook and paste it
>> elsewhere in the notebook, the Graphic objects are not the same (even
>> though their visual appearance is identical.
>>
>> I discovered this irritation attempting regression testing. Here's an
>> example: assume you have a function 'test' that takes two arguments:
>>      test [ expression_, expectedResult _]
>> An overly simple implementation might be this:
>>     SetAttributes [ test, HoldAll ] ;
>>     test [ expr_, ansr_ ] := expr === ansr;
>> Now suppose you wish to verify that some routine, say  'graf', is still
>> giving the same result it it did previously. Here is an example:
>>
>>     graf := ListPlot [ { 1, 2, 2, 3 }, ImageSize->Tiny ];
>>     test [ graf , previousResult ] // Print;
>>
>> What should 'previousResult' be? You might consider copying the graphic
>> produced by 'graf' earlier, which was correct, and paste it into 'test' as
>> the second argument. Unfortunately, the action of copy & paste changes the
>> internal structure of Graphic [ a1, a2, ... ] so the regression test will
>> always fail.
>>
>> Questions:
>> (1) Is there a good reason for this? (The unwashed are curious.)
>> (2) Is this a bug (or 'feature') that could be fixed?
>> (3) Is there a way to prevent it?
>> (4) Is there an algorithm to do one of
>>   (a) convert an original Graphic to its pasted form.
>>   (b) convert a pasted Graphic to its original form.
>>   (c) convert any Graphic to a canonical form, such that any two Graphic
>> objects that produce identical displays will have identical canonical forms.
>>
>> For the truly curious, here are the differences in for a rather simple
>> ListPlot I made. Let OG be the original, and CG be the pasted copy of OG.
>>
>> OG had Length 2; CG had Length 8.
>>
>> OG [[ 1 ]] was { { { }, {Hue[0.67, 0.6, 0.6], Point[{{1., 1.}, {2., 2.},
>> {3., 2.}, {4., 3.}}]}, { } } }
>> CG [[ 1 ]] was {   { }, {Hue[0.67, 0.6, 0.6], Point[{{1., 1.}, {2., 2.},
>> {3., 2.}, {4., 3.}}]}, { }   }
>>
>> OG [ [ 2 ] ] was List of seven rules,
>>
>> OG [ [ 2 through 8 ] ] were the same seven rules.
>>
>> It would be simple to convert one of these trees to the other, but it would
>> be rash to generalize the nature of the needed conversion without extensive
>> investigations. Perhaps a  Wolfram wizzard can throw light on these
>> questions, or someone can propose a different kind of regression testing to
>> skirt the issue?
>>
>>



  • Prev by Date: Re: Regression Testing of Graphics: some questions
  • Next by Date: Re: FindMinimum function does not seem to work for simple problems
  • Previous by thread: Regression Testing of Graphics: some questions
  • Next by thread: Re: Regression Testing of Graphics: some questions