More bugs in Random Variable VIs

[X.]

I have already complained about the poor algorithms used in the Mathematics>> Probability & Statistics>>Probability>>Discrete Random.vi

I want to hammer down that these VIs need urgent revision, as they now prove to fail one more test, which is memory usage (and then some).

Take this simple piece of code:

On my (soon to be retired) Win XP machine, the result of this calculation is:

With 4GB available (but only 3GB usable in XP), I was a bit surprised by this, so I took a look at the offending piece of code.

Lo and behold, here is what happens in it:

First of all, what is the point of going through the Continuous Inverse CDF.vi for a uniform distribution to begin with? Wouln't it be optimal to just rescale the resulting array?

Second, I find it amusing that if you read the description of the Uniform White Noise (obs 90).vi used as a source, it reads:

Sure, well thanks for showing a good example, NI! And BTW, isn't the Uniform Random.vi we are looking at precisely the one we are suggested to use instead? Now I am confused...

Anyhow, let's have a look at this obsolete VI that is still being used in the latest LV version that I know of:

See the I32 values used in the generation initialization? 1234, 2345, 3456? Doesn't look optimized to me and I would be curious to see randomness test for this generator... But who cares about that sort of things nowadays?

In conclusion, I urge everyone who is serious about simulations (and thus who needs good random number generators) to stay clear from the offering by NI at this stage, as those VIs seems to have been programmed by non-experts (note that I am no claiming to be an expert, just a careful user).

And of course I suggest NI to take the time to rewrite those VIs ASAP.

[chaka1234]

Hi X,

Thanks for posting a detailed description. 

I will be working on this issue, and if necessary I'll file a Corrective Action Request.

Thanks!

CarmenC.

[X.]

As much as I appreciate your willingness to (maybe) file a CAR, I think what is missing here is an acknowledgment from NI that their implementation of fundamental functions need to be OPEN so that they can be VERIFIED and then (maybe) TRUSTED.

I am inclined to reach the same conclusion as Darin. K in this bug report thread (which BTW HAS NOT been acknowledged by NI), that is, that *ANY* VI calling a Call Library Function Node (CLFN) is suspicious until proven sound (which will never happen if the source is not posted). Since we have other things to do than extensively benchmark or reverse-engineer every single CLFN provided by NI, this essentially means that LV cannot be used for serious scientific work until a critical overhaul of its development policy is enacted.

And please do not tell me that you are using proprietary algorithms (as I have heard in the Vision Toolkit about obviously botched VIs)... A proprietary random generator or Kummer function algorithm? Come on!

In fact, it might be time to start writing most of these functions in G...

[tst]

---

@X. wrote:

On my (soon to be retired) Win XP machine, the result of this calculation is:

With 4GB available (but only 3GB usable in XP), I was a bit surprised by this...

---

Ignoring the rest of your post (I have no particular opinion on that) that number has 8 zeros, so it's actually 100M, or 800 MB of contiguous memory, which is often impossible to allocate. The VI also has the indicator inside the loop, which might require a second allocation (probably not, but my knowledge of that area is limited).

Or, since it says it stopped at the for loop, maybe that requires a second allocation. I can see a theoretical optimization where it reuses the buffer of the original array (since it's the only one processing it), but the parenthetical from the previous paragraph still applies.

[X.]

Good catch (and an opportunity to redirect everyone here). I am used to running out of memory on XP, hence my "soon to be retired XP" parenthesis. The buffer allocation at the autoindex in the For Loop in Uniform Random.vi is the culprit.

The point of my post was not to protest about that specific occurence, but rather about the horrors I discovered when popping the hood open.

[pobrepablo1]

Seconded, I agree completely. NI needs to realize nobody cares about stealing their "integration" algorithm, or anything else which has been documented extensively for decades now. Just post the code in G and be subject to peer review. 

it's especially bad when VI's are password protected. that just signals to me they did a sloppy job and don't want anyone to see what they've written. 

[X.]

---

@pobrepablo1 wrote:

Seconded, I agree completely. NI needs to realize nobody cares about stealing their "integration" algorithm, or anything else which has been documented extensively for decades now. Just post the code in G and be subject to peer review. 

it's especially bad when VI's are password protected. that just signals to me they did a sloppy job and don't want anyone to see what they've written. 

---

Now, you are being paranoid... 🙂

Actually, protecting bad code with a password would be already a step toward salvation...

Note that I am not blaming NI for using bad algorithms, or even using DLLs, but they should have a Google policy of rewarding everyone discovering bugs in their implementation, rather than having interns assigned to scour the forums at their leisure and politely promise (if that) to file a CAR...maybe.

[pobrepablo1]

I'm not saying it is bad code. But if you can't see what they're doing, who can tell? Of course, most companies e.g. matlab etc. don't provide source code, but I think most people feel they have earned trust, whereas these partial glimpses of questionable code from NI only hampers its image. Either post it in full or not at all, I say.

[tst]

Well, I do have possible reasons for why all of those are in DLLs, but I have no idea if they're true:

1. It would allow NI to reuse them in other products, such as CVI.
2. It's actually more efficient than G.
3. It was more efficient than G when it was written and it was never decided to invest the resources in rewriting it.
4. Same as 3, but replace the first part with "there was someone available who knew how to do it in C".

As for the locked VIs, NI usually says that it locks VIs not because they have bad code, but because they contain calls to functionality which NI would rather not let the general public have access to, because it can be dangerous.

[X.]

As an update, the LV 2015 version implement my rescaling suggestion but still uses the same call to a DLL with some dummy seed parameters.

And is fine with generating 1E8 values on a 64 bit machine with 16 GB of RAM.