From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

labview challenge

LabView Challenge - Nth Root Rumble.

Anyone out there know how it's possible to set an I32 to 4,294,967,296.

Shouldn't that be a U32 between 0 and 4,294,967,295
or an I32 between 0 and 2,147,483,647

Confused ...
0 Kudos
Message 1 of 48
(6,499 Views)
An I32 has a range of -2147483648 to 2147483648. There is a bit for the sign. A U32 has a range of 0 to 4294967295 (no sign). What exactly is your need for the numeric? There's been some discussions about different ways to represent I64 or U64. You might want to doa search of the forum for 64 bit to see if any of the topics apply to what you want to do.
Message 2 of 48
(6,453 Views)
Dennis

Thanks for replying. I think my original post wasn't quite specific enough.
If you check out the latest Labview Coding Challenge - Nth Root Rumble at :-

http://www.ni.com/devzone/lvzone/codingchallenge.htm

There is a requirement to use an I32 to set a value between 0 and 4,294,967,296. (!)
I guess this is just a mistake. I'm not sure who to flag it up to at NI to get clarification but obviously as it stands the challenge is pretty much impossible. 🐵

Regards
Neil
0 Kudos
Message 3 of 48
(6,431 Views)
Hello Neil,

Its how you look at the number!!

I have not looked at the challenge - When I get a Breather, I will.

But If you consider I32 and U32. The bits are the same 32 bits. You can use these bits to represent 4294967295 numbers.

In case of I32, we use the Most significant Bit to represent the Sign of the Number 0 is Positive and 1 is Negative so we can only represent Nos comprising of 31 bits, the MSB being Sign Bit. The Max Positive Number therefore is 0x7FFFFFFF = 2147483647

Say now you want the I32 to go to 2147483648 One greater than It can hold..? Well what is the Next Binary Number 0x80000000. In I32 this is -2147483648 and in U32 it is 2147483648
The Hex 0x80000002 is -2147483646 in I32 and 2147483650 in U32.

The Bit Pattern is same.. It is how we tell our mind to interpret this bit pattern. If you can convince your mind than you can convince the Program !!

Good Luck!!

Mache
Good Luck!

Mache
0 Kudos
Message 4 of 48
(6,420 Views)
It may be the same 32 bits, and you can convince your mind or look at it any way you want, but you cannot tell Labview to set an I32 to 4294967296. See attached vi. You can't even tell Labview to set a U32 to 4294967296 because the upper limit is 4294967295. It would take a U33(?) to hold the number 4294967296. The Labview challenge requirement is totally impossible.
- tbob

Inventor of the WORM Global
Message 5 of 48
(6,416 Views)
I agree that the challenge has a mistake. It must mean U32 instead of I32 and the challenge says BETWEEN 0 and 4294967296. To me, that means you would exclude 4294967296 and use the max of a U32 which is 4294967295.
0 Kudos
Message 6 of 48
(6,404 Views)
OK, I suppose a look-up table is prohibited, since the challenge says the vi must "Calculate" the Nth root.

At least a FULL lookup table seems to be excluded from this wording 😉

Shane.
Using LV 6.1 and 8.2.1 on W2k (SP4) and WXP (SP2)
0 Kudos
Message 7 of 48
(6,384 Views)

@Dennis Knutson wrote:
I agree that the challenge has a mistake. It must mean U32 instead of I32 and the challenge says BETWEEN 0 and 4294967296. To me, that means you would exclude 4294967296 and use the max of a U32 which is 4294967295.



OK, from this wording, we then can also exclude "0" for x, making input checking easier :). In addition, there is apparently no requirement on error checking and the results will be limited to integers. This means that for example inputs of e.g. [x=3, n=2] will not be an allowed input because the result is not an integer.

This looks way too simple!
0 Kudos
Message 8 of 48
(6,362 Views)
That was my reaction after thinking about it for a while.

I stuck a pretty simple, standard version for the calculation (proper calculation, no "cheating" 😉 ), and it came out at around 0.35 microseconds for a single calculation (I had to loop 1 million times to get decent timing results).

This corresponds to just over 500 processor clock cycles on my machine, which according to sources in the internet (discussing implementations in assembler) is somewhat slow.

I dunno, I reckon there are still different ways to optimise.

We'll see soon enough. The deadline is unusually close, so maybe this reflects the fact that NI thinks it's easy too.

Shane.
Using LV 6.1 and 8.2.1 on W2k (SP4) and WXP (SP2)
0 Kudos
Message 9 of 48
(6,332 Views)
OK, I have made a few quick prototypes that give the correct result, one of them has no orange wires. (I think that should have been one of the challenge requirements!) 🙂

With no orange wires, it's still a bit slow (16 microseconds for the example input), but I have some ideas for significant improvements. (W2k, 1GHz PIII).
0 Kudos
Message 10 of 48
(6,323 Views)