[CR] LV muParser

[Andy75]

Cool- thank you.

I'll have a look into it tomorrow.

[Diego Salomao]

Hello, 

Is it possible to add support for other simple functions like "random" or "now"?

Thanks in advance.

[Rolf Kalbermatter]

1 hour ago, Diego Salomao said:

Hello, 

Is it possible to add support for other simple functions like "random" or "now"?

Thanks in advance.

Have you read the documentation text file included? There is a function rand() which calls the LabVIEW Random Number node and returns its values. Do not expect crypto quality randomness from this. The LabVIEW Random Number generator has been repeatedly investigated and found to have a reasonable randomness but with a limited interval. For most simple requirements that is quite enough, but if you need real crypto quality randomness there would need to be done a lot more serious work and then you quickly can forget to find this as a free library.

As to now() that's a bit tricky. The entire formula parser only really operates on doubles internally and doesn't have any other types. The newly hacked in bitwise operators were simply added by converting the double to an U64 for doing the bitwise operation then store it back as a double on the value stack. That should do for most bitwise operations for up to 32- bit integers but can start to get inaccurate if you chain many bitwise operators in a formula.

So what would you expect the now() to produces? A double representing the number of seconds since January 1, 1904 GMT, as the LabVIEW epoch is? Or rather since January 1, 1970 UTC as the Unix epoch is? Or maybe rather the number of days since January 0, 1900 as the Excel epoch, or would January 1, 1600 UTC be better as the Windows SYSTEMTIME is? You see lots of possibilities and all of them equally right or wrong, so avoiding that problem by not implementing it is simply the easiest solution. 😁

[Diego Salomao]

4 hours ago, Rolf Kalbermatter said:

Have you read the documentation text file included? There is a function rand() which calls the LabVIEW Random Number node and returns its values. Do not expect crypto quality randomness from this. The LabVIEW Random Number generator has been repeatedly investigated and found to have a reasonable randomness but with a limited interval. For most simple requirements that is quite enough, but if you need real crypto quality randomness there would need to be done a lot more serious work and then you quickly can forget to find this as a free library.

As to now() that's a bit tricky. The entire formula parser only really operates on doubles internally and doesn't have any other types. The newly hacked in bitwise operators were simply added by converting the double to an U64 for doing the bitwise operation then store it back as a double on the value stack. That should do for most bitwise operations for up to 32- bit integers but can start to get inaccurate if you chain many bitwise operators in a formula.

So what would you expect the now() to produces? A double representing the number of seconds since January 1, 1904 GMT, as the LabVIEW epoch is? Or rather since January 1, 1970 UTC as the Unix epoch is? Or maybe rather the number of days since January 0, 1900 as the Excel epoch, or would January 1, 1600 UTC be better as the Windows SYSTEMTIME is? You see lots of possibilities and all of them equally right or wrong, so avoiding that problem by not implementing it is simply the easiest solution. 😁

I understand. However, i have tried to run a simple expression in one of the examples of the library containing the function "rand", but an error was raised. Here´s the image attached.

[Rolf Kalbermatter]

1 hour ago, Diego Salomao said:

I understand. However, i have tried to run a simple expression in one of the examples of the library containing the function "rand", but an error was raised. Here´s the image attached.

Ahhh I misunderstood you. I thought you were referring to my own library that I had attached. But you are referring to the muParser library however. Can't help you with that one as I don't know the details of the actual muParser library that implements the logic in the background.

[Diego Salomao]

You're library is great. I like your implementation. Thanks for sharing with us.😃

[Porter]

On 8/3/2022 at 7:05 AM, Rolf Kalbermatter said:

You may want to try with this library. No guarantees about its proper operation. It's a quickly hacked together version from this library that I posted earlier. It's not really tested for the extra bitwise operators and there is no provision for correct left and right association of these operators, so it might require explicit bracketing to work as expected unlike in other languages and formula parsers that tend to follow the mathematical and/or C style conventions.

