A fun question for the hardcore CLAD. What is the significance of 134217727

[CDuck]

Here's a fun constraint I discovered after running into an issue with divide by 0 causing 2^31 loop iterations.  I edited the number down to see what the actual limit for the loop iterations here is and it is 134217728. 134217727 works just fine.  So the question is what will probe 4 read after running the program?

Answer:

Spoiler

Due to Error "LabVIEW: (Hex 0x2) Memory is full." - The probe will read not executed.

134217727 is apparently the maximum size of this array, and LabVIEW knows not to even try executing it!

I would love to hear more info about why this was chosen as a constraint!

[BertMcMahan]

Well, if you run it in LV 64-bit, it reads 134217727 🙂

And if you change the Array type (and coercion node) to Single precision, it works just fine there as well.

I have a guess. 32 bit LabVIEW has a memory limit of 2 Gibibytes. 134217728x 8-byte doubles creates a value of 1 Gibibyte. I bet there is some buffer allocation somewhere that's doubling the memory usage accidentally, which hits the limit.