Beginners Guide To Programming - Part V Choosing The Correct Variables

Started by kevin, April 21, 2008, 07:21:41 AM

Previous topic - Next topic

kevin


TDK's Play Basic Programming For Beginners

Back To Index

Part 5 - Choosing The Correct Variables

Looking at the code posted by many users on the forums, it's clear that many of you are not sure about the difference between float and integer variables - or when you use them.

 Back when I started programming, (prior to CPU's having Maths Co-Processors if anyone else remembers them), computers were nowhere near as fast as they are now and we had to use every trick in the book to squeeze as much speed out of our programs as possible. This included using integer variables rather than floating point at every opportunity.

This was because it took a lot longer for a computer to do a floating point calculation than an integer calculation.

These days, this is still true, but as computers are so fast, it's not as critical any more. Even so, it's still pointless using floating point variables with numbers which can only ever be integers!

More to the point, using the wrong variable type can lead to errors in calculations and difficult to trace problems in your programs later on.



Variable Types:


 The three basic variable types common to both versions of PlayBASIC are String, Numeric Integer and Numeric Float (also called Reals).


      String variables have the $ symbol (dollar) on the end of their names - like MyString$.

      Integer variables have nothing on the end of their names - like Score.

      Float variables have a # symbol (hash) on the end of their names - like FireAngle#.





Choosing The Type Of Variable To Use:


   What variable type you use depends on what sort of information you need to store. If your variable is only ever going to contain whole numbers then you should use integer variables. If you are going to need the ability to calculate and store fractions then you should use floats.

   Choosing the wrong one can cause problems. For example, run the following example in PB:


A=5
B=A/2
Print B
Sync
WaitKey


 The answer is of course 2.5 but the program prints 2.   This is because A and B are integer variables and regardless of the calculation, the result becomes an integer when it's placed into an integer variable. So, you lose the '.5' off the end.

  To store a floating point number, you have to use a floating point variable - but there are pitfalls to be aware of even then. Take the above example ammended so that B is now a floating point variable:


A=5
B#=A/2
Print B#
Sync
WaitKey


 Note that when you run it, you still get the answer 2 instead of 2.5!

  This is because in the line B#=A/2 both A and 2 are both integers so the result of the division calculation will be an integer.   Even though the variable B# is a float, the result is still turned into an integer when it's stored. This is called variable typecasting.

  So what do you do if you have an integer and need to turn it into a float?

  Well, you simply make sure that the parameters in the formula you use are not all integers. For example, run the following snippet:


A=5
B#=A/2.0
Print B#
Sync
WaitKey


 Notice that as we have changed the divisor from 2 (integer) to 2.0 (float), when you run it, the answer is now correct - 2.5!



When To Use What:


 As mentioned previously, integers are faster than floats so are preferable to use when we can - we just need to know when to use the correct type.

  Working in 2D with the screen is a good example of where you should only use integers.

  The screen is usually something like 800x600 or 1024x768 and the values correspond to the number of pixels (screen dots) running across and down the screen.

  In 800x600 mode the 800 pixels running across the screen start at number 0 on the left and end at 799 on the right. Running down the screen 0 is at the top and 599 is at the bottom.

 Placing something on the screen requires the X and Y position values as in:

DrawImage 1,100,100,true

 Which places the image #1,  100 pixels across and 100 pixels down the screen.

 The important thing to realize here is that a pixel co-ordinate is a whole number like 100, 250 or 399. It can NEVER be a floating point number like 100.5 or 250.77 because you can't position anything on the screen between two pixels.

  So, any variables in any way related to 2D screen positions or moving screen objects around should be integer variables.

  Another area where you frequently see float variables mis-used is with the mouse.

  The mouse can only ever return whole numbers, so store the results in integers - not floats. There's nothing stopping you from using those integer variables later in calculations which result in float values if you need to - just remember the bit above about how to force calculations involving integers to return float values.

  In 3D however, we aren't talking about pixels any more, but 'units' - because they are not a fixed size like pixels. It's not easy to get your head around the concept at first, but 3D units are relative. 1 unit doesn't equal a centimetre, a metre, an inch or a mile - it depends on the size of the objects in the scene to convey 'size'.

 For example, think of two terrain - one of them 100000x100000 units and the other 100x100 units in size. If all the objects are scaled down on the smaller terrain, it can look the same size to the camera as the larger one - despite the hugely differing unit sizes of the matrices. A tree 20 units high would look enormous on the smaller matrix but miniscule on the larger one.

 So, the size of your objects define how big a 3D unit appears and it has nothing to do with the actual number of 3D units.

  What's more, they are not whole units - you can have fractional parts of a unit. Objects can be placed at locations like 100.2, 10.3, 100.7 and moved 0.1 units in any direction.

 As such, you would use float variables to store these values.

  So, in summary, only use float variables when you have to and your programs will be faster - and you'll avoid many problems when your programs grow bigger.

TDK_Man