Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #5981 > unrolled thread

Subtracting times

Back to article view | Back to comp.sys.acorn.programmer

Contents

  Subtracting times Alan Adams <alan@adamshome.org.uk> - 2020-02-18 11:55 +0000
    Re: Subtracting times Jean-Michel <jmc.bruck@orange.fr> - 2020-02-18 19:11 +0100
      Re: Subtracting times Steve Drain <steve@kappa.me.uk> - 2020-02-21 03:28 -0800
        Re: Subtracting times Alan Adams <alan@adamshome.org.uk> - 2020-02-21 12:45 +0000
        Re: Subtracting times Alan Adams <alan@adamshome.org.uk> - 2020-02-21 15:17 +0000
          Re: Subtracting times Steve Drain <steve@kappa.me.uk> - 2020-02-22 10:37 +0000
            Re: Subtracting times Steve Drain <steve@kappa.me.uk> - 2020-02-25 16:05 +0000
              Re: Subtracting times Alan Adams <alan@adamshome.org.uk> - 2020-02-25 16:35 +0000
                Re: Subtracting times Steve Drain <steve@kappa.me.uk> - 2020-02-27 17:10 +0000
                  Re: Subtracting times Steve Drain <steve@kappa.me.uk> - 2020-02-27 10:06 -0800
                  Re: Subtracting times Alan Adams <alan@adamshome.org.uk> - 2020-02-28 11:21 +0000
                    Re: Subtracting times jeffrey.a.doggett@gmail.com - 2020-04-22 12:00 -0700
                      Re: Subtracting times Martin <News03@avisoft.f9.co.uk> - 2020-04-23 00:07 +0100
                        Re: Subtracting times jeffrey.a.doggett@gmail.com - 2020-04-23 03:13 -0700
                          Re: Subtracting times Martin <News03@avisoft.f9.co.uk> - 2020-04-23 18:01 +0100
                            Re: Subtracting times "John Williams (News)" <UCEbin@tiscali.co.uk> - 2020-04-23 18:06 +0100
                              Re: Subtracting times jeffrey.a.doggett@gmail.com - 2020-04-23 11:18 -0700
                                Re: Subtracting times Martin <News03@avisoft.f9.co.uk> - 2020-04-23 21:23 +0100
                                  Re: Subtracting times David Higton <dave@davehigton.me.uk> - 2020-04-24 15:24 +0100
                            Re: Subtracting times David Higton <dave@davehigton.me.uk> - 2020-04-23 20:57 +0100
          Re: Subtracting times jgh@mdfs.net - 2020-02-23 17:39 -0800
            Re: Subtracting times Steve Drain <steve@kappa.me.uk> - 2020-02-24 10:23 +0000
              Re: Subtracting times Alan Adams <alan@adamshome.org.uk> - 2020-02-24 11:12 +0000
                Re: Subtracting times Martin <News03@avisoft.f9.co.uk> - 2020-02-24 13:05 +0000
    Re: Subtracting times Matthew Phillips <spam2011m@yahoo.co.uk> - 2020-02-19 08:35 +0000
      Re: Subtracting times Alan Adams <alan@adamshome.org.uk> - 2020-02-19 10:03 +0000
        Re: Subtracting times Sebastian Barthel <naitsabes@freenet.de> - 2020-02-19 13:04 +0000
          Re: Subtracting times Alan Adams <alan@adamshome.org.uk> - 2020-02-19 16:41 +0000
            Re: Subtracting times jgh@mdfs.net - 2020-02-19 12:01 -0800
        Re: Subtracting times Matthew Phillips <spam2011m@yahoo.co.uk> - 2020-02-23 20:46 +0000
    Re: Subtracting times Martin <News03@avisoft.f9.co.uk> - 2020-02-19 23:54 +0000
      Re: Subtracting times Alan Adams <alan@adamshome.org.uk> - 2020-02-20 11:18 +0000

Page 1 of 2  [1] 2  Next page →

#5981 — Subtracting times

My head is hurting.

