A simple puzzler for the long (US at least) weekend...

[altenbach]

Here's a very simple program (LV2015).

Who can guess correctly (without running it!) what the output will be? 😄

Who can explain the result? (no units or such used. No hidden code!)

[zou]

Different display format.

[altenbach]

Both displays are whole numbers with the same number of digits shown. 😉

[RavensFan]

But George isn't technically wrong.

At least the Display Formats property page appears different between the indicator and the control. 

[alexderjuengere]

 

---

@altenbach wrote:

Who can explain the result? (no units or such used. No hidden code!)

---

it's a power of 2 ...?!

🤔

[Bob_Schor]

---

@alexderjuengere wrote:

it's a power of 2 ...?!

🤔

---

Not if it is a decimal representation -- powers of 2 end in 2, 4, 6, or 8.  It's at least got a factor of 10 = 2 * 5.  Trust Altenbach to drive us crazy ...

Bob Schor

[jamiva]

---

@zou wrote:

Different display format.

---

I think George is correct. If you look at the Advanced Editing Mode for the Display Format, the indicator's format is Decimal while the control is formatted as Floating Point.

[altenbach]

Yes, but why would they show a different value?

(For something different, enter NaN in the input control :))

[GerdW]

Hi,

some clarifications:

Does LabVIEW internally round to I64 when displaying numeric values formatted as integer?

The log2(x) indicates the maximum value possible for I64 (63 bit mantissa + 1 bit sign). It also indicates rounding errors for the DBL value because it contains only 52 bits of mantissa (+1 bit sign + 11 bits exponent)…

Even more details:

I added two more DBL floats, which differ in value by only 1 bit (as shown in flattened strings): their decimal value differs by >1000. Any (decimal) value in between is not accepted as input…

[altenbach]

While all very large DBL values are integers (of course!), for some reason LabVIEW takes the liberty to constrain them to the valid I64 range if formatted as %d, no matter how may digits we request (e.g. %100d makes no difference :D) Note that if we convert to U64 first, we actually get numbers up to 2x higher.

One might argue that %d should display any possible integer value, irrespective of representation, but we would of course run out of paper for things such as 1e+300. 😄

Obviously, the formatting algorithm takes some (reasonable?) shortcuts here, but I doubt that LabVIEW does it's own thing. Most likely these are some standard libraries and other programming languages show the same (not able to test). Formatting is relatively expensive, so speed is definitely crucial.