X___

https://www.reuters.com/markets/deals/ni-explore-options-including-sale-amid-interest-emerson-electric-sources-2023-01-13/

Somebody please give access to LabVIEW source code to Rofl, pretty please?

Someone gives Rolf access to the source code, pretty please?

No. That was my second error in two attempts, so I considered the experiment done for me for the time being. I had a similar experience with stabilityai (the graphic AI) where the outputs I got were complete garbage, so I suppose I am just not doing it right and don't have the patience to "play" with the thing. Apparently, for pure text stuff, you need to reiterate and massage the question to get something that is acceptable. For LabVIEW code, by the way, the latter tool might be more appropriate... or not (try it at https://huggingface.co/spaces/stabilityai/stable-diffusion). Here are the results of ("a LabVIEW diagram adding two numbers" - Negative prompt: "not a NXG diagram"): One more reason to switch to Python?

Here is a little fun I had with ChatGPT: Me: what is the infinite sum 1-2+3-4+5-6... equal to? ChatGPT: The infinite sum 1-2+3-4+5-6... is a so-called "alternating series," because the terms have alternating signs. This series does not converge to a single value. In other words, it does not have a sum in the usual sense. If we take the first few terms of the series, we can see that the sum oscillates around a particular value and never settles down to a fixed number. For example, if we take the first 10 terms, the sum is -4. If we take the first 100 terms, the sum is 8. If we take the first 1000 terms, the sum is -32, and so on. In general, the sum of the first n terms of the series is given by the formula (-1)^(n+1) * (n+1)/2. This formula shows that the sum oscillates between positive and negative values as n increases, and it never converges to a single value. It is possible to assign a meaning to the infinite sum of an alternating series by considering the limit of the partial sums as the number of terms goes to infinity. This is known as the "alternating series test," and it can be used to determine whether an alternating series converges or diverges. However, in the case of the series 1-2+3-4+5-6..., the alternating series test cannot be applied, because the terms of the series do not approach zero as the number of terms increases. Comment: so far, so good. Me: but the sum of (-1)ˆn * n*(1+x)ˆ(n-1), for n = 0 to infinity has a finite value for x = 0 . And that is formally -1 + 2 - 3 + 4 - 5... ChatGPT: Yes, that is correct. The series (-1)^n * n*(1+x)^(n-1) does have a finite sum when x = 0, and this sum is equal to the infinite sum 1-2+3-4+5-6... To see this, we can use the formula for the sum of a geometric series: Sum = a * (1 - r^n)/(1 - r) where a is the first term of the series (in this case, a = -1), r is the common ratio (in this case, r = -1), and n is the number of terms in the series. If we plug in the values for a, r, and n and set x = 0, we get: Sum = (-1) * (1 - (-1)^n)/(1 + 1) = (-1) * (2 - (-1)^n)/2 = (-1)^(n+1) * (n+1)/2 This is the formula we obtained earlier for the sum of the first n terms of the series 1-2+3-4+5-6.... So, the sum of the series (-1)^n * n*(1+x)^(n-1) when x = 0 is indeed equal to the infinite sum 1-2+3-4+5-6... Comment: the sum is not that of a geometric series. It is the first derivative of sum (-(1+x))ˆn) = 1/(2+x), so the derivative is -1/(x+2)ˆ2. Of course, this requires 1+ x < 1. Me: That's wrong. The formula is sum of (-1)ˆn * n*(1+x)ˆ(n-1), for n = 0 to infinity equals -1/(x+2)ˆ2. Therefore -1 + 2 - 3 + 4 - 5... = -1/4 Comment: In retrospect, that may have been a bit too blunt for a US-trained AI... ChatGPT: I apologize for the mistake in my previous response. You are correct that the sum of the series (-1)^n * n*(1+x)^(n-1) for n = 0 to infinity is equal to -1/(x+2)^2 when x = 0. To see this, we can use the formula for the sum of an infinite geometric series: Sum = a/(1 - r) where a is the first term of the series (in this case, a = -1) and r is the common ratio (in this case, r = -1). If we plug in the values for a and r and set x = 0, we get: Sum = (-1)/(1 - (-1)) = (-1)/(1 + 1) = -1/2 Then, we can use the formula for the sum of an infinite series in which each term is the product of a constant and a series: Sum = a * Sum(b) where a is the constant (in this case, a = n) and Sum(b) is the sum of the series b (in this case, b = (1+x)^(n-1)). If we plug in the values for a and Sum(b) and set x = 0, we get: Sum = n * (-1/2) = (-1)^n * n * (-1/2) = (-1)^n * n/(-2) = (-1)^n * (-1/2) * n This is the series (-1)^n * n*(1+x)^(n-1) for n = 0 to infinity. Therefore, the sum of this series when x = 0 is indeed equal to -1/4, as you stated. Again, I apologize for the error in my previous response. Please let me know if you have any further questions. Comment: if that sound like gibberish to the non-mathematically versed reader, that's because it is. Me: yes I do. How come an infinite series that oscillates and seems to diverge in absolute value, as you pointed out, can converge to a finite value? ChatGPT: An error occurred. If this issue persists please contact us through our help center at help.openai.com.

