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

Groups > comp.sys.acorn.programmer > #5986

Re: Subtracting times

Show all headers | View raw

In message <r2jboh$ap3$1@solani.org>
          Sebastian Barthel <naitsabes@freenet.de> wrote:

> Am Wed, 19 Feb 2020 10:03:26 +0000 schrieb Alan Adams:

>> In message <757ca84458.Matthew@sinenomine.freeserve.co.uk>
>>           Matthew Phillips <spam2011m@yahoo.co.uk> wrote:
>> 
>>> In message <37f8364458.Alan.Adams@ArmX6.adamshome.org.uk>
>>>  on 18 Feb 2020 Alan Adams  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.

>>> But that's only if you're sure the result fits in 4 bytes.
>> 
>> If anyone takes a year and a half to paddle round a slalom course, we
>> can time them with a calendar.
>> 
>>>>   resultbuf%?I%=L%AND&FF
>>>> ENDPROC
>> 
>>> If you wnat a signed result, you can simplify by making the FOR-NEXT
>>> loop with I% run from 0 to 4 and lose all the lines after the NEXT.
>> 
>> The following shows why this makes my head hurt.
>> 
>> adding two positive numbers shouldn't produce a negative result.
>> 
>>>A%=&7FFFFFFF PRINT A%
>> 2.14748365E9
>>>B%=A%+1 PRINT B%
>> -2.14748365E9


> But: that's no problem at all since You are NOT doing some kind of
> integer mathematics here. You are trying to change the bytes as they are
> stored in memory.

> The example with B%=A%+1 results in a "higher" value in memory - but the
> BASIC interprets it as a signed value, and therefore it changes to
> negative value if the top-most bit has been set.
> This only means that You can't print this values directly via PRINT -
> there is always the need to use an output-procedure if a "time" value is
> intended.

The inconsistency is that BASIC shows a number as signed, but treats it in 
addition as unsigned. To be consistent it should signal an overflow in the 
example above.


> If You really know that the times measured never (!) execeed the 4 Bytes
> then I dont know why anyone should deal with the highest (the 5th) Byte.
> If these time stamp%s are taken as start and stop times then they are
> ordered since You already know wich is the higher/later one.

I don't know which, that's where the problem lies.

Suppose the finisher knocks his button. Then the starter starts someone. 
We now have a finish timestamp which is before a start timestamp. To 
detect this I need to get the difference returned as a negative number.

The 5th byte becomes important in Februiary 2021. Currently it has the 
value &57. Next Feb it moves to &58. I need to ensure that a start with 
byte5 as 57 and a finish with a byte5 of 58 doesn't result in a negative 
number, nor a ridiculously large one. While it would potentially only 
affect a small number of runs, it could also result in a crash somewhere 
in the system when presented with invalid data.

> One thing - and thats the first I wanted to mention - more:
> If this is on a 32 Bit Machine (as an Archimedes or RPC or Pi) then there
> are only 4 Bytes per integer variable% !
> If You use a construct such as stamp1%?I% with I%=4 there will be a result
> - but probably not the one, wich gives the correct value for the 5th
> Byte. I think this should give You the least significant Byte of the next
> 32Bit variable wich is stored in memory directly after (behind) the
> stamp1% . This means: stamp1%?4 doesn't give the 5th Byte of stamp1% as
> intendend, but will result in Byte 1 of stamp2% ( hence the same as
> stamp2%?0 ).

I'm not using the 5th byte as part of the answer. I'm using the 
calculation of the 5th byte to determine whether to negate the result that 
I do use, i.e. bytes 1 to 4. There's no reason in fact to store it after 
calculating it - that's left over from some testing situations.




> All the best,
> SBn


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

Back to comp.sys.acorn.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web