Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Newcomers DBPro Corner / Choosing The Correct Variables [DBC/DBP]

Author
Message
TDK
Retired Moderator
22
Years of Service
User Offline
Joined: 19th Nov 2002
Location: UK
Posted: 13th Dec 2006 15:31 Edited at: 8th Feb 2007 00:53
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 DB 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#.

(DBPro has a number of other useful variable types, but are not included in this text so the information given here applies to both versions of DB).


Choosing The Type Of Variable To Use:

What variable 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 DB:

A=5
B=A/2
Print B
Wait Key


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#
Wait Key


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 is 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#
Wait Key


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:

Paste Image 1,100,100

which places the image 100 pixels across and 100 pixels down the screen.

The important thing to realise 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 matrices - one of them 100000x100000 units and the other 100x100 units in size. If all the objects are scaled down on the smaller matrix, 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

IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 13th Dec 2006 19:19
Quote: "prior to CPU's having Maths Co-Processors if anyone else remembers them"


Ah, the old days

On kinda the same subject, I see many people using byte and word variables in their code because they believe that because they are smaller than integers, they will be faster.

Wrong. Intel & AMD processors are 32 bit processors and are built to deal with 32 bit chunks of information - they will fetch 32 bits of information even if you want to use less, then they will spend extra time extracting the specific information you need before using it.



Stick to integers and floats unless you need bigger values (double integer, double float), and don't reduce the size of your variables below those.

IMO, the smaller variable types only have a use in a very few specialised situations, such as raw memory access.

indi
22
Years of Service
User Offline
Joined: 26th Aug 2002
Location: Earth, Brisbane, Australia
Posted: 13th Dec 2006 22:57
Can you guys amend this to the newcomers sticky, its valuable information.
If we get too many stickies we have to bundle them up so we dont have 20 stuck subjects at the top of each forum area.

Code Dragon
18
Years of Service
User Offline
Joined: 21st Aug 2006
Location: Everywhere
Posted: 27th Dec 2006 00:33 Edited at: 28th Dec 2006 17:27
Quote: "This is because in the line B#=A/2 both A and 2 are both integers so the result is 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."


Hmmm, I always thought that the variable A would get casted into a float because B is a float... I've been having trouble with type casting for quite a long time now, but I finally understand it now, thanks!

Quote: "I see many people using byte and word variables in their code because they believe that because they are smaller than integers, they will be faster.

Wrong. Intel & AMD processors are 32 bit processors and are built to deal with 32 bit chunks of information - they will fetch 32 bits of information even if you want to use less, then they will spend extra time extracting the specific information you need before using it."


That Visual Basic book lied! It said it was the operating system that fetches the 32 bits, but it doesn't really matter I guess. It's not really surprising that it does that, though, Windows IS a 32 bit operating system, so it will only work on 32 bit computers, right? I still use word variables when possible to save memory, but only in 2d programs because computers are now fast enough that we don't have to worry about 2d framerates. It only makes a difference in really huge arrays though.

I'm not sure if I should bother with variable types and optimising programs anymore, ultimately graphics will be rendered through a photorealistic raytracing engine, which will take up 99.9% of the execution time. Right now, optimising is kind of discouraging because optimised or not DBP makes code slower than C++, which I still can't figure out why. Then again, I want programs to run as fast as possible because there's always a customer with a slower computer.

"Did I ever tell you how I got the nickname the Dragon of the West?"
"I'm not interested in a lengthy anecdote, Uncle."
"It's more of a demonstration really."
TDK
Retired Moderator
22
Years of Service
User Offline
Joined: 19th Nov 2002
Location: UK
Posted: 28th Dec 2006 14:26 Edited at: 28th Dec 2006 14:27
Quote: "Hmmm, I always thought that the variable A would get casted into a float because B is a float... I've been having trouble with type casting for quite a long time now, but I finally understand it now, thanks!"


You are correct - that's how most other languages work.

Unfortunately DB works slightly differently - hence the confusion most users have with it. I suppose really that it would be more correct saying that DB doesn't really have proper casting.

In a nutshell, to force a calculation in DB to return a float, you have to use floating point numbers instead of integers.

Even in many tutorials, it's clear that the author doesn't understand this aspect.

TDK_Man

Login to post a reply

Server time is: 2024-11-26 05:47:55
Your offset time is: 2024-11-26 05:47:55