Numbers bigger then 10 to a array of integers

[Darin.K]

This problem came up a few days ago, I do not have my LV with me but I seem to recall from my testing then:

1) Overall winner was essentially MattW's method, speed + simplicity

2) Speed winnner is lookup table (about 2X faster), constraints are living with fixed width and padding and not too many digits.

3) Recursion wins coolness, loses by about a factor of 5 in speed on my machine

[Matt_W1]

---

@nathand wrote:

---

@matt W wrote:

This is faster than the previous two.

---

On my machine, at least, my approach is about 20ms faster (for 1 million 7-digit numbers).  Attached is the VI I used for benchmarking.

---

 Funny, mines faster in my benchmark and yours in your benchmarks. It took my a bit to figure out why. The reverse array in yours is producing a subarray and when the 2d array of digits is built in my benchmark it's apparently not done in the quickest fashion. I can fix that by using the always copy node (or a unit conversion to a different numeric type) just before the autoindex out on the for loop for your code. If I fix the problem (by forcing the subarray to a full array, your benchmark does it when exiting the case statement) your code wins by a bit. My first attempt at an answer was almost identical to yours but my flawed benchmark made me think that my second attempt was better. So yours is faster than mine, as long as your careful with handling the subarray.

[JÞB]

WELL,

That is "interesting to learn"  the recursive method ALSO had the execution priority set to "time critical".  Now I have some real questions.

• Were the FP's in memory? (this would reduce the footprint) or called without the FP's?
• In what version was the demo produced? post the VI please I would love to duplicate the results A factor of 5 that ( is) (may be) a bug!  supposedly sharing clones should save time and resources.

Nathand- reverse the array inside the loop- buy the method shown (yes you'll cross a wire)  add a variable for the base.  5x slower.  a BUG but a REALLY good bug to know about.

[Darin.K]

I missed Nathan's mod math post (the usual way). When I did this with a for loop I found very similar results to the String to Number version. No complaint with either method.

I suggest that you use mod math to break the number into four digit chunks, convert those using a lookup table and call this vi recursively to build the final array. 🙂

@Jeff - you are right, it is very important to keep in mind that pre-pending to an array is expensive, every element must be moved each iteration. Ouch

[nathand]

---

@Jeff Bohrer wrote:

WELL,

That is "interesting to learn"  the recursive method ALSO had the execution priority set to "time critical".  Now I have some real questions.

• Were the FP's in memory? (this would reduce the footprint) or called without the FP's?
• In what version was the demo produced? post the VI please I would love to duplicate the results A factor of 5 that ( is) (may be) a bug!  supposedly sharing clones should save time and resources.

Nathand- reverse the array inside the loop- buy the method shown (yes you'll cross a wire)  add a variable for the base.  5x slower.  a BUG but a REALLY good bug to know about.

---

Sorry, what?  I can't figure out what that last sentence is supposed to say.  "...the method shown?"  Shown where?

You can duplicate the 5x slowdown in my benchmark code, unless you're trying to tell me that that's what needs to be fixed.  I don't believe sharing clones works quite the way you think it does, because in a recursive algorithm like this there is no sharing of clones if I've correctly understood LabVIEW's implementation.  Share clones means that each time the recursive VI executes, LabVIEW uses an idle copy of the VI if one is available.  If not, then it creates a new clone and runs that.  In recursion like this, there will never be an idle copy available because all prior copies are still executing, so each time the code recurses, a new clone of the recursive VI must be made.

[JÞB]

Nathand-

None of my criticism of your code was went to be implied as a criticism of your skills!  ( Actually,I thought your post was inspired and "ripped"-it off somewhat)

I am surprised that the re-entrant solution underperformed your solution. 

By  "re-implement" I simply meant to "build array" with reversed elements to avoid the "reverse array" call after the loop.

I, Am curious to learn the outcome on a "benchmark'" machine---   (Mine has IT crap running that I can't stop!)

[勇]

请问TMS320C6713EVM开发板价格是多少啊？

[RavensFan]

Translation thanks to Google:

"Development board does TMS320C6713EVM What is the price ah"

Your question has nothing to do with this message thread.

Please either start a new thread in the board that is posted clearly in English, or post your question to the Chinese board.

[nathand]

For whatever it's worth, I don't see any substantial difference in timing in the recursive version between prepending to the array, versus appending to the array and then reversing afterwards.

I am surprised that converting to a string is so close in time to a purely mathematical solution, but I suppose internally the conversion to a string is doing exactly the same quotient/remainder division (perhaps in a more-optimized way) so that both approaches require a very similar set of operations.

[WG-]

Thanks everybody for the replies, I'm gonne use the recursive method or the one by nathand because that includes a base which was in fact exactly what I needed.