X___

I was puzzled by that statement and since I am unable to do anything more demanding at this time, I checked the job offers at NI. There are 4 sites: Texas, Costa-Rica, Hungary, Malaysia. Most of the software-related postings appear to be API and driver related. I would be surprised that any of the frontend software is developed outside a tight-knit group in Austin (especially because NI is not an open source software developer, where delocalization is the rule).

Simple: to be understood by and be able to share code with others in academia. I have a few options: python, MATLAB, Mathematica, possibly C/C++ but certainly not LabVIEW. I dabble in all other languages, but in terms of cost and adoption, the choice is easy. I understand that for automation and delivering slick UI to paying customers it might not cut it, but if Emerson drops it, everyone will have to reconsider their options. As far as I am concerned, the writing has been on the wall a long time ago as far as LabVIEW was concerned. What saddens me the most is that its graphical paradigm hasn't percolated (much) in other languages (Node-Red and some other experiments being rare and not-so-impressive exceptions).

I don't know about that. For me multithreading works when all my cores usage are maxed out. I see that in both LabVIEW code and Python code.

I wonder whether Emerson knows that, and if so, what their logical conclusion will be moving forward. I mean, I have no doubt what they will decide.

My bad, I did not fully fleshed my proposal to Jeff K. I did not mean to rewrite LabVIEW in Python, but import some of the graphical concepts of LabVIEW into Python. Here is it: develop a Python module that allows representing python code graphically. The execution parallelism implemented in LabVIEW would probably be the trickiest part, but I am not sure I would require it initially. And implement some type and syntax checking breaking the "diagrams" at edit time rather than at compile/runtime (typos is what I hate in text-based languages).

You mean that sentence: I am not sure he means LabVIEW when he thinks "new technologies". After all that is more the purview of Colonel Kodosky... Who probably wouldn't mind a few extra 100 million dollars for... what about spinning off G and funding an open source project making a graphical Python-based LabVIEW?

That's maybe because, according to Reuters (https://www.reuters.com/markets/deals/emerson-makes-76-bln-bid-ni-corp-2023-01-17/), (company with a green and blue-themed website too...). So, their interest is probably not in supporting the development of a niche software that once pretended to be the programming language to run them all (or did it?) but is certainly not anymore. A lot of people at NI should probably get busy updating their profiles and checking job offers, if they had not been thinking of it after AQ's departure... BTW, I don't quite understand your previous argument that cofounders having a majority of shares would oppose a sale? Why would they not try to get as much money out of the sale and leave their families/heirs with a comfortable fortune to spend the rest of their lives?

I see...nothing. In any case, they already have taken Ni's color(s). Or is it the opposite? And as far as their slogan: "Go Boldly", this will be easy to merge with NI's: "Go boldly and engineer ambitiously... for twice the price!".

What software does Emerson have?

If I had wanted to be ironical, I would have typed LabVIEW 2023 Q5. And twitted it!

They are trying their best to snap NI at a bargain price, knowing full well that the picture will completely change when LabVIEW 2023 Q4 will be released, instantly doubling the value of NI share price.

https://finance.yahoo.com/news/ni-appoints-cfo-140000382.html

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.