This NXT Area and Volume Calculator is a little math exercise for your NXT, which gets it to act like an electronic "rolling tape" measuring device, to calculate length, area, and volume in both metric and English units.
As some of you may know, the new NXT-G 2.0 software from LEGO Education has added support for "floating point" (non-integer decimal numbers such as 12.3) numbers and math. I was pondering what this meant for users of the existing NXT-G 1.x software, which only supports integer numbers and integer math. So I decided to cook up a little exercise to do some math that could benefit from floating point, but still done the integer way, so the program for this project will work in either NXT-G 1.X or 2.0.
For those interested, here is a brief summary of some of the issues. A basic technique of integer math is to pay attention to the order of operations and store results scaled up in precision if necessary. For example, if there are 2.54 cm per inch, how do you convert cm to in without decimals? Answer: in = (cm x 100) / 254. And if you wanted more precision, you could carry around tenths of cm (mm) and tenths of inches as integers, do your math that way, then divide down before displaying. A gotcha to look out for is "overflow" of your integers, which is not usually a problem with the NXT's 32-bit integers, but in this project it gets close to being a problem in practice. The measurements are stored in cm internally, and if you tried to calculate the volume of something as big as a house, you would overflow the integers. However, I set my sights on nothing larger than a room (and precision no more than cm), which works out, so I didn't have to do anything special. But FYI this points out something that floating point numbers do very well, which is handle a large variation in dynamic range (measuring very small things and very large things with the same program) without a lot of special handling in the program. If this program used floating point, it would be simpler, more accurate (could have used mm accuracy internally), and handle both larger and smaller objects at the same time. These issues can still be solved with only integers, but it gets very messy, especially in a block language like NXT-G. And speaking of messy, the last part of the program, which displays the volume in gallons displayed displayed as a decimal number rounded to tenths (e.g. "12.3") is a serious pain using integers and would be much worse still if you wanted to display more than just tenths. The new floating point number-to-text block in 2.0 does all this for you. No normal NXT-G 1.x user would want to deal with this, so a solution in practice for 1.x would be to use some external/imported blocks to do the messy parts, but you would still need to be aware of what unit/precision you are storing where, and whether that will suffice for your application. Or maybe just import a whole floating point support library if you need it (anybody have one of these?).
As some of you may know, the new NXT-G 2.0 software from LEGO Education has added support for "floating point" (non-integer decimal numbers such as 12.3) numbers and math. I was pondering what this meant for users of the existing NXT-G 1.x software, which only supports integer numbers and integer math. So I decided to cook up a little exercise to do some math that could benefit from floating point, but still done the integer way, so the program for this project will work in either NXT-G 1.X or 2.0.
For those interested, here is a brief summary of some of the issues. A basic technique of integer math is to pay attention to the order of operations and store results scaled up in precision if necessary. For example, if there are 2.54 cm per inch, how do you convert cm to in without decimals? Answer: in = (cm x 100) / 254. And if you wanted more precision, you could carry around tenths of cm (mm) and tenths of inches as integers, do your math that way, then divide down before displaying. A gotcha to look out for is "overflow" of your integers, which is not usually a problem with the NXT's 32-bit integers, but in this project it gets close to being a problem in practice. The measurements are stored in cm internally, and if you tried to calculate the volume of something as big as a house, you would overflow the integers. However, I set my sights on nothing larger than a room (and precision no more than cm), which works out, so I didn't have to do anything special. But FYI this points out something that floating point numbers do very well, which is handle a large variation in dynamic range (measuring very small things and very large things with the same program) without a lot of special handling in the program. If this program used floating point, it would be simpler, more accurate (could have used mm accuracy internally), and handle both larger and smaller objects at the same time. These issues can still be solved with only integers, but it gets very messy, especially in a block language like NXT-G. And speaking of messy, the last part of the program, which displays the volume in gallons displayed displayed as a decimal number rounded to tenths (e.g. "12.3") is a serious pain using integers and would be much worse still if you wanted to display more than just tenths. The new floating point number-to-text block in 2.0 does all this for you. No normal NXT-G 1.x user would want to deal with this, so a solution in practice for 1.x would be to use some external/imported blocks to do the messy parts, but you would still need to be aware of what unit/precision you are storing where, and whether that will suffice for your application. Or maybe just import a whole floating point support library if you need it (anybody have one of these?).