I need a BASIC routine to subtract one 5-byte time from another and return 
a correctly signed result.

Complications arise at the point where the low word goes from &7fffffff to 
&80000000, and where the high byte increases.

BASIC doesn't allow access to the carry or borrow from arithmetic 
operations.

I've developed the following which *seems* to work correctly. However I'm 
not sure about all the edge cases.

This is part of a timing system, Next February the high byte of times will 
change from &57 to &58, and I would like this code to survive working 
across this boundary. I need to reliably detect negative results, which 
can occur if a spurious finish time pulse arrives before a start time.

Subtract stamp2 from stamp1 and store the result in resultbuf.
( Although the result is 5 bytes. the elapsed time will always be 
contained in the low 4 bytes. This will only overflow after 1 year, 5 
months and 2 hours 27 minutes. The system doesn't meed to run for that 
long. )
                                                                 
PROCsubstamp(resultbuf%,stamp1%,stamp2%)
LOCAL I%,J%,K%,L%,borrow%
borrow%=0
  FOR I%=0 TO3
    J%=stamp1%?I%
    K%=stamp2%?I%
    L%=J%-K%-borrow%
    resultbuf%?I%=L%AND&FF
    IF L% < 0 THEN borrow%=1 ELSE borrow%=0
  NEXT
  I%=4
  J%=stamp1%?I%
  K%=stamp2%?I%
  L%=J%-K%-borrow%
  IF L% < 0 THEN
    resultbuf%!0 = -(resultbuf%!0)
  ENDIF
  resultbuf%?I%=L%AND&FF
ENDPROC


-- 
Alan Adams, from Northamptonshire
alan@adamshome.org.uk
http://www.nckc.org.uk/

[toc] | [next] | [standalone]

#5982

In message <37f8364458.Alan.Adams@ArmX6.adamshome.org.uk>
          Alan Adams <alan@adamshome.org.uk> wrote:

> My head is hurting.

> I need a BASIC routine to subtract one 5-byte time from another and return
> a correctly signed result.

> Complications arise at the point where the low word goes from &7fffffff to
> &80000000, and where the high byte increases.

> BASIC doesn't allow access to the carry or borrow from arithmetic
> operations.

> I've developed the following which *seems* to work correctly. However I'm
> not sure about all the edge cases.

> This is part of a timing system, Next February the high byte of times will
> change from &57 to &58, and I would like this code to survive working
> across this boundary. I need to reliably detect negative results, which
> can occur if a spurious finish time pulse arrives before a start time.

> Subtract stamp2 from stamp1 and store the result in resultbuf.
> ( Although the result is 5 bytes. the elapsed time will always be
> contained in the low 4 bytes. This will only overflow after 1 year, 5
> months and 2 hours 27 minutes. The system doesn't meed to run for that
> long. )

> PROCsubstamp(resultbuf%,stamp1%,stamp2%)
> LOCAL I%,J%,K%,L%,borrow%
> borrow%=0
>   FOR I%=0 TO3
>     J%=stamp1%?I%
>     K%=stamp2%?I%
>     L%=J%-K%-borrow%
>     resultbuf%?I%=L%AND&FF
>     IF L% < 0 THEN borrow%=1 ELSE borrow%=0
>   NEXT
>   I%=4
>   J%=stamp1%?I%
>   K%=stamp2%?I%
>   L%=J%-K%-borrow%
>   IF L% < 0 THEN
>     resultbuf%!0 = -(resultbuf%!0)
>   ENDIF
>   resultbuf%?I%=L%AND&FF
> ENDPROC

from Steve Drain (ROOL Forum 18/12/2016)

I wrote a library to support some of this this, as have others. It is a 
candidate for Basalt, someday. ;-)

Look at http://kappa.me.uk/Libraries/lbLongs032.zip





Jean-Michel

-- 
Jean-Michel

[toc] | [prev] | [next] | [standalone]

#5991

