labview challenge

[NeilR]

Clearly the key to this challenge is speed optimisation.
What hints and tips do you guys have for achieving accurate timing measurement.
The obvious way is to have a mega for-loop with a tick count on entry and exit.
The other way I guess is to use the Profile VIs capability.
Are there any ways to reduce the effect of Windows "sticking its oar in" or methods
of achieving more accurate measurement.

[shoneill]

Well, for my measurements I basically stuck my entire code (terminals and all) in a big (well, not so big actually) for loop and set it to run i million times. Then I placed a sequence structure over this, and added a ms timer before and after the loop execution.

The difference in the ms timer before and after / 1 million is the ms taken for each run.

Shane.

[BruceAmmons]

I agree that the problem is way too simple as NI stated it. How do you get better times than sub-microsecond?

I actually suggested this challenge, but my intention was to use very large integers. This would force the use of BIG number representations and more complicated math. This way, you would have to come up with an intelligent guess for the root, check it, then modify it in an iterative process. This would require an actual algorithm instead of a simple calculation.

I was hoping NI would restate the problem after I pointed this out. At a minimum, they should correct the I32 to U32 so we can represent the numbers specified.

I suppose we could do our own challenge with larger integers if anybody is interested...

Bruce

[shoneill]

I'm starting to wonder about the sub-microsecond times myself.

It's basically using a single NI function. I let the thing run a million times in a loop, and the timer difference (ms) before and after divided by 1000000 gives me the time per iteration in milliseconds (or the time divided by 1000 gives the time in microseconds).

Someone correct me if I'm wrong.

There has to be more to it than that surely.

Shane.

[altenbach]

---

@Bruce Ammons wrote:
I suppose we could do our own challenge with larger integers if anybody is interested...

Bruce

---

I'd love to do that, still have a set of large integer math tools left over from the vampire challenge but I don't think I have enough spare time 😞
We would need to agree on a input/output format. How about decimal strings? Should "n" be limited to U32 or also be large?


I agree that the current problem is poorly formulated.

- At minimum, I suggest an alternate challenge that forbids any orange wires on the diagram.
- We also need a template so the connector pane of all entries match up for easier testing.
- The challenge does not forbid lookup tables, should they really be allowed?

[Heiko Fettig]

If I understand the rules correctly only external code, CINs, DLLs, EXEs are excluded. However, if I use a simple formula node with 'y=x**(1/n)' I get the nth root of x even with all the decimals.

What is the point of this challenge? I could understand it with integers larger than 32bit, but this way it does not make any sense.

[BruceAmmons]

Happily, I just heard from NI that they are going to revise the challenge to make it a little more difficult. We should be seeing the changes soon.

Bruce

[chilly_charly]

Hi everybody !

Of course calculating th nth power of a number is something that's achieved easily in LV. But that does not mean the speed is optimal. For instance, compare a square root timing to a cube root timing. 0.02 against 0.14 microsecond... a ratio of seven. The last figure stands for any root except 2. When dealing with integers, there should be methods to increase significantly the calculation speed. Have a look at :
http://www.mactech.com/articles/mactech/Vol.14/14.01/FastSquareRootCalc/

CC

[altenbach]

I fully agree that it is conceivable to beat the built-in function by using all integer math and bit shuffling, I just haven't found a way to do it (I can get within about a factor of two).

Dennis hinted above that the formulation of the challenge might change, but so far it's all still original. 😞 Will anything happen soon in this matter?

[BruceAmmons]

Well, I thought they were going to update it quickly. They sent me the revised version over a week ago, and we only made a few minor changes. I'm not sure what happened. Now that I am responding, they will probably update it today.

Basically, the input is going to be an integer string of up to 10,000 digits and a U8 value for N. The output will also be an integer in string form. The rest of the task remains essentially the same - find the Nth root of the input value. Now the challenge is to figure out an optimal way to represent the large numbers and to do the necessary math to calculate the root. It should require the use of all four basic math operations in large integer format, unless somebody knows a better way to do it than I have figured out so far.

I've been working on a solution for the last week or so, and now have a working version. I am at about 1.6 seconds for the square root of 10000 digits, but the time decreases rapidly with higher values of N. Interestingly, the size of N doesn't matter nearly as much as the size of the root.

Bruce