LabVIEW Minutiae (that may bite you someday)

[tobyscott]

Just spent a while trying to figure out what was causing me to get 2 EOL per write. When I wire an EOL constant to a Format into file on windows, it reads the CR LF and converts it to CR CR LF. Reading up on the help

"This function converts new lines, or \n, in the format string into the platform-specific end-of-line character, for example, CR/LF on Windows, CR on Mac OS X, and LF on Linux. If you do not want to convert new lines into the end-of-line character, use the Format Into String function and wire the resulting string output to the text input of the Write to Text File function. Then right-click the Write to Text File function and remove the checkmark next to the Convert EOL shortcut menu item."

So even if you have the os specific eol it still can do some converting!

[altenbach]

Here's one for the purists that always try to eliminate benign coercion dots.

First the scenario:

In order to avoid the coercion dot at "index array", the output configuration of "boolean array to number" has been changed to I32, nothing else.

I challenge anyone to guess the output value for the following code. You can click on the spoiler later.

(Yes, it would be pure evil to turn that into a CLAD question 😄 )

Spoiler

The issue is that the "sign extension mode" defaults on ON if the output is signed and the index here will be -3 and the element will be zero because that index does not exist. The fix in this case is to change the sign extension mode to "never" and everything will work as expected. See also my post in the Rube Goldberg thread.

It seems to be a serious omission that the sign extension mode is nowhere to be seen on the properties page where it should be featured prominently, not to be missed!

I have posted a relevant idea, please vote for it!

[Gregory]

Does it treat those 4 bits as the most significant bits and tack on 28 0's afterward? That would make the index decimal -1610612736 and give the default I32, 0?

Edit: I peaked at the answer, my guess was (mostly) wrong.

[altenbach]

No, they are LSB, but will get padded with ones for the missing bits if the last element is TRUE.

from the help

If we add another FALSE the the end of the array, things work just fine, of course:

[JÞB]

---

@altenbach wrote:

No, they are LSB, but will get padded with ones for the missing bits if the last element is TRUE.

from the help

If we add another FALSE the the end of the array, things work just fine, of course:

---

Excuse me for the obfuscation .  But I do recall that there are 7.1 and 4.1 depreciation calls for boolean.  I actually never completely understood. 

Could you elucidate?

Apperatly,  this might be related to another one of your Idea Exchange posts.  I'm provisionaly good with it,  would it break depression?  IDK!

[Yamaeda]

---

@JÞB wrote:

---

@altenbach wrote:

No, they are LSB, but will get padded with ones for the missing bits if the last element is TRUE.

from the help

If we add another FALSE the the end of the array, things work just fine, of course:

---

Excuse me for the obfuscation .  But I do recall that there are 7.1 and 4.1 depreciation calls for boolean.  I actually never completely understood. 

Could you elucidate?

Apperatly,  this might be related to another one of your Idea Exchange posts.  I'm provisionaly good with it,  would it break depression?  IDK!

---

The last element is False, no?

[altenbach]

---

@Yamaeda wrote:
The last element is False, no?

---

Yes, if the last element is false, all is well.

If the boolean array size is N, the algorithm basically treats it as signed N-bit integer, i.e. the last boolean is the sign bit. This can probably be useful in limited cases, but I was surprised that sign extension is enabled by default.

(Also teaches you that blindly trying to eliminate coercion dots can have unintended secondary effects.) 😄

[JÞB]

---

@altenbach wrote:

---

@Yamaeda wrote:
The last element is False, no?

---

Yes, if the last element is false, all is well.

If the boolean array size is N, the algorithm basically treats it as signed N-bit integer, i.e. the last boolean is the sign bit. This can probably be useful in limited cases, but I was surprised that sign extension is enabled by default.

(Also teaches you that blindly trying to eliminate coercion dots can have unintended secondary effects.) 😄

---

Last bit is MSB, LSB. last (I think LSB) and sign (MSB) might be why I was often confused.   Set us all straight! (Please, ...)

[altenbach]

Since we are talking about boolean arrays where each element is a bit, first and last elements are well defined in terms of array ordering,

Element zero will the LSb, while the "last" (sic) array element will be the MSb (or the sign). See also.

To be more clear,  we use e.g. LSb, not LSB, because we are talking bits, not bytes. 😄