Michel  wrote:
> Alan Adams wrote:
> > I need a BASIC routine to subtract one 5-byte time from another and return
> > a correctly signed result.
> from Steve Drain (ROOL Forum 18/12/2016)
> 
> I wrote a library to support some of this this, as have others. It is a 
> candidate for Basalt, someday. ;-)
> 
> Look at http://kappa.me.uk/Libraries/lbLongs032.zip

I suspect that this problem has been satisfactorily solved in plain BASIC, but that library I wrote a good while ago uses fragments of assembly to do the heavy lifting, because of the carry etc.

For interest's sake I put together a couple of routines to deal solely with 5-byte times using assembly at:

 http://www.kappa.me.uk/Miscellaneous/swTimeDiff.zip

I am not sure that I have got it right, so please pull it apart. ;-)

[toc] | [prev] | [next] | [standalone]

#5992

In message <80ec8ad6-58f7-4862-8ccd-34d8d5627c3c@googlegroups.com>
          Steve Drain <steve@kappa.me.uk> wrote:

> Michel  wrote:
>> Alan Adams wrote:
>>> I need a BASIC routine to subtract one 5-byte time from another and return
>>> a correctly signed result.
>> from Steve Drain (ROOL Forum 18/12/2016)
>> 
>> I wrote a library to support some of this this, as have others. It is a
>> candidate for Basalt, someday. ;-)
>> 
>> Look at http://kappa.me.uk/Libraries/lbLongs032.zip

> I suspect that this problem has been satisfactorily solved in plain BASIC,
> but that library I wrote a good while ago uses fragments of assembly to do
> the heavy lifting, because of the carry etc.

In BASIC it has to be done byte-by-byte, or using half-words, so that the 
borrow/carry can be detected.

> For interest's sake I put together a couple of routines to deal solely
> with 5-byte times using assembly at:

>  http://www.kappa.me.uk/Miscellaneous/swTimeDiff.zip

> I am not sure that I have got it right, so please pull it apart. ;-)

It looks good. I'll test it in a bit.

The boundary conditions seem to be when the low word goes from 7fffffff to 
80000000, when it goes from ffffffff to 00000000, and in each case when 
the arguments swap.

Then there are the cases where the high bytes differ.

There's no way to indicate with an integer return, the result when the 
high bytes differ by more than 1. Those cases are when the times are more 
than a year and a half apart, so in my case, won't occur.

-- 
Alan Adams, from Northamptonshire
alan@adamshome.org.uk
http://www.nckc.org.uk/

[toc] | [prev] | [next] | [standalone]

#5993

In message <80ec8ad6-58f7-4862-8ccd-34d8d5627c3c@googlegroups.com>
          Steve Drain <steve@kappa.me.uk> wrote:

> Michel  wrote:
>> Alan Adams wrote:
>>> I need a BASIC routine to subtract one 5-byte time from another and return
>>> a correctly signed result.
>> from Steve Drain (ROOL Forum 18/12/2016)
>> 
>> I wrote a library to support some of this this, as have others. It is a
>> candidate for Basalt, someday. ;-)
>> 
>> Look at http://kappa.me.uk/Libraries/lbLongs032.zip

> I suspect that this problem has been satisfactorily solved in plain BASIC,
> but that library I wrote a good while ago uses fragments of assembly to do
> the heavy lifting, because of the carry etc.

> For interest's sake I put together a couple of routines to deal solely
> with 5-byte times using assembly at:

>  http://www.kappa.me.uk/Miscellaneous/swTimeDiff.zip

> I am not sure that I have got it right, so please pull it apart. ;-)

I ran 10 sets of test data. I think it gets it wrong for the last 4. In 
each case the sign is wrong for the returned integer. The values are too 
small as well. These are the cases where the result is too large for an 
integer to hold.

The 5-byte integer values looks correct, but cannot be returned to BASIC.

I compared it with my BASIC routine. The adjustment I made after the last 
subtraction was wrong. Omitting it returned the correct answer.

A$ is the bytes (high to low) in a%, similarly for B$ and C$.
the dates are the conversion iof A% and B% to dates.