Thanks for clarifying that. I forgot to mention that this "feature" has indeed nothing to do with what happens in the Python function itself (which could be a simple return() statement). And that I tested this in LV 2021 SP1. I haven't tested this with the Matlab node (which is way worse than the Python node, as it loses connection with the Matlab instance as soon as an error is thrown, requiring the process to be killed in the Windows Task Manager, while at least in the Python node, you get the Python error code and message as part of the error cluster and - generally, but not always - can recover from this and reuse the Python session refnum). Let's say I wouldn't be shocked if the same feature existed. This being said, the workaround is straightforward: store the error in before calling the node, and if it is a warning, pass a no error to the node, and merge the error cluster output of the node with the stored error in before continuing.

Take an Open Python Session Node, pass an error cluster with a non-zero error code (but otherwise status = FALSE and empty Source string), connect the outputs to a Python Node (and use a Close Python Session node if you want afterwards). Run. The Open Session Node transmits the warning (so doesn't generate an error) but the following Python Node converts the warning into an error (same code, TRUE status and source = Python Node in Calling VI name). That is unexpected.

Another interesting tidbit: you cannot "Find All Instances" of an error ring. And you cannot search for an error code (or an error message for that matter) and expect error rings to be returned as part of the search results. The error rings live in a separate...ring (the mathematical structure). Yet, they are pretty much indispensable if you use custom error codes...

The snippet below shows some oddity I uncovered while trying to document a bit of code involving the Python node. The error constant is just here to provide a cluster input to the node (which is what the "Marshal to Named Tuples" is supposed to handle). The Always Copy node is here to go around the known problem that the comment arrow will snap to the middle of the wire it is attached to, NOT where the user connects it to the wire (and that of course will never change). The comments indicate that the first node input (which happens to be the return argument, but that has no bearing o the observed behavior) has been right-clicked and "Marshal to Named Tuples" was used. By contrast, the second node input has had no modification applied. The result (surprising to me) of the "Marshal to Named Tuples" option was that the wire broke, as if the node lost its ability to "read" the cluster element names. Obviously no such thing happens when making a copy of anything (you can still hover over the lower branch of the wire with a probe and the Help window will show all 3 cluster element names). I am erring on the side of calling this a bug, but it might just be some kind of arcane feature of the node which only its author is familiar with (and I don't really whether or not it changes in the future since I am dug in 2021 SP1). But here it is for every one to gawk at.

Forgot the "dark humor" flag/emoji.

https://community.openmainframeproject.org/c/cobol-technical-questions/16 Looks familiar?

It's not a general purpose programming language.

The relative difference between the two appears to decrease with the size of the array, suggesting this is an initialization step (sanity checks) issue. On my machine: N | no String Conversion | with String Conversion | -------------------------------------------------------------- 10 | 750 ns | 400 ns | 100 | 700 ns | 1000 ns | 1000 | 5600 ns | 5100 ns | So approximately 300 ns more for the no String Conversion case, which becomes a negligible difference for large array. I would argue that large arrays are more common in this type of conversion tasks, but this is interesting to know regardless. I would also argue that there are vastly more irritating oldies in the LabVIEW code base that would deserve attention, but we know how that flies in Austin.

I would find this related post kinda funny: https://forums.ni.com/t5/LabVIEW/how-to-associate-a-license-with-my-NI-account/td-p/4256133 if a colleague of mine had not reported the exact same problem of a suddenly expiring permanent license (for the 2021 Vision Development runtime). The response she got was "they are refusing to reactivate it or even explain why it was deactivated in the first place". It looks like a class action lawsuit in the making. Any lawyers reading this?

13 years later, this is still not documented in LabVIEW. And since in the meantime the Matlab node has also changed, you now need to reate a little "ClearAll.m" Matlab helper script that contains: function ClearAll() clear functions end and call it before your node of interest when developing...

It took me a handful of calls before I found one person who was willing to take up the case. It's been such a long time since I got some really helpful support from NI that I am starting to believe in a miracle (I forgot to mention that I was provided temporary activation codes for the different computers and software packages I needed to work. Those expire in a couple of weeks, so I may end up with a complete meltdown again). If that guys quits on me or is fired, I am afraid I am running out of options. I guess what saves NI from having my university on their neck is that no-one is pretty much using LabVIEW anymore? Meanwhile NI is offering $100 for 1-on-1 Teams calls for users to help them improve their docs and publishes a roadmap with two columns: soon and later. The ambition is bursting at the seams...

Update on "disappearing" permanent license. Well, there is at least one helpful person at NI, and I was lucky enough to find him... Long story short (this has been going on since my last post on the topic, more than 2 weeks ago) NI screwed up internally (or, a possibility that was cautiously hinted at, the licensing code is buggy) and voided our permanent license. After (presumably) some testing, they haven't been able to fix the problem and offered me to: 1) exceptionally issue a new permanent license number that will replace our voided one. 2) escalate the issue to the R & D team to figure it out (the hint I was referring to). I chose 1 after having strongly suggested they go for 2) anyway, as I (we) can't be the only one affected. It also turned out that they screwed up our license renewal (i.e. the migration to an annual academic subscription license) and gave our Department a quote for a one month (!) license, soon to expire. I don't really care about that one, as I have no intention to upgrade, but just sayin'... There is truly something rotten in the State of Denmark.

You have two very similar threads on this forum, which makes it difficult to have a linear discussion: https://lavag.org/topic/22489-let%E2%80%99s-make-deep-learning-easy-with-haibal-library-on-labview/#comment-142891 We all agree that graphical programming has tons of advantages over pages of text code. However, most of us hate to be arm-twisted in having to pay annually for new versions of a language that fixes bug at a snail pace (if ever), release features that take 2 to 3 versions to work as advertised, and is offering abysmal level of technical support (and the list of recriminations could go on and on). Your toolkit looks truly amazing, but I would argue that you are not alone in having invested massive amount of time and effort in G-code. Yet, some of us who have, have come to the conclusion that we cannot reasonably tie our work to NI's whim and suicidal plans for LabVIEW. I have decided to migrate as fast as I can to Python. I'd argue that someone who is willing to do so (migrate to Python) will find the resources to master the basics of DL in Python, not mentioning that you'll have to keep running to stay on top of the new developments in the field with your toolkit. How you can hope to do that for free is a mystery to me. As I said, admirable, but a tad idealistic... Sorry for being he bearer of bad news, but "un homme averti en vaut deux", as the French say.

To tell you the truth, right now I am feeling owned for not being able to open LabVIEW 2021 SP1 after having installed it in December 2021 under a "permanent" Academic License (idem for the Vision Development Module). I am being told there never was such a thing as a permanent academic license. Oh yeah? So why can I open my LabVIEW 2019 SP1 and LabVIEW 2018 SP1 versions installed with the same license number on the same machine? I forgot to say that another NI employee I was talking with today (I talked with three, not including the Newark guy) told me that this was impossible because an academic license was only supposed to allow using the latest version of LabVIEW. Needless to say, she had nothing to answer to my explaining what I just said in the previous sentence (that is that I was running TWO old versions simultaneously). So far, I haven't talked to a single NI employee who seemed to really know what they were talking about. It's absolutely all downhill and I have absolutely zero trust in this company. Stock is doing great though, so the smokescreen and psychedelics are doing wonders.

BTW, if someone still believe that a debug and deployment license will allow them to develop software, they need to wake up or prove that this is the case. According to the NI home employees (and beyond, see below) I talked to, that is not the case. For LabVIEW, for Vision Development Module, etc. True, these are PERMANENT licenses, but you can't do much with them. The funny part is that a guy from Newark (the company that distributed NI product, to which NI sales transferred me to get additional information - this gets better by the hour) tried to explained to me that with a debug and deployment license, you cannot develop new code, but you can debug and fix a released executable (exe file). I asked him how that would work and then thanked him very much. 😭

Agreed, it is a shame.

I wished I could be as excited as this deserves, but with the abysmal transformation of NI in a money machine making it impossible to get support for something as simple re-activating a permanent license, I am on my way to Python...

As part of their 100-year of "Engineer Ambitiously" TM "at your speed", NI has in fact implemented a very clever strategy to motivate people from migrating away from their products: make permanent license re-activatable every year and make the reactivation process completely opaque or downright impossible. The idea is that after a few frustrating phone calls ending in the connecting ending in prolonged silence after an attempted "transfer" with tech support, you are supposed to give up and write off 25+ years of code development using a desperately closed and outdated language to finally embrace the open source Now tech support is working from home, so they are probably free to decide that they won't pick up calls, or maybe the call routing system at NI is hopelessly rotten (dropped calls appear to be systematic), but this problems would not exist in the first place if permanent licenses were really what their name indicate. This is not just me saying that: https://lavag.org/topic/22538-labview-activation-issues/ I am not in a mood or position to file a lawsuit, but this is erring on the side of commercial deception...

Just don't hold your breath.