In a table I have the sentence-length of convicted given in days (one year =
360 days, one month = 30 days). In a report I want to convert these days to
normal language, so f.ex 420 days would be 1 year and 2 months.

The code should be pretty straightforward, I thought, but the result seems
like a Paradox - at least to me. Here's the code:

vNumberDays = number(Field.Value) ; f.ex 420

;To get the years:
vNumberYears = floor(vNumberDays/360)
vLongIntYears = longInt(vNrÅr)

;And the months:
vNumberMonths = fraction(vNumberDays/360)*12
vLongIntMonths = longInt(vNumberMonths)

This code works very well, EXCEPT in one case: If vNumberDays = 390.
In this case vNumberMonths will be 1.00 - and it is. However
longInt(vNumberMonths) returns 0 (not 1, like it should). I have tested
this on two different machines, both with the same error. If vNumberDays =
750 you should expect the same error, if it was consistent, but in this case
the result is correct....

If I change
vLongIntMonths = longInt(vNumberMonths)
to
vLongIntMonths = longInt(vNumberMonths+0.01)
or to
vLongIntMonths = longInt(round(vNumberMonths,0))
the result is correct. So it seems to me that Paradox feels that 1,00
really is something like 0.9999...

Problem is: You don't know when Paradox is of this opinion. Can't I trust
it? Do I always have to put in some rounding to be safe?

Jostein Bakke

Jostein
<<
vNumberMonths = fraction(vNumberDays/360)*12
Why not
vnumbermonths=mod(vnumberdays,360)/30

Using fractions, you always have to round the results or add a small
fraction to compensate for effects of binary calculations.

--
Bertil Isberg - CTECH
Paradox buglist:
online: http://web.comhem.se/~u82608896/

"Jostein Bakke" <bakkeb (AT) online (DOT) no> skrev i meddelandet
news:4438996f (AT) pnews (DOT) thedbcommunity.com...

Thanks Bertil,

mod() has not "been in my box", but I see it will work well.

However, why is it that I dont have to compensate for effects of binary
calculations when I use mod()?

Or more to the point: How should I have known this difference between the
two methods?

Jostein

Jostein

309/360=1.083333333333333333333333333333

0.0833333333333333 *12 is probably not 1.000000000000 but rather
0.999999999999

What you could have done is to round the result of
vNumberMonths = fraction(vNumberDays/360)*12
to 2 decimals

vLongIntMonths = longInt(round( fraction(vNumberDays/360)*12, 2) )

When assigning a number to an integer, Paradox won't round it for you.


Using mod, I don't care about fractions
mod(vnumberdays,360)/30
will return 0, 1, 2,..............



--
Bertil Isberg - CTECH
Paradox buglist:
online: http://web.comhem.se/~u82608896/

"Jostein Bakke" <bakkeb (AT) online (DOT) no> skrev i meddelandet
news:443a167e (AT) pnews (DOT) thedbcommunity.com...

Jostein Bakke wrote:
WXP, pdx7.0.5.57,bde5.1, a script with ~ your code :
vNumberDays = number(390) ; f.ex 420
;To get the years:
vNumberYears = floor(vNumberDays/360)
vLongIntYears = longInt(vNumberYears )
vLongIntYears.view("vLongIntYears")
vNumberMonths = fraction(vNumberDays/360)*12
vLongIntMonths = longInt(vNumberMonths)
vNumberMonths.view("vNumberMonths")
vLongIntMonths.view("vLongIntMonths")

the last gives 1 and not 0

beside: why dividing by 360 instead of 365 or 365.25? Is it a commercial
convention?

bye
marco