real division in an integer world

I declare i as integer (forgive me, old Fortran habits die hard) and perform the following calculations:

i=(Last_Date - First_Date)/NumSets


where xxx_date is a date (validated) and NumSets is integer.

Apparently, i is being rounded to the nearest integer.


ie: i=47/26 => 2
i=33/26 => 1

What gives?

DerFarm

You are asking why an integer is only holding an integer value? When you declare a variable (i) as integer, can't it only hold integer values? That would mean to get the results you want, you are probably going to have to use a single, or double. At least that's what I think.

Not at all. Effectively, integer means with no trailing decimals.

In other languages, integer = xnum/ynum with a real result would be interpreted as

integer=Int(xnum/ynum)

Here it is apparently integer=round(xnum/ynum,0)

Different kettle of fish altogether.


DerFarm

Try this:

Code:

---

Dim sngAvgSetsPerDay As Single ' Forgive me...VB habits die hard :)

sngAvgSetsPerDay =(Last_Date - First_Date)/NumSets

---

An Integer (or a Long) is a whole number, whereas a Single (or Double) can have a decimal number value.

Hope that helps!

I don't think your question was clear initially. I thought you wanted to know why the result was rounded to the nearest integer.

True, this is the way that VB handles it - rounding instead of truncating. Don't know why.

In your code you use the / operator

Code:

---

i=(Last_Date - First_Date)/NumSets

---

whereas you should use the \ operator instead. This op. divides

ex.:

Code:

---

Dim intVal As Integer

intVal = 11 \ 4  ' Returns 2.
intVal = 9 \ 3  ' Returns 3.
intVal = 10 \ 6  ' Returns 2.
intVal = 10 / 6 ' Returns 1.

---

try it, you'll like it ;)

Actually, rounding is more accurate, isn't it?

If you add the results of rounded numbers, you will be closer to the actual result than if you add the result of truncated numbers.

When adding numbers less or equal to .5 away from the whole part, the methods work identically. The further away you move from .5 toward the next whole number, the less acurate truncating is.

i.e:

Code:

---

' Actual numbers:
' 1.1 + 1.3 + 1.5 + 1.7 + 1.9 = 7.5
'
' Truncated numbers:
' 1 + 1 + 1 + 1 + 1 = 5  (difference = 2.5)
'
' Rounded numbers:
' 1 + 1 + 1 + 2 + 2 = 7  (difference = .5)
'
' *****  ANOTHER EXAMPLE  *****
'
' Using the same number over and over:
' 1.6 * 10 = 16
'
' Truncated version:
' 1 * 10 = 10  (difference = 6)
'
' Rounded version:
' 2 * 10 = 20  (difference = 4)

---

This leads me to believe that VB is a little more advanced than languages like C when it comes to converting decimals to whole numbers! :)

[Edited by seaweed on 10-03-2000 at 05:41 PM]

On average, truncating will produce an error of 0.5 per number. Rounding gives an error of 0. This is probably why it was chosen for VB.

But bear in mind that C is designed to be compact and excess-free, in which case it is best to discard the extra values. "If the programmer wants it rounded, then they can do it themselves" is basically its attitude!