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>

**Re: Mathematica's FindMinimum does not solve trivial optimization problems**

**FindMinimum does not free memory**

**Re: Regression Testing of Graphics: some questions**

**Re: Regression Testing of Graphics: some questions**