Extend the cases that CropWorkspace can deal with

[Steve Williams]

from Steve King:

CropWorkspace currently seems to assume that the input workspace will always have increasing X data, however there are instances when it is necessary to zero-pad an array/list (such as when transferring data out of NumPy algorithms). If the array/list is passed to CreateWorkspace the padding will (correctly) be included but cannot then be cropped off!

Code like this Python should remove the trailing zeros from the workspace.

x = [1, 2, 3, 4, 5, 6, 0, 0, 0]
y = [10, 20, 30, 40, 50, 60, 0, 0, 0]
e = [0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0, 0, 0]
ndata = 6

CreateWorkspace('a',x,y,e),NSpec=len(y))
CropWorkspace('a','a',1,6)#remove trailing zeros

[Steve Williams]

CropWorkspace also needs to deal with decreasing x-values

[Steve Williams]

This supersedes all previous entries on this ticket.

Algorithms that create workspaces from user supplied data, at least CreateWorkspace and LoadASC will always create x-value arrays whose values increase monotonically. This will involve making a sorting function, which will also be able to sum the contents of identical bins and hence change users data a little.

For histograms things are slightly more difficult as out-of-order bin boundaries describe overlapping bins. How this is handled should be obvious from the documentation.

[Steve Williams]

CreateWorkspace may have been fixed so this is no longer a problem in #3118

[Steve Williams]

The test script should read as follows:

x = [1, 2, 3, 4, 5, 6, 0, 0, 0]
y = [10, 20, 30, 40, 50, 60, 0, 0, 0]
e = [0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0, 0, 0]

CreateWorkspace('a',x,y,e,1)
CropWorkspace('a','a',1,6)

[Karl Palmen]

I'm unable to run the above as a python script. When ran through the GUI I got

CropWorkspace started
XMin is greater than the largest X value (1 > 0)
Error in execution of algorithm CropWorkspace:
XMin is greater than the largest X value (1 > 0)

So this is still an issue.

[Karl Palmen]

I see that the problem arises from the following code in the getXMin method

    if ( m_commonBoundaries && minX_val > X.back() )
    {
      std::stringstream msg;
      msg << "XMin is greater than the largest X value (" << minX_val << " > " << X.back() << ")";
      g_log.error(msg.str());
      throw std::out_of_range(msg.str());
    }

I think X.back() gets the last element in the workspace (spectrum) assuming it's the maximum, even if there are trailing zeros.

[Karl Palmen]

A look at the code for CropWorkspace::getXMin and the function std::lower_bound that it calls, suggests postponing the check until after the call of std::lower_bound and then do it only if that function returns the end index. This will only happen all the values (not just the last) are less than minX_val.

If this reduces efficiency too much one can reinstate the check beforehand for cases where X.back() is not zero.

[Karl Palmen]

Defer checking of Xmin value re #2027

Signed-off-by: Karl Palmen <karl.palmen@…>

Changeset: 9f0a346058b593930493c1c8305ed08b225e3a1c

[Karl Palmen]

Fix CropWorkspace::getXMin problem re #2027

Signed-off-by: Karl Palmen <karl.palmen@…>

Changeset: eb08e3bc419dbdfaeb67dae49fc0c2d108092616

[Karl Palmen]

I tested with script

x = [1, 2, 3, 4, 5, 6, 0, 0, 0]
y = [10, 20, 30, 40, 50, 60, 0, 0, 0]
e = [0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0, 0, 0]

a = CreateWorkspace(x,y,e,1)
a2 = CropWorkspace(a,1,6)
a3 = CropWorkspace(a,1.5,5)
ax1 = CropWorkspace(a,7,8)

and the correct error message was displayed at the end, but workspace a3 was cropped on the left hand side only, when it should be cropped on both sides. So work is needed on this too.

[Karl Palmen]

I've found that cropping works OK if the max is sufficiently low. It works for workspace a4 but not a3 in

x = [1, 2, 3, 4, 5, 6, 0, 0, 0]
y = [10, 20, 30, 40, 50, 60, 0, 0, 0]
e = [0.1, 0.2, 0.3, 0.4, 0.5, 0.6, 0, 0, 0]

a = CreateWorkspace(x,y,e,1)
a3 = CropWorkspace(a,1.5,5)
a4 = CropWorkspace(a,1.5,4.5)

[Karl Palmen]

I've found out that the functions upper_bound() and lower_bound() require the array between the two iterator argument ot be sorted (or partitioned).

So it seems necessary to check for trailing zeros in advance and wind back the X.end() to the last non-zero value.

[Karl Palmen]

Update comment re #2027

Signed-off-by: Karl Palmen <karl.palmen@…>

Changeset: 038ffd9c1c6d54b45008f26cd140a22ed2972cc2

[Karl Palmen]

Merge branch 'feature/2027_crop_workspace' into develop

[Karl Palmen]

Merge branch 'feature/2027_crop_workspace' into develop into 6856_ConvertToDiffractionMDWS_v2

[Karl Palmen]

After a discussion with Martyn Gigg, it was decided that CropWorkspace should not support trailing zeroes and that instead users should trim the trailing zeroes before creating the workspace.

Tester must not run "git test start 2027" or equivalent, but check whether we should support workspaces with trailing zeroes at all.

[Stuart Campbell]

This ticket has been transferred to github issue ​2874