string to number conversion

[Mathan]

Dears,

I want to convert a string (obtained from a text file) to a number as like below.

If string is           2010101010101010101010100

no should be     2010101010101010101010100

but i am getting some other values as u c in my program.

i need the output values like if input string is 201010010100

i need the output in byte arrays like 20H, 10H, 10H, 01H, 01H, 00H

Is there any workaround?

Thanks

Mathan

Message Edited by mathan on 06-11-2008 01:58 AM

[MikeS81]

Hi mathan,

why do you need a workaround? Where is your error?
The biggest number which you can show in LabView as number is U64. And your is greater than 2e19.

Mike

[Norbert_B]

hope this helps,
Norbert


Message Edited by Norbert B on 06-11-2008 02:55 AM

[altenbach]

You are making the mistake to assume that you have a binary hex string while you actually have a hex formatted string.

Here's one possibility (LV 8.5.1), modify as needed:

Message Edited by altenbach on 06-11-2008 01:14 AM

[Norbert_B]

Altenbach,

it has nothing to do with mathan's question, but i am curious why you are using bitshift instead of devision. I first thought: Cool, this is faster for sure. But then i decided to benchmark it, with a surprising result in my eyes:
It seems that devision, even with coercion dots, is faster than bitshifts....
Can you perharps confirm this (or disprove it 🙂 )

thanks,
Norbert

[altenbach]

Well, a small scalar integer operation is peanuts either way, so completely insignificant for all practical purposes. 😉

Benchmarking any difference is extremely difficult, because of possible folding and UI issues, but I get about 5% faster for the bitshift. How do you benchmark it?

A bit shift is just the more natural way for me to do things, because any integer factors of two ARE bit shifts on integers so why go to orange wires and introduce three coercion dots in the process? 😄

[Norbert_B]

You are correct that both operations should be quite the same and very atomic, so there is no real practical background on this 😉

Here is my benchmark-vi. The difference is about 1s faster for the devision where the total time for the devision is about 1.5s....(default number of iterations with Dual Core @ 2GHz) which is quite huge. And i cannot explain the difference and therefore wrote the entry 🙂

thanks,
Norbert

[EDIT]: That is very odd... i closed the vi several times and reopened it with the same result as stated above. But i checked the "online-version" a few secs ago with inverted result. So now the bit shift is faster... and this is true for the offline version of the vi as well........ very very odd.....


Message Edited by Norbert B on 06-11-2008 04:32 AM

[GerdW]

Hi Norbert,

you should change your Benchmark just a little bit to avoid "constant folding" - this will make the benchmark more reliable.

For me there is no practical difference for this operation, both give the same speed (more or less, sometimes divide is some ms faster than bitshift, sometimes vice versa).

Edited:
Changed the benchmark.vi again to avoid UI issues (moved indicator out of the loop). Now bitshift is faster than division...



Message Edited by GerdW on 06-11-2008 11:52 AM

[Norbert_B]

Gerd,

i placed the indicator in the loop to suppress constant folding. But your approach is better i have to admit 🙂
Nevertheless, statistically my approach should work out too since both indicators are exposed to the same delays, so if the benchmark runs long enough, there should not be be any difference caused by this.

Another point i currently found out why my PC made some strange things: there was an autoupdate from Windows running in the background, so my system was not fit for any benchmark at all........

Norbert

[Mathan]

Dear all,

NorbertB's solution worked out for me.

Altenbach - I need byte array as final output and not a string array.

Thanks,

Mathan