14:51:20.29 ** Clear **
A$="00 00 00 00 20 " B$="00 7F FF FF C0 " C$="FF 80 00 00 60 " 
!C%=-2147483552
A$="00:00:00 01-Jan-1900" B$="13:13:55 06-Sep-1900" !C%=-2147483552

A$="00 7F FF FF C0 " B$="00 00 00 00 20 " C$="00 7F FF FF A0 " 
!C%=2147483552
A$="13:13:55 06-Sep-1900" B$="00:00:00 01-Jan-1900" !C%=2147483552

A$="00 80 00 00 20 " B$="00 7F FF FF C0 " C$="00 00 00 00 60 " !C%=96
A$="13:13:56 06-Sep-1900" B$="13:13:55 06-Sep-1900" !C%=96

A$="00 7F FF FF C0 " B$="00 80 00 00 20 " C$="FF FF FF FF A0 " !C%=-96
A$="13:13:55 06-Sep-1900" B$="13:13:56 06-Sep-1900" !C%=-96

A$="00 FF FF FF 20 " B$="01 00 00 00 C0 " C$="FF FF FF FE 60 " !C%=-416
A$="02:27:50 13-May-1901" B$="02:27:54 13-May-1901" !C%=-416

A$="01 00 00 00 C0 " B$="00 FF FF FF 20 " C$="00 00 00 01 A0 " !C%=416
A$="02:27:54 13-May-1901" B$="02:27:50 13-May-1901" !C%=416

A$="01 FF FF FF 20 " B$="00 00 00 00 C0 " C$="01 FF FF FE 60 " !C%=-416
A$="04:55:43 22-Sep-1902" B$="00:00:01 01-Jan-1900" !C%=-416

A$="00 00 00 00 C0 " B$="01 FF FF FF 20 " C$="FE 00 00 01 A0 " !C%=416
A$="00:00:01 01-Jan-1900" B$="04:55:43 22-Sep-1902" !C%=416

A$="FF FF FF FF 20 " B$="00 00 00 00 C0 " C$="FF FF FF FE 60 " !C%=-416
A$="06:57:55 03-Jun-2248" B$="00:00:01 01-Jan-1900" !C%=-416

A$="00 00 00 00 C0 " B$="FF FF FF FF 20 " C$="00 00 00 01 A0 " !C%=416
A$="00:00:01 01-Jan-1900" B$="06:57:55 03-Jun-2248" !C%=416



-- 
Alan Adams, from Northamptonshire
alan@adamshome.org.uk
http://www.nckc.org.uk/

[toc] | [prev] | [next] | [standalone]

#5994

Alan Adams wrote:
> Steve Drain wrote:
>> For interest's sake I put together a couple of routines to deal solely
>> with 5-byte times using assembly at:
> 
>>   http://www.kappa.me.uk/Miscellaneous/swTimeDiff.zip
> 
>> I am not sure that I have got it right, so please pull it apart. ;-)
> 
> I ran 10 sets of test data. I think it gets it wrong for the last 4. In
> each case the sign is wrong for the returned integer. The values are too
> small as well. These are the cases where the result is too large for an
> integer to hold.

I can see that, and was right to be sceptical of my own code.
> The 5-byte integer values looks correct, but cannot be returned to BASIC.

Yes, the subtraction is fine, but does not produce the desired result.

If the BASIC version is fine, I think I will leave it there.

[toc] | [prev] | [next] | [standalone]

#6000

Steve Drain wrote:
> If the BASIC version is fine, I think I will leave it there.

Last words. Adapting a technique I used to implement 'magic numbers' for 
assembler division by a constant I have come up with:

  DEFFNdiff(a%,b%)
   LOCAL a,b,c:c=2^32
   IF !a%<0 THEN a=c-(NOT!a%+1) ELSE a=!a%
   IF !b%<0 THEN b=c-(NOT!b%+1) ELSE b=!b%
  =(a%!4-b%!4)*c+a-b

The returned value is a signed float and if assigned to an integer it 
will give a 'Number to big' error if out of the range you want. I think 
it is exact within that range.

