LabVIEW
There is a negative number in the square of the real number. please help me
Also try to downconvert before attaching (file...save for previous). At this moment, virtually nobody is using LabVIEW 2018 because it just came out less than a week ago.
This Snippet shows (part of) the code you submitted:
There are many things that are not exactly "wrong", but that contain "traps" and "mistakes". The heart of your calculation is to find the distance between two points represented by a cluster of 2 I16 coordinates (conveniently called "x" and "y"). For convenience, I'm going to call the two points P1 and P2. Here are some things to consider:
- Consider the point P3 = (x1, y2). This lies directly above (or below) P1, and directly to the left (or right) of P2, hence P1, P2, and P3 form a right triangle, with hypotenuse P1, P2 and legs P1, P3 and P2, P3.
- The hypotenuse of a right triangle is at least as long as the longest side, and can be considerably longer. For example, the hypotenuse of a square of side "s" is 1.414 s.
- If the coordinates of the points are represented by an I16 quantity, the distance between the points might be larger than the maximum I16 number, that is, might be larger than 32,767, and hence not representable as an I16 value! This is probably the source of your problem.
- Your code shows a lack of understanding about LabVIEW quantities. Here are some things I would change:
- I would get the distance between the points (represented by the X,Y cluster) by subtracting the Clusters directly.
- I would calculate the length of this "point" by doing the following sequence: Cluster to Array, Index Array (without wiring anything to the Index, and "pulling down" the Index terminal to give two indices, allowing me to get x and y components with a single Index Array function), converting the two I16s to Dbls, squaring/adding/square-rooting, ensuring the result is <= 32,767, and converting back to I16 if desired.
- You should not use an Extended value as the Index in Index Array!!
- You do not need any Absolute Value functions in this calculation.
Try rewriting your routine, once you understand what I'm trying to say, above. I've deliberately not provided a Block Diagram, as I think you will learn and understand better if you read what I wrote and then try "doing it yourself".
Bob Schor
Since the result is floating point anyway, converting the two points to complex would make things even simpler. No need for squares or square-roots. (The absolute value of a CDB is r in DBL).
And yes, as bob said, if you square an integer having a limited number of bits, the result is arbitrary if it does not fit in the valid range and can even be negative. If it is negative, you are definitely getting a wraparound and taking the absolute value will not be the correct value. Even if the square value is positive it is not guaranteed to be the right value. For example 32764² calculated in I16 results in 16, definitely not right even though it is positive. As a rule of thumb, to safely square an integer, the result needs up to twice as many bits used by the input.
(Hey, now we suddenly need the absolute value function after all! :D)
or alternatively (but watch out for wraparound in the subtraction!):
