PDA

View Full Version : 2013 Alignment Station Labels based on Time



sebastien795355
2015-04-01, 05:06 PM
So, here's the deal:

I programmed a series of expressions that will convert a station into a time stamp based on travel speed. It is very similar to a DEC->HMS system except it operates using a base scale factor for travel speed. I then made it calculate a tens digit and ones digit for both minutes and seconds to preserve digit offsets.

The problem is, I think it's pooping bricks in the calculations and is finding infinitely small redundancies causing a round down during the truncates. I'll list my code first then post results.

If your first answer is "ROUNDDOWN instead of TRUNC"... trust me, I've tried it. It just gags. First it spits out the parenthesis, then it spits out the R in ROUNDDOWN...

The basic system, without making two-digit results

TS Travel Speed
- m/hr value constant to be adjusted case-by-case

TS Hour Calc
({Station Value}/{TS Travel Speed})

TS Hour Trunc
TRUNC({Station Value}/{TS Travel Speed})

TS Min Calc
(({TS Hour Calc}-{TS Hour Trunc})*60)

TS Min Trunc
TRUNC(({TS Hour Calc}-{TS Hour Trunc})*60)

TS Sec
(({TS Min Calc}-{TS Min Trunc})*60)


What this should do is subtract the trancated value from the whole value, leaving the decimal to be brought to whole value of the next segment. What I am finding is a less-than-zero redundancy in the truncated values on perfect numbers which is carrying through, producing unwanted results.

For instance, 12'00" is coming out 11'60". I have then inserted each step into a label style to see their results. It is truncating the 12' as 11', then during the next stage it subtracts the truncated value leaving a 1 multiplied by 60.

I have also allowed for finite decimals (3 places) and in one stage it showed 3 zeroes, in another stage it shows 3 nines, for instance 11.000'59.999"

I personally think it's just pooping bricks on the formulas.


The next segment then creates tens and ones digits


TS Min Tens
TRUNC({TS Min Calc}/10)

TS Min Ones
TRUNC({TS Min Calc}-({TS Min Tens}*10))

TS Sec Tens
TRUNC({TS Sec}/10)

TS Sec Ones
({TS Sec}-({TS Sec Tens}*10))

I leave the last one to rounding so it can show decimals if needed. I'm finding some weird results yet again. For instance, the seconds becomes 510" because there is a finite redundancy being carried through the truncating.


Any help?

-Sebastien

sebastien795355
2015-04-01, 05:30 PM
Also, I forgot to mention - the problem is nonsystematic. It only happens every so often.

The redundancy in the seconds generally only becomes visible at the values that are more perfect in higher stages of the calculation, such as a perfect minute carrying into the seconds. The seconds errors can be hidden in the rounding, but still exist nonetheless.

sebastien795355
2015-04-01, 08:23 PM
I fixed the formulas by adding 0.001m just before the truncate. It basically rolls it just over the whole number forcing the truncate to recognize the number.

TS Travel Speed
- m/hr value constant to be adjusted case-by-case

TS Hour Calc
({Station Value}/{TS Travel Speed})

TS Hour Trunc
TRUNC({Station Value}/{TS Travel Speed}+0.001)

TS Min Calc
(({TS Hour Calc}-{TS Hour Trunc})*60)

TS Min Trunc
TRUNC(({TS Hour Calc}-{TS Hour Trunc})*60+0.001)

TS Sec
(({TS Min Calc}-{TS Min Trunc})*60)

The next segment then creates tens and ones digits

TS Min Tens
TRUNC({TS Min Calc}/10+0.001)

TS Min Ones
TRUNC({TS Min Calc}-({TS Min Tens}*10)+0.001)

TS Sec Tens
TRUNC({TS Sec}/10+0.001)

TS Sec Ones
({TS Sec}-({TS Sec Tens}*10)+0.001)

troma
2015-04-23, 06:27 PM
I seem to remember having trouble with the TRUNC function a while ago, and switching to the FLOOR function fixed it.
But I'm not totally sure on that. It was a while ago...!