I will be interested to know where the bugs are. ;-)

[toc] | [prev] | [next] | [standalone]

#6001

In message <r33gnb$1q0r$1@gioia.aioe.org>
          Steve Drain <steve@kappa.me.uk> wrote:

> Steve Drain wrote:
>> If the BASIC version is fine, I think I will leave it there.

> Last words. Adapting a technique I used to implement 'magic numbers' for
> assembler division by a constant I have come up with:

>   DEFFNdiff(a%,b%)
>    LOCAL a,b,c:c=2^32
>    IF !a%<0 THEN a=c-(NOT!a%+1) ELSE a=!a%
>    IF !b%<0 THEN b=c-(NOT!b%+1) ELSE b=!b%
>   =(a%!4-b%!4)*c+a-b

That's so terse it makes my eyes water.

I don't think I will try to understand it.

Alan

> The returned value is a signed float and if assigned to an integer it
> will give a 'Number to big' error if out of the range you want. I think
> it is exact within that range.

> I will be interested to know where the bugs are. ;-)


-- 
Alan Adams, from Northamptonshire
alan@adamshome.org.uk
http://www.nckc.org.uk/

[toc] | [prev] | [next] | [standalone]

#6002

Alan Adams wrote:
> That's so terse it makes my eyes water.
> I don't think I will try to understand it.

The original problem could be solved if BASIC would do arithmetic with
unsigned integers. A 5-byte float can hold an unsigned integer exactly,
but we have to get those integers into floats. I think the method I
posted earlier is actually over-thought and more elaborate than it needs
to be. Please let me know if this works for you:

    DEFFNdiff(a%,b%)
     LOCAL a,b,c:c=2^32
     IF !a%<0 THEN a=c+!a% ELSE a=!a%
     IF !b%<0 THEN b=c+!b% ELSE b=!b%
    =(a%!4-b%!4)*c+a-b

This, some other ramblings, and an extension of the assembler routine
that Martin posted, which will return negative values, are at:

  http://www.kappa.me.uk/Miscellaneous/swTimeDiff.zip

I think the assembler routine is the most useful, but the BASIC one is
quite satisfying. ;-)

[toc] | [prev] | [next] | [standalone]

#6003

Ooops!

 =(a%?4-b%?4)*c+a-b

[toc] | [prev] | [next] | [standalone]

#6004

In message <r38t89$nvf$1@gioia.aioe.org>
          Steve Drain <steve@kappa.me.uk> wrote:

> Alan Adams wrote:
>> That's so terse it makes my eyes water.
>> I don't think I will try to understand it.

> The original problem could be solved if BASIC would do arithmetic with
> unsigned integers. A 5-byte float can hold an unsigned integer exactly,
> but we have to get those integers into floats. I think the method I
> posted earlier is actually over-thought and more elaborate than it needs
> to be. Please let me know if this works for you:

With your followup correction, yes it works well.

>     DEFFNdiff(a%,b%)
>      LOCAL a,b,c:c=2^32
>      IF !a%<0 THEN a=c+!a% ELSE a=!a%
>      IF !b%<0 THEN b=c+!b% ELSE b=!b%
>     =(a%!4-b%!4)*c+a-b

> This, some other ramblings, and an extension of the assembler routine
> that Martin posted, which will return negative values, are at:

>   http://www.kappa.me.uk/Miscellaneous/swTimeDiff.zip

> I think the assembler routine is the most useful, but the BASIC one is
> quite satisfying. ;-)


-- 
Alan Adams, from Northamptonshire
alan@adamshome.org.uk
http://www.nckc.org.uk/

[toc] | [prev] | [next] | [standalone]

#6065

Sorry that I'm late to the party here. In order to calculate the elapsed time you can just subtract the lower 4 bytes.

So if Start% is the lower four bytes of the start time & Finish% is the lower four bytes of the finish time:

TimeTaken% = Finish% - Start%

This "Just works" and will always produce the correct result even with rollovers.

