Numbers bigger then 10 to a array of integers

[WG-]

Okay I want to do the following...

I have a number (bigger then 10). Assume I got the number 4327 now I want to change this number to a numeric array with the values [4,3,2,7] as fast as possible.

I only thought of one solutions (which is possible also the fastest), but I want to know if anyone has maybe a better idea.

My solution is just to cast that number to a string using the NumberToString VI, "4327", then split into a array of strings ["4","3","2","7"], and cast it back using the StringToNumber VI.

Anyone got a better faster idea?

[SteveChandler]

If the range of input is not too huge the fastest way might be to precreate an array and index it

[JÞB]

Let the UI thread help you?  (works for any base!)

[nathand]

Why convert to strings and back?  Just use a bit of math:

[SteveChandler]

But are those two methods the "fastest" ways?

[Matt_W1]

This is faster than the previous two.

[nathand]

---

@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.

[JÞB · Accepted solution]

Absolutely not!

Although Nathand's solution could be expanded to work with any base as well. This may be a bit faster

the use of native recursion vs the buffer expansion should show in favor of the recusive technique up to a considerable number of digits.

[nathand]

---

@Jeff Bohrer wrote:

Absolutely not!

Although Nathand's solution could be expanded to work with any base as well. This may be a bit faster

the use of native recursion vs the buffer expansion should show in favor of the recusive technique up to a considerable number of digits.

---

Nowhere close, unfortunately.  Here's the benchmarking VI updated with your code, which is 4-5x slower than both my approach and Matt W's.  The recursive implementation is a good idea but LabVIEW's recursion is not terribly efficient.  Each recursive copy requires allocating an entirely new copy of the VI.

EDIT: uploaded recursive subVI, needed as well.

[altenbach]

---

@matt W wrote:

This is faster than the previous two.

---

I'd go with that, it is fast enough. 😄

However, make sure that the input is never negative. 😄