Context Navigation

Ticket #11316 (closed: fixed)

Opened 6 years ago

Last modified 5 years ago

Fixes for projection

Reported by:	Andrei Savici	Owned by:	Harry Jeffery
Priority:	major	Milestone:	Release 3.4
Component:	Framework	Keywords:
Cc:	owen.arnold@…	Blocked By:	#11020
Blocking:		Tester:	Owen Arnold

Description (last modified by Andrei Savici) (diff)

Ticket #11020 create the projection object. Here are a few things that needs to be changed:

The number of offsets can be any. You can have more than 3. The only requirement is that when you use the projection object, the number of offsets is either 0 or equal to the number of dimensions in the input (or output) workspace in CutMD
Remove comment on line 75 in Code/Mantid/Framework/API/inc/MantidAPI/Projection.h. We always have exactly 3 axes
p=Projection(); x=p.toWorkspace() should put the x workspace in the ADS
Modifying the workspace should change the projection object as well.

Change History

comment:1 Changed 6 years ago by Andrei Savici

Description modified (diff)

comment:2 Changed 6 years ago by Harry Jeffery

Blocked By 11020 added

comment:3 follow-up: ↓ 4 Changed 6 years ago by Harry Jeffery

seems troublesome regarding scope. Once you've got data binding in one direction, the users will be confused that it's not also updated in the other direction, so we'd end up adding support for that too. At that point all we've achieved is a weird storage back-end for a specialised table workspace. I think the problem here stems from ambiguous intentions, as the workspace is not a view of the projection itself, but an output generated from it. I think it would make things much clearer if I renamed the toWorkspace method to createWorkspace to clarify that it's an output, not a conversion/cast.

comment:4 in reply to: ↑ 3 Changed 6 years ago by Owen Arnold

Replying to Harry Jeffery:

seems troublesome regarding scope. Once you've got data binding in one direction, the users will be confused that it's not also updated in the other direction, so we'd end up adding support for that too. At that point all we've achieved is a weird storage back-end for a specialised table workspace. I think the problem here stems from ambiguous intentions, as the workspace is not a view of the projection itself, but an output generated from it. I think it would make things much clearer if I renamed the toWorkspace method to createWorkspace to clarify that it's an output, not a conversion/cast.

I agree with Harry on this point. The only way to handle this kind of thing would be to make the Projection a subtype of an ITableWorkspace (like the PeaksWorkspace), which would be a lot of work to the entire framework. If users are really keen on that then we could do it, but it would be several weeks work I think.

comment:5 Changed 6 years ago by Harry Jeffery

I also have a couple of questions about 1.

If the number of offsets is either 0 or the number of input/output workspace dimensions, how many input/output workspace dimensions can there be? 0-n? If the projection is always three dimensional, can the number of input/output dimensions not also be assumed to be three?

Supporting more than 3 will require changing the TableWorkspace format. When there's unused offsets, we shouldn't need to do anything as they'll be set to 0 by default.

I've implemented points 2 and 3, but have not yet pushed them.