If TimeTaken% < 0 then the finish was before the start.

Jeff

[toc] | [prev] | [next] | [standalone]

#6066

On 22 Apr in article
<69d8792f-18c1-4a2c-8e14-0a7e0fd698c7@googlegroups.com>,
   <jeffrey.a.doggett@gmail.com> wrote:
> Sorry that I'm late to the party here. In order to calculate the
> elapsed time you can just subtract the lower 4 bytes.

> So if Start% is the lower four bytes of the start time & Finish% is
> the lower four bytes of the finish time:

> TimeTaken% = Finish% - Start%

> This "Just works" and will always produce the correct result even
> with rollovers.

> If TimeTaken% < 0 then the finish was before the start.

I don't think this works if the time difference is over 35 weeks....

-- 
Martin Avison 
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received. 

[toc] | [prev] | [next] | [standalone]

#6069

On Thursday, 23 April 2020 00:09:59 UTC+1, Martin  wrote:
> On 22 Apr in article
> <69d8792f-18c1-4a2c-8e14-0a7e0fd698c7@googlegroups.com>,
>    <jeffrey.a.doggett@gmail.com> wrote:
> > Sorry that I'm late to the party here. In order to calculate the
> > elapsed time you can just subtract the lower 4 bytes.
> 
> > So if Start% is the lower four bytes of the start time & Finish% is
> > the lower four bytes of the finish time:
> 
> > TimeTaken% = Finish% - Start%
> 
> > This "Just works" and will always produce the correct result even
> > with rollovers.
> 
> > If TimeTaken% < 0 then the finish was before the start.
> 
> I don't think this works if the time difference is over 35 weeks....
> 
> -- 
> Martin Avison 
> Note that unfortunately this email address will become invalid
> without notice if (when) any spam is received.

No, but Alan is timing a canoeist down a slalom course.  If it takes 35 weeks then there's something amiss.

[toc] | [prev] | [next] | [standalone]

#6074

On 23 Apr in article
<dccbb754-a167-43b8-ad2f-f6d82fbbd68b@googlegroups.com>,
   <jeffrey.a.doggett@gmail.com> wrote:
> On Thursday, 23 April 2020 00:09:59 UTC+1, Martin  wrote:
> > On 22 Apr in article
> > <69d8792f-18c1-4a2c-8e14-0a7e0fd698c7@googlegroups.com>,
> >    <jeffrey.a.doggett@gmail.com> wrote:
> > > Sorry that I'm late to the party here. In order to calculate the
> > > elapsed time you can just subtract the lower 4 bytes.
> > 
> > > So if Start% is the lower four bytes of the start time &
> > > Finish% is the lower four bytes of the finish time:
> > 
> > > TimeTaken% = Finish% - Start%
> > 
> > > This "Just works" and will always produce the correct result
> > > even with rollovers.
> > 
> > > If TimeTaken% < 0 then the finish was before the start.
> > 
> > I don't think this works if the time difference is over 35
> > weeks....

> No, but Alan is timing a canoeist down a slalom course.  If it
> takes 35 weeks then there's something amiss.

Indeed. But what happens when the 5-byte hex times are...
    start time =  58 00 00 04 00
    end time   =  57 00 00 05 00
gives x100 ... when it should be flagged as negative and duff!

-- 
Martin Avison 
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received. 

[toc] | [prev] | [next] | [standalone]

#6075

In article <5865cc4b9aNews03@avisoft.f9.co.uk>,
   Martin <News03@avisoft.f9.co.uk> wrote:

> Indeed. But what happens when the 5-byte hex times are...
>     start time =  58 00 00 04 00
>     end time   =  57 00 00 05 00
> gives x100 ... when it should be flagged as negative and duff!

I've already added a note in my programming library, but can we have a
definitive answer on this, please!

An agreed one that I can save as a note!

John

-- 
John WILLIAMS, now back in the UK - no attachments to these addresses!
Non-RISC OS posters change user to johnrwilliams or put 'risc' in subject!
Who is John WILLIAMS? http://petit.four.free.fr/picindex/author/

