How many decimal places can be stored in a register?
assuming R[1] = 5.5555
If I were to teach two points and tell the robot to move in R[1] seconds, would it lop off or round any of the numbers?
r-30ia v7.70
How many decimal places can be stored in a register?
assuming R[1] = 5.5555
If I were to teach two points and tell the robot to move in R[1] seconds, would it lop off or round any of the numbers?
r-30ia v7.70
the registers can contain integers or reals. Karel does not have floats, or any other format for very accurate calculations. Registers can be up to 32 bits using 2's compliment signed doubleword. This gives you a range From −2,147,483,648 to 2,147,483,647, from −(231) to 231 − 1. when a number smaller than 1.0 is needed, the karel shell will convert it to a 32 bit REAL. i suspect it uses IEEE 754, so it has a significance of 7 digits. this gives a range From -3.4028236E+38 through -1.175494E-38, 0.0, and from +1.175494E-38 through +3.4028236E+38, All REAL variables with magnitudes between -1.175494E- 38 and +1.175494E-38 are treated as 0.0.
i often have customers who want offsets displayed in thousandths of an inch. this poses a problem, as the built in hmi displays on the TP do not represent anything smaller than .0001 without converting it to scientific notation. when you start doing calculations at that level i recommend converting them to integers first and doing your calculations with whole numbers.
here is a excerpt from a wiki dealing with it. http://en.wikipedia.org/wiki/Floating_point
Addition and subtraction[edit]
A simple method to add floating-point numbers is to first represent them with the same exponent. In the example below, the second number is shifted right by three digits, and we then proceed with the usual addition method:
123456.7 = 1.234567 × 10^5
101.7654 = 1.017654 × 10^2 = 0.001017654 × 10^5
Hence:
123456.7 + 101.7654 = (1.234567 × 10^5) + (1.017654 × 10^2)
= (1.234567 × 10^5) + (0.001017654 × 10^5)
= (1.234567 + 0.001017654) × 10^5
= 1.235584654 × 10^5
In detail:
e=5; s=1.234567 (123456.7)
+ e=2; s=1.017654 (101.7654)
e=5; s=1.234567
+ e=5; s=0.001017654 (after shifting)
--------------------
e=5; s=1.235584654 (true sum: 123558.4654)
This is the true result, the exact sum of the operands. It will be rounded to seven digits and then normalized if necessary. The final result is
e=5; s=1.235585 (final sum: 123558.5)
Note that the low three digits of the second operand (654) are essentially lost. This is round-off error. In extreme cases, the sum of two non-zero numbers may be equal to one of them:
e=5; s=1.234567
+ e=−3; s=9.876543
e=5; s=1.234567
+ e=5; s=0.00000009876543 (after shifting)
----------------------
e=5; s=1.23456709876543 (true sum)
e=5; s=1.234567 (after rounding/normalization)
Note that in the above conceptual examples it would appear that a large number of extra digits would need to be provided by the adder to ensure correct rounding: in fact for binary addition or subtraction using careful implementation techniques only two extra guard bits and one extra sticky bit need to be carried beyond the precision of the operands.[11]
Another problem of loss of significance occurs when two close numbers are subtracted. In the following example e = 5; s = 1.234571 and e = 5; s = 1.234567 are representations of the rationals 123457.1467 and 123456.659.
e=5; s=1.234571
− e=5; s=1.234567
----------------
e=5; s=0.000004
e=−1; s=4.000000 (after rounding/normalization)
The best representation of this difference is e = −1; s = 4.877000, which differs more than 20% from e = −1; s = 4.000000. In extreme cases, all significant digits of precision can be lost (although gradual underflow ensures that the result will not be zero unless the two operands were equal). This cancellation illustrates the danger in assuming that all of the digits of a computed result are meaningful. Dealing with the consequences of these errors is a topic in numerical analysis; see also Accuracy problems.
Multiplication and division[edit]
To multiply, the significands are multiplied while the exponents are added, and the result is rounded and normalized.
e=3; s=4.734612
× e=5; s=5.417242
-----------------------
e=8; s=25.648538980104 (true product)
e=8; s=25.64854 (after rounding)
e=9; s=2.564854 (after normalization)
Similarly, division is accomplished by subtracting the divisor's exponent from the dividend's exponent, and dividing the dividend's significand by the divisor's significand.
Thank you for the info. The bulk of my calculations are done externally from the robot.
You have to be careful with doing math with mixed logic. Since the TPP shell has to convert the registers from INTEGERS to REALS on the fly, it does not always do it properly if you have a lot of nested logic. Memory allocation to a TPP program matters as well. If you write a program and it cant seem to do basic math correctly, reboot the robot and the compiler on the robot will recompile the program and re-instantiate the variables. you might notice this on changing the representation of positions from Cartesian to Joint. occasionally i will change the representation and the robot will throw up an alarm stating that there is not enough memory allocated to the kinematics to complete the operation and prompts me to reboot. once i do it works fine. I think this same thing happens with the math, but instead of prompting that there is a problem, it just tries its best. 8.10/02 had a big problem with doing that. i haven't seen it much since though.