[Nexus] proposed additions to NXdata for non-linear scaling - to aid cbf interoperability

[jonathan.sloan at diamond.ac.uk]

Hi,

Thanks for your replies.


> Hi All,
>     Perhaps let's take a quick look at what would be required to
> implement and support an NXformula class. The 2010 NIAC minutes mention
> "muParser"
> (http://muparser.beltoforion.de/mup_features.html#idFeatureOverview) for
> the syntax and it could be used to cover high-performance needs in C++,
> C and C#. I expect we should also support implementations in Python and
> Java (at least), which should be doable for the short list of muParser
> built-in functions and telling people needing high performance to use
> muParser instead.
>
> I would propose that NXformula be implemented as a group containing:
> * A field named "formula" containing a string representing the formula.
> * Links with names corresponding to the parameters of the formula and
> pointing to the appropriate datasets.
>
> E.g.
> Scaling:NXformula
>    formula="A*sin(B)+C/3.5"
>    A:NXlink -> /entry1/counter0/data
>    B:NXlink -> /entry1/sample/rotation_angle
>    C:NXlink -> /entry1/counter1/data
>
>
> Does this sound like a "good" way to do it?
>
> Cheers,
> Ben

That does sound good, I was actually going to suggest something similar in response to your earlier comments.

Would it be possible to extend this to cover tensors of data? It appears to cover only scalar values right now, and you should be able to gain much higher performance (and more usability) by pushing iteration down into lower-level code. I have a vague idea of how to go about doing so, but I suspect that it would introduce a lot of complexity which might not really be necessary to implement tensors nicely.


> I was thinking that the list of provided functions in muParser was
> short enough that it would be better to write a new parser in
> Python/Java that implements the same set of functions, rather than
> providing bindings to muParser itself.

Personally, I would assume it's simpler to expose the C interface to python, since it should be something that would only need to be done once. It's something that CBF already does, and would avoid the complexity of writing and testing two separate parsers. I've never actually done this though, so I might be wrong.

Thanks.


-- 
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom