<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi All,<br>
       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. Something like:
    <a class="moz-txt-link-freetext" href="http://pyparsing.wikispaces.com/file/view/fourFn.py/30154950/fourFn.py">http://pyparsing.wikispaces.com/file/view/fourFn.py/30154950/fourFn.py</a><br>
    <br>
    The Python/Java versions wouldn't need to be very fast - just enough
    to get by. People needing performance would be told to use muParser.
    The code would be written by whoever decides they need it enough,
    which might be the CBF crew. I am continuing this conversation in
    the hope that we can lay out the set of requirements clearly enough
    that somebody could decide it is worth the effort.<br>
    <br>
    Cheers,<br>
    Ben<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 19/02/14 16:31, Wintersberger, Eugen
      wrote:<br>
    </div>
    <blockquote
      cite="mid:35E004AD6290A7438FCA34BBF325F41606996940@ADXV2.win.desy.de"
      type="cite">
      <pre wrap="">Hi all,

On Wed, 2014-02-19 at 15:50 +0100, Benjamin Watts wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">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" 
(<a class="moz-txt-link-freetext" href="http://muparser.beltoforion.de/mup_features.html#idFeatureOverview">http://muparser.beltoforion.de/mup_features.html#idFeatureOverview</a>) for 
the syntax and it could be used to cover high-performance needs in C++, 
C and C#. 
</pre>
      </blockquote>
      <pre wrap="">
That is a really interesting project - was not aware of this. 

</pre>
      <blockquote type="cite">
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">
Well -  I am not so sure if this is really that easy. I guess you would
provide a binding via the Python C-API and JNI. Both are not as easy to
handle as their documentation suggests. 

In fact I thought that NAPI is in maintenance mode and no new features
will be implemented (I think this decision was made on the NIAC meeting
in 2012). Who would write the code?

</pre>
      <blockquote type="cite">
        <pre wrap="">
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?
</pre>
      </blockquote>
      <pre wrap="">
Despite my concerns mentioned above this sounds absolutely fine for me.
One maybe needs an additional attribute to the data field of NXdetector
providing a path to the NXformula instance storing the transformation
'code'. 

regards
  Eugen

</pre>
      <blockquote type="cite">
        <pre wrap="">
Cheers,
Ben


On 19/02/14 14:28, Mark Koennecke wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">Hi,


On 02/19/2014 11:15 AM, Wintersberger, Eugen wrote:
</pre>
          <blockquote type="cite">
            <pre wrap="">Hi folks

On Wed, 2014-02-19 at 10:11 +0100, Benjamin Watts wrote:
</pre>
            <blockquote type="cite">
              <pre wrap="">Hi Jonathan,
     This kind of thing has been discussed at previous NIAC meetings.
Your proposal makes for a simple change, but does more to push the
problem further away from yourself than to actually solve it.
</pre>
            </blockquote>
            <pre wrap="">If I understand Ben correctly what he means is that the code working
with the stored data needs to do a lot of work to interpret it
correctly.

</pre>
            <blockquote type="cite">
              <pre wrap="">What we
really need is some "standard" way to present mathematical formulae in
general that is accessible across different programming languages.
</pre>
            </blockquote>
            <pre wrap="">That's the right way to go.

</pre>
            <blockquote type="cite">
              <pre wrap="">I
think maybe Eugen Wintersberger had a good suggestion, but I don't
recall any follow-up on it.
</pre>
            </blockquote>
            <pre wrap="">Hm - I cannot recall that I made a good suggestion on this. However,
what I would mot probably do is to use Python syntax to represent math.
This has two advantages:

1.) an actual language can immediately execute the code
2.) it might be easy to write a parser for Python code in any other
language.

In my opinion 2. is the the critical point. Once you start with this you
are basically inventing a new scripting language. Consequently, a
program which wants to use the data needs to parse this code and takes
the appropriate action which is not a trivial task.

In addition one should be very careful with such things to not open
Pandoras box. I would restrict this to plain math (no loops, no
branching, etc.). Otherwise you really invent a new language.

What is still open is how to fill the namespace for the code to execute.
Where should all the data mentioned in

offset  + data**c

come from?

At the end of the day there is one question we should seriously discuss:
how far do we want to go with math in Nexus?
</pre>
          </blockquote>
          <pre wrap="">This is exactly the point why we never got down to anything in this.
In 2011, Amando was tasked to make a proposal but nothing ever
came from it. With the manpower and support we do not have, we
cannot support our own data interpreter, cross platform and good
performance wise.

IMHO, the wisest solution seems to be to add what is
absolutely required. Required in the sense to cover the use case where
you do not have the time to do the conversion on the fly before
writing the data to disk.

Regards,

            Mark





</pre>
          <blockquote type="cite">
            <pre wrap="">regards
   Eugen



_______________________________________________
NeXus mailing list
<a class="moz-txt-link-abbreviated" href="mailto:NeXus@nexusformat.org">NeXus@nexusformat.org</a>
<a class="moz-txt-link-freetext" href="http://lists.nexusformat.org/mailman/listinfo/nexus">http://lists.nexusformat.org/mailman/listinfo/nexus</a>
</pre>
          </blockquote>
          <pre wrap="">
_______________________________________________
NeXus mailing list
<a class="moz-txt-link-abbreviated" href="mailto:NeXus@nexusformat.org">NeXus@nexusformat.org</a>
<a class="moz-txt-link-freetext" href="http://lists.nexusformat.org/mailman/listinfo/nexus">http://lists.nexusformat.org/mailman/listinfo/nexus</a>
</pre>
        </blockquote>
        <pre wrap="">
_______________________________________________
NeXus mailing list
<a class="moz-txt-link-abbreviated" href="mailto:NeXus@nexusformat.org">NeXus@nexusformat.org</a>
<a class="moz-txt-link-freetext" href="http://lists.nexusformat.org/mailman/listinfo/nexus">http://lists.nexusformat.org/mailman/listinfo/nexus</a>
</pre>
      </blockquote>
      <pre wrap="">
</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
NeXus mailing list
<a class="moz-txt-link-abbreviated" href="mailto:NeXus@nexusformat.org">NeXus@nexusformat.org</a>
<a class="moz-txt-link-freetext" href="http://lists.nexusformat.org/mailman/listinfo/nexus">http://lists.nexusformat.org/mailman/listinfo/nexus</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>