[toc] | [prev] | [next] | [standalone]

#6076

> Indeed. But what happens when the 5-byte hex times are...
>     start time =  58 00 00 04 00
>     end time   =  57 00 00 05 00
> gives x100 ... when it should be flagged as negative and duff!

That would require the judge on the finish line to press his button 35 weeks before the starter presses his button. Cannot happen.

[toc] | [prev] | [next] | [standalone]

#6079

On 23 Apr in article
<6667d647-6873-488d-8a39-ed15086e185a@googlegroups.com>,
   <jeffrey.a.doggett@gmail.com> wrote:
> > Indeed. But what happens when the 5-byte hex times are...
> >     start time =  58 00 00 04 00
> >     end time   =  57 00 00 05 00
> > gives x100 ... when it should be flagged as negative and duff!

> That would require the judge on the finish line to press his button 
> 35 weeks before the starter presses his button. Cannot happen.

Unfortunately the OP in his first post said...
> I need to reliably detect negative results, which can occur if a
> spurious finish time pulse arrives before a start time.

-- 
Martin Avison 
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received. 

[toc] | [prev] | [next] | [standalone]

#6080

In message <5865ded017News03@avisoft.f9.co.uk>
          Martin <News03@avisoft.f9.co.uk> wrote:

> On 23 Apr in article
> <6667d647-6873-488d-8a39-ed15086e185a@googlegroups.com>,
>   <jeffrey.a.doggett@gmail.com> wrote:
> > > Indeed. But what happens when the 5-byte hex times are...
> > >     start time =  58 00 00 04 00
> > >     end time   =  57 00 00 05 00 gives x100 ... when it should be
> > > flagged as negative and duff!
> 
> > That would require the judge on the finish line to press his button  35
> > weeks before the starter presses his button. Cannot happen.
> 
> Unfortunately the OP in his first post said...
> > I need to reliably detect negative results, which can occur if a spurious
> > finish time pulse arrives before a start time.

Still OK; it won't go wrong unless the spurious pulse arrives between
(roughly) 17 weeks and 35 weeks before the start time.

David

[toc] | [prev] | [next] | [standalone]

#6078

In message <5865cc4b9aNews03@avisoft.f9.co.uk>
          Martin <News03@avisoft.f9.co.uk> wrote:

> On 23 Apr in article
> <dccbb754-a167-43b8-ad2f-f6d82fbbd68b@googlegroups.com>,
>   <jeffrey.a.doggett@gmail.com> wrote:
> > On Thursday, 23 April 2020 00:09:59 UTC+1, Martin  wrote:
> > > On 22 Apr in article
> > > <69d8792f-18c1-4a2c-8e14-0a7e0fd698c7@googlegroups.com>,
> > >    <jeffrey.a.doggett@gmail.com> wrote:
> > > > Sorry that I'm late to the party here. In order to calculate the
> > > > elapsed time you can just subtract the lower 4 bytes.
> > > 
> > > > So if Start% is the lower four bytes of the start time & Finish% is
> > > > the lower four bytes of the finish time:
> > > 
> > > > TimeTaken% = Finish% - Start%
> > > 
> > > > This "Just works" and will always produce the correct result even
> > > > with rollovers.
> > > 
> > > > If TimeTaken% < 0 then the finish was before the start.
> > > 
> > > I don't think this works if the time difference is over 35 weeks....
> 
> > No, but Alan is timing a canoeist down a slalom course.  If it takes 35
> > weeks then there's something amiss.
> 
> Indeed. But what happens when the 5-byte hex times are...
>    start time =  58 00 00 04 00
>    end time   =  57 00 00 05 00 gives x100 ... when it should be flagged as
> negative and duff!

As has already been pointed out, the answers are all correct within a
certain range of times, something like 35 weeks, which is orders of
magnitude greater than can happen in this use case.

It's not a general solution, but it is entirely correct and appropriate
for what the OP's needs.

David

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.sys.acorn.programmer

csiph-web