Do you have any plans to put this up on Github and/or vipm.io?

[Rolf Kalbermatter]

On 8/29/2017 at 6:33 PM, smithd said:

what about a calculated path (eg build a path control -- set to empty -- with your lib path). I was surprised by the 600 usec benchmark above -- my recollection from a few years ago was that overhead of a constant name in the CLFN vs one on the diagram was only a small overhead, maybe 13 usec vs 15 usec for some stupidly simple dll call.

My guess is that the library name in the CLN itself should be slightly faster if they would implement it the way I would. For a passed in library name they do need to verify that the library name hasn't changed compared to the previous execution so there is some overhead to compare the new name with the old one. It shouldn't even be in the uSec range however as comparing paths is mainly just a MemCompare for most of it, although in a loop for each path element itself. if the paths are the same, it doesn't need to do anything more.

If there is no path wired in, that check can be entirely skipped and LabVIEW nodes certainly have the option to check for that as it is an attribute of the node if it has the path input enabled.

As to calculating the path dynamically: You do want to cache the path in a Feedback node and only calculate it on first call. Recalculating it each and every time should be only necessary with very strange external DLLs, but not for platform and bitness differences only.

[Rolf Kalbermatter]

6 hours ago, Porter said:

Do you have any plans to put this up on Github and/or vipm.io?

Well I never have submitted anything to vipm.io and Github for such libraries feels more like a FINO (first in never out) than anything else. 🙂

May have to check the vipm.io submission procedure. After hacking above version I did look into it more and am considering to improve it to support some more operators and make it more C like in operator syntax (but no variable type support nor arrays or pointers). The main difference would be that the current exponent operator "^" would change to be the EXOR operator instead and for exponent one would need to call the according function.

[Diego Salomao]

Hello Mr. Kalbermatter,

i have a question. When i type an expression like: sin(pi/2)+exp(0)+floor(1.1), i keep receiving 1.1 as an answer. Do you know the reason?

 

Cheers

[Rolf Kalbermatter]

On 9/9/2022 at 8:43 AM, Diego Salomao said:

Hello Mr. Kalbermatter,

i have a question. When i type an expression like: sin(pi/2)+exp(0)+floor(1.1), i keep receiving 1.1 as an answer. Do you know the reason?

As mentioned. the library was a quick hack to another earlier library to add the bitwise operators. And it was likely a bit a to quick hack, messing up a few other things in the process. As you don't use bitwise operators I would recommend you to look at the original library, to which a link is included in that post.

[Porter]

I have updated to muParser version 2.3.4.

Is anyone willing to give it a test on LV Linux 32-bit and 64-bit?

Here is the latest code: https://github.com/rfporter/LV-muParser/releases/tag/V2.1.0

[Rolf Kalbermatter]

50 minutes ago, Porter said:

I have updated to muParser version 2.3.4.

Is anyone willing to give it a test on LV Linux 32-bit and 64-bit?

Here is the latest code: https://github.com/rfporter/LV-muParser/releases/tag/V2.1.0

The 32-bit version may be difficult to test. 2016 was the last version that had a 32-bit version of LabVIEW both on Mac and Linux. After that it was 64-bit only. Not sure how many people still have a 2015 or 2016 installation of those.

[Antoine Chalons]

I can't get it to work on Ubuntu with LV 2020 SP1

LabVIEW won't accept the so file and keep asking me to point to the file.

I've already seen some weird behaviors with CLFN on Linux when feeding the library path on the diagram but if the case of your 64 so file, even if I create a new VI, place a new CLFN and try to link to libmuparser-x64-lv.so LabVIEW then prompts me to find 'libmuparser-x64-lv.so'

 

[Rolf Kalbermatter]

16 minutes ago, Antoine Chalons said:

I can't get it to work on Ubuntu with LV 2020 SP1

LabVIEW won't accept the so file and keep asking me to point to the file.

