Re: Regression Testing of Graphics: some questions
- To: mathgroup at smc.vnet.net
- Subject: [mg128118] Re: Regression Testing of Graphics: some questions
- From: Bob Hanlon <hanlonr357 at gmail.com>
- Date: Mon, 17 Sep 2012 00:21:28 -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>
Write each to a file
graf := ListPlot[{1, 2, 2, 3}, ImageSize -> Tiny];
Export["20120916.4graf.txt", graf];
FilePrint["20120916.4graf.txt"]
Graphics[{{{}, {Hue[0.67, 0.6, 0.6], Point[{{1., 1.}, {2., 2.}, {3.,
2.}, {4., 3.}}]}, {}}}, {AspectRatio -> GoldenRatio^(-1), Axes ->
True, AxesOrigin -> {0, 0}, ImageSize -> Tiny, PlotRange -> {{0, 4.},
{0, 3.}}, PlotRangeClipping -> True, PlotRangePadding ->
{Scaled[0.02], Scaled[0.02]}}]
Get["20120916.4graf.txt"]
Export["20120916.5graf.txt", graf];
Import["20120916.4graf.txt"] ===
Import["20120916.5graf.txt"]
True
Bob Hanlon
On Sun, Sep 16, 2012 at 2:02 PM, James Stein <mathgroup at stein.org> wrote:
> 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?
>>>
>>>
- References:
- Regression Testing of Graphics: some questions
- From: James Stein <mathgroup@stein.org>
- Regression Testing of Graphics: some questions