I've already seen some weird behaviors with CLFN on Linux when feeding the library path on the diagram but if the case of your 64 so file, even if I create a new VI, place a new CLFN and try to link to libmuparser-x64-lv.so LabVIEW then prompts me to find 'libmuparser-x64-lv.so'

That means that your system misses some dependencies. To solve this we would need to have a list of possible dependencies and their version that this library may have. Aside from obvious dependencies that should be apparent to anyone having compiled this library you would also want to know the system and gcc version on which it was compiled. Depending on that there might be various other dependencies that your Ubuntu system may or may not come preinstalled with in the correct version.

[Antoine Chalons]

I see, I'm often struggling so files dependencies.

Making a single PostgreSQL VIP (starting from Dr. Powell's repo) that would support Linux, NI Linux RT and Windows took quite a bit of effort.

@Porter I can't dedicate time to dig into this issue, but I can run some test if you post a new VIP, good luck to you!

[Porter]

Thanks for giving it a try.

The library was compiled using gcc version 11.3.0 on Ubuntu 22.04. It uses openMP, but I don't think that is an external dependency.

I will try to get LV2020 community edition installed on my VM so that I can investigate further.

[Antoine Chalons]

i have ubuntu 20.04 and I don't have gcc installed, is it required?

i have gcc 9.4.0, shall i upgrade?

Edited December 21, 2022 by Antoine Chalons
checked gcc version

[Rolf Kalbermatter]

1 hour ago, Antoine Chalons said:

i have ubuntu 20.04 and I don't have gcc installed, is it required?

i have gcc 9.4.0, shall i upgrade?

gcc should only be required if you intend to recompile the shared library yourself. However glibc compatibility between different compiler versions always is a pitta. Usually compiling with the oldest version you expect to be used is best.

[Porter]

Shockingly it works just fine for me. Note that installing LV2022 on ubuntu 22.04 is not straight forward. Its best to stick with ubuntu 20.04. I also couldn't get VI package manager to install so I extracted the vip manually.

I did notice that the muparser .so files were not put in the right place. They should reside in /usr/local/natinst/LabVIEW-202X-64/resource/ and not in the vi.lib. Otherwise they won't be found.

Edited December 21, 2022 by Porter

[Porter]

This vip will put the .so files in the resource directory: lv_muparser-2.1.0.2.vip

[ensegre]

Same result as Antoine also for me here, LV2021-64, Ubuntu 20 (gcc 9.4.0), both with muParser version 2.1.0 and 2.1.0.2, even specifying the library path directly inside the CLFN, explicitly using the .so in <vi.lib> (2.1.0) or <resource> (2.1.0.2). I'd vote for missing dependency. The moment I'll remember how to check with ld, nm, etc. I'd seek which.

[Antoine Chalons]

yep, still no luck on my side

[ensegre]

Quote

$ ldd /usr/local/natinst/LabVIEW-2021-64/resource/libmuparser-x64-lv.so
/usr/local/natinst/LabVIEW-2021-64/resource/libmuparser-x64-lv.so: /usr/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /usr/local/natinst/LabVIEW-2021-64/resource/libmuparser-x64-lv.so)
/usr/local/natinst/LabVIEW-2021-64/resource/libmuparser-x64-lv.so: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /usr/local/natinst/LabVIEW-2021-64/resource/libmuparser-x64-lv.so)
    linux-vdso.so.1 (0x00007ffcd6953000)
    libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f2da3b77000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f2da3995000)
    libm.so.6 => /usr/lib/x86_64-linux-gnu/libm.so.6 (0x00007f2da3846000)
    libgcc_s.so.1 => /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f2da382b000)
    libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007f2da3639000)
    libdl.so.2 => /usr/lib/x86_64-linux-gnu/libdl.so.2 (0x00007f2da3633000)
    libpthread.so.0 => /usr/lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f2da360e000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f2da3c67000)

 

[Porter]

I will setup a Ubuntu 20.04 VM tonight and recompile against gcc 9.4