Counter math
Archiver
Posts: 46,084
Hi, friends
I am building a counter (regressive and progressive) which has also 'average
of operations per hour' and 'time to end' functions. Not too complicated. I
am using 16 bit math and only integer (no floating point) operations.
BUT
the problem is my 'time to end' feature. I do it by multiplying the
operations left to be done (regressive counter) by the average number of
seconds I am taking on each operation. This average is calculated by the
formula:
avg10=(secs/prog)*10)+(((secs//prog)*10)/prog)
Prog is the progressive counter, or how many operations were already done in
how many secs.
By using this I have the average multiplyed by 10, what is good because if
the average is 7.5, or 22.3 seconds, I will have 75 or 223 and will not
loose the decimal.
So, the time to end, in seconds, is:
timetoend=(reg/10)*avg10
I expect reg (regressive counter) to be at most 65535, and avg10 to be at
most 300 (30 secs avg), but of course they can't be at their mosts
simultaneously, or the result will be way over 65535.
BUT the most likely average is around 20s (avg10=200) which will give me a
max number of operations left = 3270 (too low !).
So, the question is: what can I do to improve this solution ?
The only thing I have imagined so far is to use timetoend=(reg/100)*avg10
for reg greater than 3270 (knowing I will have secs/10 as a result) but I
loose too much resolution, and the problem still persists for reg greater
than 32700.
Am I getting lost here ? Any ideas ?
Original Message
From: "Tracy Allen" <tracy@e...>
To: <basicstamps@yahoogroups.com>
Sent: Wednesday, December 17, 2003 1:16 PM
Subject: RE: [noparse][[/noparse]basicstamps] Re: How to send and receive Long hex string
(serial communication)
> ZY,
>
> Here is a more specific and tested routine that sends 2400 baud, 8
> bits, even parity. The message Jon referred to was an earlier one
> that had a general approach, not a specific solution.
>
> send2400:
> wx=mybyte
> FOR i=0 TO 7
> wx.bit8= wx0(i) ^ wx.bit8 ' calculate even parity
> NEXT
> wx = wx << 1 | 1 ' append start bit on right
> wx=wx ^ %11011011011 ' pre-compensate for inversions to follow
> OUT2= ~~~wx0(0) ' start bit
> OUT2= ~~~wx0(1) ' data bit 0
> OUT2= ~~~~wx0(2) ' the ~~~~ or ~~~ pad the time per bit
> OUT2= ~~~wx0(3) ' they just eat up a little time
> OUT2= ~~~wx0(4) ' to make it 417uS per bit average
> OUT2= ~~~~wx0(5) ' and spread the difference over the 8 bits.
> OUT2= ~~~wx0(6)
> OUT2= ~~~wx0(7)
> OUT2= ~~~~wx0(8) ' data bit 7
> OUT2= ~~~wx0(9) ' even parity
> OUT2= ~~~wx0(10) ' stop bit
> RETURN
>
> However, I see now in the subject line, your question is not only
> "send" but "receive". I don't think the BS2 can do that because
> there is simply not enough time to sync with a start bit. I think
> the BS2p or 'pe might be able to do it, with help of the POLLWAIT 8
> command. But the original BS2 does not have that command.
> Otherwise, external hardware (MAX3110) will be needed with the Stamp.
> The MAX3100 is a UART chip, and additional links and info can be
> found here.. <http://www.emesys.com/BS2IrDA.htm>.
>
> >As was pointed out [noparse][[/noparse]because I missed it in your original post], the
> >BASIC Stamp doesn't do eight bits and even parity. Dr. Tracy Allen
> >wrote a "bit-bang" rouitine that may help you. Here's a copy from
> >Tracy's original post on the subject:
> >
> >Each bit at 2400 baud is 417 microseconds. You might be able to send
> >each byte with a subroutine such as the following. You have to enter
> >the subroutine with the word variable serword already loaded with the
> >11 bits that need to be transmitted, including the start bit, 8 data
> >bits, parity bit (your program has to calculate parity), and the stop
> >bit.
> >
> >' word variable serit contains the assembled 11 bits
> >' right justified
> >' adjust the variable "padding" to get correct timing
> >' p1 is a dummy pulse that appears, just for timing.
> >' the out command takes about 220 microseconds,
> >' the pulsout takes another 220 microseconds, plus
> >' the length of the dummy pulse.
> >
> >Send_2400:
> > output 0
> > out0=serword.bit10 ' start bit
> > pulsout 1,padding
> > out0=serword.bit9
> > pulsout 1,padding
> > out0=serword.bit8
> > pulsout 1,padding
> > out0=serword.bit7
> > pulsout 1,padding
> > out0=serword.bit6
> > pulsout 1,padding
> > out0=serword.bit5
> > pulsout 1,padding
> > out0=serword.bit4
> > pulsout 1,padding
> > out0=serword.bit3
> > pulsout 1,padding
> > out0=serword.bit2
> > pulsout 1,padding
> > out0=serword.bit1
> > pulsout 1,padding
> > out0=serword.bit0 ' stop bit
> > RETURN
> >
> >A FOR-NEXT loop probably would not work, because the FOR-NEXT logic
> >takes about 800 microseconds.
> >
> >
> >
> >-- Jon Williams
> >-- Applications Engineer, Parallax
> >-- Dallas Office
> >
> >
> >
> >
> >
> >
> >
Original Message
> >From: zy93@h... [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=mTAR5uHUsFMBwsKdkTTHIkZ7m5_Yu5x3kRc8N4KQMMVS4LjKvC24YZTynMamiZB_xdE4fCrj2WJ6vCU]zy93@h...[/url
> >Sent: Wednesday, December 17, 2003 8:20 AM
> >To: basicstamps@yahoogroups.com
> >Subject: [noparse][[/noparse]basicstamps] Re: How to send and receive Long hex string
> >(serial communication)
> >
> >
> >Hello:
> >
> >I use PC to communicate with the control unit before by using VB. The
> >string like 020E011001000000000000047C0CCDA5. It works very well. But
> >now I am trying to use BS2 replace the PC. So I think the code should
> >be the same as before in order to communicate with the control
> >unit.The communication protocol requires: 8 databit, 1 stopbit, 2400,
> >even.
> >What code and baudmode here should be for BS2??
> >
> >Thanks, ZY
>
> To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
> from the same email address that you subscribed. Text in the Subject and
Body of the message will be ignored.
>
>
> Yahoo! Groups Links
>
> To visit your group on the web, go to:
> http://groups.yahoo.com/group/basicstamps/
>
> To unsubscribe from this group, send an email to:
> basicstamps-unsubscribe@yahoogroups.com
>
> Your use of Yahoo! Groups is subject to:
> http://docs.yahoo.com/info/terms/
>
>
>
I am building a counter (regressive and progressive) which has also 'average
of operations per hour' and 'time to end' functions. Not too complicated. I
am using 16 bit math and only integer (no floating point) operations.
BUT
the problem is my 'time to end' feature. I do it by multiplying the
operations left to be done (regressive counter) by the average number of
seconds I am taking on each operation. This average is calculated by the
formula:
avg10=(secs/prog)*10)+(((secs//prog)*10)/prog)
Prog is the progressive counter, or how many operations were already done in
how many secs.
By using this I have the average multiplyed by 10, what is good because if
the average is 7.5, or 22.3 seconds, I will have 75 or 223 and will not
loose the decimal.
So, the time to end, in seconds, is:
timetoend=(reg/10)*avg10
I expect reg (regressive counter) to be at most 65535, and avg10 to be at
most 300 (30 secs avg), but of course they can't be at their mosts
simultaneously, or the result will be way over 65535.
BUT the most likely average is around 20s (avg10=200) which will give me a
max number of operations left = 3270 (too low !).
So, the question is: what can I do to improve this solution ?
The only thing I have imagined so far is to use timetoend=(reg/100)*avg10
for reg greater than 3270 (knowing I will have secs/10 as a result) but I
loose too much resolution, and the problem still persists for reg greater
than 32700.
Am I getting lost here ? Any ideas ?
Original Message
From: "Tracy Allen" <tracy@e...>
To: <basicstamps@yahoogroups.com>
Sent: Wednesday, December 17, 2003 1:16 PM
Subject: RE: [noparse][[/noparse]basicstamps] Re: How to send and receive Long hex string
(serial communication)
> ZY,
>
> Here is a more specific and tested routine that sends 2400 baud, 8
> bits, even parity. The message Jon referred to was an earlier one
> that had a general approach, not a specific solution.
>
> send2400:
> wx=mybyte
> FOR i=0 TO 7
> wx.bit8= wx0(i) ^ wx.bit8 ' calculate even parity
> NEXT
> wx = wx << 1 | 1 ' append start bit on right
> wx=wx ^ %11011011011 ' pre-compensate for inversions to follow
> OUT2= ~~~wx0(0) ' start bit
> OUT2= ~~~wx0(1) ' data bit 0
> OUT2= ~~~~wx0(2) ' the ~~~~ or ~~~ pad the time per bit
> OUT2= ~~~wx0(3) ' they just eat up a little time
> OUT2= ~~~wx0(4) ' to make it 417uS per bit average
> OUT2= ~~~~wx0(5) ' and spread the difference over the 8 bits.
> OUT2= ~~~wx0(6)
> OUT2= ~~~wx0(7)
> OUT2= ~~~~wx0(8) ' data bit 7
> OUT2= ~~~wx0(9) ' even parity
> OUT2= ~~~wx0(10) ' stop bit
> RETURN
>
> However, I see now in the subject line, your question is not only
> "send" but "receive". I don't think the BS2 can do that because
> there is simply not enough time to sync with a start bit. I think
> the BS2p or 'pe might be able to do it, with help of the POLLWAIT 8
> command. But the original BS2 does not have that command.
> Otherwise, external hardware (MAX3110) will be needed with the Stamp.
> The MAX3100 is a UART chip, and additional links and info can be
> found here.. <http://www.emesys.com/BS2IrDA.htm>.
>
> >As was pointed out [noparse][[/noparse]because I missed it in your original post], the
> >BASIC Stamp doesn't do eight bits and even parity. Dr. Tracy Allen
> >wrote a "bit-bang" rouitine that may help you. Here's a copy from
> >Tracy's original post on the subject:
> >
> >Each bit at 2400 baud is 417 microseconds. You might be able to send
> >each byte with a subroutine such as the following. You have to enter
> >the subroutine with the word variable serword already loaded with the
> >11 bits that need to be transmitted, including the start bit, 8 data
> >bits, parity bit (your program has to calculate parity), and the stop
> >bit.
> >
> >' word variable serit contains the assembled 11 bits
> >' right justified
> >' adjust the variable "padding" to get correct timing
> >' p1 is a dummy pulse that appears, just for timing.
> >' the out command takes about 220 microseconds,
> >' the pulsout takes another 220 microseconds, plus
> >' the length of the dummy pulse.
> >
> >Send_2400:
> > output 0
> > out0=serword.bit10 ' start bit
> > pulsout 1,padding
> > out0=serword.bit9
> > pulsout 1,padding
> > out0=serword.bit8
> > pulsout 1,padding
> > out0=serword.bit7
> > pulsout 1,padding
> > out0=serword.bit6
> > pulsout 1,padding
> > out0=serword.bit5
> > pulsout 1,padding
> > out0=serword.bit4
> > pulsout 1,padding
> > out0=serword.bit3
> > pulsout 1,padding
> > out0=serword.bit2
> > pulsout 1,padding
> > out0=serword.bit1
> > pulsout 1,padding
> > out0=serword.bit0 ' stop bit
> > RETURN
> >
> >A FOR-NEXT loop probably would not work, because the FOR-NEXT logic
> >takes about 800 microseconds.
> >
> >
> >
> >-- Jon Williams
> >-- Applications Engineer, Parallax
> >-- Dallas Office
> >
> >
> >
> >
> >
> >
> >
Original Message
> >From: zy93@h... [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=mTAR5uHUsFMBwsKdkTTHIkZ7m5_Yu5x3kRc8N4KQMMVS4LjKvC24YZTynMamiZB_xdE4fCrj2WJ6vCU]zy93@h...[/url
> >Sent: Wednesday, December 17, 2003 8:20 AM
> >To: basicstamps@yahoogroups.com
> >Subject: [noparse][[/noparse]basicstamps] Re: How to send and receive Long hex string
> >(serial communication)
> >
> >
> >Hello:
> >
> >I use PC to communicate with the control unit before by using VB. The
> >string like 020E011001000000000000047C0CCDA5. It works very well. But
> >now I am trying to use BS2 replace the PC. So I think the code should
> >be the same as before in order to communicate with the control
> >unit.The communication protocol requires: 8 databit, 1 stopbit, 2400,
> >even.
> >What code and baudmode here should be for BS2??
> >
> >Thanks, ZY
>
> To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
> from the same email address that you subscribed. Text in the Subject and
Body of the message will be ignored.
>
>
> Yahoo! Groups Links
>
> To visit your group on the web, go to:
> http://groups.yahoo.com/group/basicstamps/
>
> To unsubscribe from this group, send an email to:
> basicstamps-unsubscribe@yahoogroups.com
>
> Your use of Yahoo! Groups is subject to:
> http://docs.yahoo.com/info/terms/
>
>
>
Comments
That is a tough problem. If you have 65535 operations and each one
takes 20 seconds, that adds up to 196605 seconds. (over 24 days!)
Is your progressive seconds counter really going to roll over to
double precision? Even at much less than that, the calculation for
avg10 as written is a problem. The minmax limit on the avg10
calculation is prog<6554 operations and secs<65536 seconds.
Isn't it enough to estimate within a minute when there is a lot of
time left to go, and then switch over to seconds when it is less than
a day left? That should be easier.
-- Tracy
>Hi, friends
>
>I am building a counter (regressive and progressive) which has also 'average
>of operations per hour' and 'time to end' functions. Not too complicated. I
>am using 16 bit math and only integer (no floating point) operations.
>
>BUT
>
>the problem is my 'time to end' feature. I do it by multiplying the
>operations left to be done (regressive counter) by the average number of
>seconds I am taking on each operation. This average is calculated by the
>formula:
>
>avg10=(secs/prog)*10)+(((secs//prog)*10)/prog)
>
>Prog is the progressive counter, or how many operations were already done in
>how many secs.
>
>By using this I have the average multiplyed by 10, what is good because if
>the average is 7.5, or 22.3 seconds, I will have 75 or 223 and will not
>loose the decimal.
>
>So, the time to end, in seconds, is:
>
>timetoend=(reg/10)*avg10
>
>I expect reg (regressive counter) to be at most 65535, and avg10 to be at
>most 300 (30 secs avg), but of course they can't be at their mosts
>simultaneously, or the result will be way over 65535.
>
>BUT the most likely average is around 20s (avg10=200) which will give me a
>max number of operations left = 3270 (too low !).
>
>So, the question is: what can I do to improve this solution ?
>
>The only thing I have imagined so far is to use timetoend=(reg/100)*avg10
>for reg greater than 3270 (knowing I will have secs/10 as a result) but I
>loose too much resolution, and the problem still persists for reg greater
>than 32700.
>
>Am I getting lost here ? Any ideas ?
> The minmax limit on the avg10
> calculation is prog<6554 operations and secs<65536 seconds.
I agree with the maximum 65536 seconds, but I don't understand the maximum
of 6554 operations.
> Isn't it enough to estimate within a minute when there is a lot of
> time left to go, and then switch over to seconds when it is less than
> a day left? That should be easier.
I would be happy with minutes only in both cases. But how to do this, since
I calculate seconds per operation on my avg10 ? If I turn it to operations
per minute, I guess I would lose too much precision, right ? Maybe
operations per 10 minutes ?
Thanks,
Pedro
>
> >Hi, friends
> >
> >I am building a counter (regressive and progressive) which has also
'average
> >of operations per hour' and 'time to end' functions. Not too complicated.
I
> >am using 16 bit math and only integer (no floating point) operations.
> >
> >BUT
> >
> >the problem is my 'time to end' feature. I do it by multiplying the
> >operations left to be done (regressive counter) by the average number of
> >seconds I am taking on each operation. This average is calculated by the
> >formula:
> >
> >avg10=(secs/prog)*10)+(((secs//prog)*10)/prog)
> >
> >Prog is the progressive counter, or how many operations were already done
in
> >how many secs.
> >
> >By using this I have the average multiplyed by 10, what is good because
if
> >the average is 7.5, or 22.3 seconds, I will have 75 or 223 and will not
> >loose the decimal.
> >
> >So, the time to end, in seconds, is:
> >
> >timetoend=(reg/10)*avg10
> >
> >I expect reg (regressive counter) to be at most 65535, and avg10 to be at
> >most 300 (30 secs avg), but of course they can't be at their mosts
> >simultaneously, or the result will be way over 65535.
> >
> >BUT the most likely average is around 20s (avg10=200) which will give me
a
> >max number of operations left = 3270 (too low !).
> >
> >So, the question is: what can I do to improve this solution ?
> >
> >The only thing I have imagined so far is to use timetoend=(reg/100)*avg10
> >for reg greater than 3270 (knowing I will have secs/10 as a result) but I
> >loose too much resolution, and the problem still persists for reg greater
> >than 32700.
> >
> >Am I getting lost here ? Any ideas ?
>
>> The minmax limit on the avg10
>> calculation is prog<6554 operations and secs<65536 seconds.
>
>I agree with the maximum 65536 seconds, but I don't understand the maximum
>of 6554 operations.
Hi Pedro,
The part of the calculation that deals with the remainder has this:
secs//prog * 10
The problem could come if secs//prog is 6554 or greater, because
6554*10=65540, which is greater than the word size 65535. I say
"could" instead of "certainly" because the remainder of the division
could fall anywhere between 0 and prog, depending on the value of
secs. But it would fail for some values of secs chosen at random,
which is enough to make the calculation unreliable.
>
>> Isn't it enough to estimate within a minute when there is a lot of
>> time left to go, and then switch over to seconds when it is less than
>> a day left? That should be easier.
>
>I would be happy with minutes only in both cases. But how to do this, since
>I calculate seconds per operation on my avg10 ? If I turn it to operations
>per minute, I guess I would lose too much precision, right ? Maybe
>operations per 10 minutes ?
Well, once you have seconds per operation (really tenths of a second
per operation, avg10), that can be converted to minutes by dividing
by 600. No problem: That can be done precisely (within one minute)
as a loop binary division.
'
binary division loop
N=avg10
for J=15 to 0 ' 16 bits
N=N//600<<1 ' remainder*2
result.bit0(J)=N/D ' next bit of result word
next
The result of the loop is the number of minutes per 65536 operations.
The factor 65536 falls naturally out of the algorithm because there
are 16 binary left-shifts. For example, if avg10 happens to be 223
(22.3 seconds per operation) then result will be 24357 minutes per
65536 operations. (multiply it out: 65536 * 22.3 / 60 = 24357).
Now on the Stamp, you can use the ** operator to figure out how many
minutes are left:
mins = reg ** result ' reg is number of operations remaining
If you want to show the number of minutes per operation, with three
decimal places, do
mins100 = 10000 ** result +5/10 ' with rounding
debug cr,".",dec3 mins100,cr
So 22.3 seconds will be displayed as 0.372 minute.
Division by 65536 is implied in the ** operator, used in this way,
and that is naturally the "per 65536" factor. When the number of
minutes remaining get small enough, you could change to an algorithm
that would put the time remaining in fractions of a minute or in
minutes:seconds.
regards,
Tracy
>
>Thanks,
>
>Pedro
>
>
>>
>> >Hi, friends
>> >
>> >I am building a counter (regressive and progressive) which has also
>'average
>> >of operations per hour' and 'time to end' functions. Not too complicated.
>I
>> >am using 16 bit math and only integer (no floating point) operations.
>> >
>> >BUT
>> >
>> >the problem is my 'time to end' feature. I do it by multiplying the
>> >operations left to be done (regressive counter) by the average number of
>> >seconds I am taking on each operation. This average is calculated by the
>> >formula:
>> >
>> >avg10=(secs/prog)*10)+(((secs//prog)*10)/prog)
>> >
>> >Prog is the progressive counter, or how many operations were already done
>in
>> >how many secs.
>> >
>> >By using this I have the average multiplyed by 10, what is good because
>if
>> >the average is 7.5, or 22.3 seconds, I will have 75 or 223 and will not
>> >loose the decimal.
>> >
>> >So, the time to end, in seconds, is:
>> >
>> >timetoend=(reg/10)*avg10
>> >
>> >I expect reg (regressive counter) to be at most 65535, and avg10 to be at
>> >most 300 (30 secs avg), but of course they can't be at their mosts
>> >simultaneously, or the result will be way over 65535.
>> >
>> >BUT the most likely average is around 20s (avg10=200) which will give me
>a
>> >max number of operations left = 3270 (too low !).
>> >
>> >So, the question is: what can I do to improve this solution ?
>> >
>> >The only thing I have imagined so far is to use timetoend=(reg/100)*avg10
> > >for reg greater than 3270 (knowing I will have secs/10 as a result) but I
>> >loose too much resolution, and the problem still persists for reg greater
>> >than 32700.
>> >
>> >Am I getting lost here ? Any ideas ?
>
>
>
>
>To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
>from the same email address that you subscribed. Text in the
>Subject and Body of the message will be ignored.
>
>
>Yahoo! Groups Links
>
>To visit your group on the web, go to:
> http://groups.yahoo.com/group/basicstamps/
>
>To unsubscribe from this group, send an email to:
> basicstamps-unsubscribe@yahoogroups.com
>
>Your use of Yahoo! Groups is subject to:
> http://docs.yahoo.com/info/terms/
I can't use it the way you suggested, though, because:
1. I think "operations per minute" (the opposite) are more what I need,
since the average of operations will not exceed 20-something seconds.
2. After prototyping with the Stamp, now I am doing this in assembly, what
complicates a bit.
Your warning about problems after 6554 operations scared me, and I didn't
see it coming.
This seconds approach for the avg10 seems no good. What I like about it is
that it keeps the average with full time and full counting, throughout the
whole work. Better than measuring single-operation times and averaging the
last n operations.
I understand the challenge here is to keep track of the average and preview
how many minutes to the end, all this not letting any calculations exceed
65535.
I was thinking maybe adapting that formula to
((prog/min)*10)+(((prog//min)*10)/min). Prog (number of operations) must be
less than 65535, and min is limited to 6554, as you pointed out. This is 109
hours, which is more than ok.
This will give me operations per 10-minute time. Feasible averages are from
20 to 80. But it will be of no help, since when I multiply it by 6500 (ie,
reg/10)...
Maybe there is a way to separate hours left and minutes left...
What do you suggest ?
Again, thanks a lot for your help.
Regards,
Pedro
Original Message
From: "Tracy Allen" <tracy@e...>
To: <basicstamps@yahoogroups.com>
Sent: Wednesday, December 17, 2003 6:58 PM
Subject: Re: [noparse][[/noparse]basicstamps] Counter math
> >Hi, Tracy
> >
> >> The minmax limit on the avg10
> >> calculation is prog<6554 operations and secs<65536 seconds.
> >
> >I agree with the maximum 65536 seconds, but I don't understand the
maximum
> >of 6554 operations.
>
> Hi Pedro,
>
> The part of the calculation that deals with the remainder has this:
> secs//prog * 10
> The problem could come if secs//prog is 6554 or greater, because
> 6554*10=65540, which is greater than the word size 65535. I say
> "could" instead of "certainly" because the remainder of the division
> could fall anywhere between 0 and prog, depending on the value of
> secs. But it would fail for some values of secs chosen at random,
> which is enough to make the calculation unreliable.
>
>
>
> >
> >> Isn't it enough to estimate within a minute when there is a lot of
> >> time left to go, and then switch over to seconds when it is less than
> >> a day left? That should be easier.
> >
> >I would be happy with minutes only in both cases. But how to do this,
since
> >I calculate seconds per operation on my avg10 ? If I turn it to
operations
> >per minute, I guess I would lose too much precision, right ? Maybe
> >operations per 10 minutes ?
>
> Well, once you have seconds per operation (really tenths of a second
> per operation, avg10), that can be converted to minutes by dividing
> by 600. No problem: That can be done precisely (within one minute)
> as a loop binary division.
>
> '
binary division loop
> N=avg10
> for J=15 to 0 ' 16 bits
> N=N//600<<1 ' remainder*2
> result.bit0(J)=N/D ' next bit of result word
> next
>
> The result of the loop is the number of minutes per 65536 operations.
> The factor 65536 falls naturally out of the algorithm because there
> are 16 binary left-shifts. For example, if avg10 happens to be 223
> (22.3 seconds per operation) then result will be 24357 minutes per
> 65536 operations. (multiply it out: 65536 * 22.3 / 60 = 24357).
> Now on the Stamp, you can use the ** operator to figure out how many
> minutes are left:
> mins = reg ** result ' reg is number of operations remaining
> If you want to show the number of minutes per operation, with three
> decimal places, do
> mins100 = 10000 ** result +5/10 ' with rounding
> debug cr,".",dec3 mins100,cr
> So 22.3 seconds will be displayed as 0.372 minute.
>
> Division by 65536 is implied in the ** operator, used in this way,
> and that is naturally the "per 65536" factor. When the number of
> minutes remaining get small enough, you could change to an algorithm
> that would put the time remaining in fractions of a minute or in
> minutes:seconds.
>
> regards,
> Tracy
>
>
> >
> >Thanks,
> >
> >Pedro
> >
> >
> >>
> >> >Hi, friends
> >> >
> >> >I am building a counter (regressive and progressive) which has also
> >'average
> >> >of operations per hour' and 'time to end' functions. Not too
complicated.
> >I
> >> >am using 16 bit math and only integer (no floating point) operations.
> >> >
> >> >BUT
> >> >
> >> >the problem is my 'time to end' feature. I do it by multiplying the
> >> >operations left to be done (regressive counter) by the average number
of
> >> >seconds I am taking on each operation. This average is calculated by
the
> >> >formula:
> >> >
> >> >avg10=(secs/prog)*10)+(((secs//prog)*10)/prog)
> >> >
> >> >Prog is the progressive counter, or how many operations were already
done
> >in
> >> >how many secs.
> >> >
> >> >By using this I have the average multiplyed by 10, what is good
because
> >if
> >> >the average is 7.5, or 22.3 seconds, I will have 75 or 223 and will
not
> >> >loose the decimal.
> >> >
> >> >So, the time to end, in seconds, is:
> >> >
> >> >timetoend=(reg/10)*avg10
> >> >
> >> >I expect reg (regressive counter) to be at most 65535, and avg10 to be
at
> >> >most 300 (30 secs avg), but of course they can't be at their mosts
> >> >simultaneously, or the result will be way over 65535.
> >> >
> >> >BUT the most likely average is around 20s (avg10=200) which will give
me
> >a
> >> >max number of operations left = 3270 (too low !).
> >> >
> >> >So, the question is: what can I do to improve this solution ?
> >> >
> >> >The only thing I have imagined so far is to use
timetoend=(reg/100)*avg10
> > > >for reg greater than 3270 (knowing I will have secs/10 as a result)
but I
> >> >loose too much resolution, and the problem still persists for reg
greater
> >> >than 32700.
> >> >
> >> >Am I getting lost here ? Any ideas ?
> >
> >
> >
> >
> >To UNSUBSCRIBE, just send mail to:
> > basicstamps-unsubscribe@yahoogroups.com
> >from the same email address that you subscribed. Text in the
> >Subject and Body of the message will be ignored.
> >
> >
> >Yahoo! Groups Links
> >
> >To visit your group on the web, go to:
> > http://groups.yahoo.com/group/basicstamps/
> >
> >To unsubscribe from this group, send an email to:
> > basicstamps-unsubscribe@yahoogroups.com
> >
> >Your use of Yahoo! Groups is subject to:
> > http://docs.yahoo.com/info/terms/
>
>
> To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
> from the same email address that you subscribed. Text in the Subject and
Body of the message will be ignored.
>
>
> Yahoo! Groups Links
>
> To visit your group on the web, go to:
> http://groups.yahoo.com/group/basicstamps/
>
> To unsubscribe from this group, send an email to:
> basicstamps-unsubscribe@yahoogroups.com
>
> Your use of Yahoo! Groups is subject to:
> http://docs.yahoo.com/info/terms/
>
>
>
20 to 80 operations per 10-minute time.
Worst case:
65000 operations left / 20 operations = 3250 (10m)
3250 / 6 = 541 hours.
What do you think ?
Original Message
From: "Pedro Drummond" <p.drummond@g...>
To: <basicstamps@yahoogroups.com>
Sent: Wednesday, December 17, 2003 10:14 PM
Subject: Re: [noparse][[/noparse]basicstamps] Counter math
> Tracy, I really appreciate your help.
> I can't use it the way you suggested, though, because:
>
> 1. I think "operations per minute" (the opposite) are more what I need,
> since the average of operations will not exceed 20-something seconds.
> 2. After prototyping with the Stamp, now I am doing this in assembly, what
> complicates a bit.
>
> Your warning about problems after 6554 operations scared me, and I didn't
> see it coming.
>
> This seconds approach for the avg10 seems no good. What I like about it is
> that it keeps the average with full time and full counting, throughout the
> whole work. Better than measuring single-operation times and averaging the
> last n operations.
>
> I understand the challenge here is to keep track of the average and
preview
> how many minutes to the end, all this not letting any calculations exceed
> 65535.
>
> I was thinking maybe adapting that formula to
> ((prog/min)*10)+(((prog//min)*10)/min). Prog (number of operations) must
be
> less than 65535, and min is limited to 6554, as you pointed out. This is
109
> hours, which is more than ok.
> This will give me operations per 10-minute time. Feasible averages are
from
> 20 to 80. But it will be of no help, since when I multiply it by 6500 (ie,
> reg/10)...
>
> Maybe there is a way to separate hours left and minutes left...
>
> What do you suggest ?
>
> Again, thanks a lot for your help.
>
> Regards,
>
> Pedro
>
>
Original Message
> From: "Tracy Allen" <tracy@e...>
> To: <basicstamps@yahoogroups.com>
> Sent: Wednesday, December 17, 2003 6:58 PM
> Subject: Re: [noparse][[/noparse]basicstamps] Counter math
>
>
> > >Hi, Tracy
> > >
> > >> The minmax limit on the avg10
> > >> calculation is prog<6554 operations and secs<65536 seconds.
> > >
> > >I agree with the maximum 65536 seconds, but I don't understand the
> maximum
> > >of 6554 operations.
> >
> > Hi Pedro,
> >
> > The part of the calculation that deals with the remainder has this:
> > secs//prog * 10
> > The problem could come if secs//prog is 6554 or greater, because
> > 6554*10=65540, which is greater than the word size 65535. I say
> > "could" instead of "certainly" because the remainder of the division
> > could fall anywhere between 0 and prog, depending on the value of
> > secs. But it would fail for some values of secs chosen at random,
> > which is enough to make the calculation unreliable.
> >
> >
> >
> > >
> > >> Isn't it enough to estimate within a minute when there is a lot of
> > >> time left to go, and then switch over to seconds when it is less than
> > >> a day left? That should be easier.
> > >
> > >I would be happy with minutes only in both cases. But how to do this,
> since
> > >I calculate seconds per operation on my avg10 ? If I turn it to
> operations
> > >per minute, I guess I would lose too much precision, right ? Maybe
> > >operations per 10 minutes ?
> >
> > Well, once you have seconds per operation (really tenths of a second
> > per operation, avg10), that can be converted to minutes by dividing
> > by 600. No problem: That can be done precisely (within one minute)
> > as a loop binary division.
> >
> > '
binary division loop
> > N=avg10
> > for J=15 to 0 ' 16 bits
> > N=N//600<<1 ' remainder*2
> > result.bit0(J)=N/D ' next bit of result word
> > next
> >
> > The result of the loop is the number of minutes per 65536 operations.
> > The factor 65536 falls naturally out of the algorithm because there
> > are 16 binary left-shifts. For example, if avg10 happens to be 223
> > (22.3 seconds per operation) then result will be 24357 minutes per
> > 65536 operations. (multiply it out: 65536 * 22.3 / 60 = 24357).
> > Now on the Stamp, you can use the ** operator to figure out how many
> > minutes are left:
> > mins = reg ** result ' reg is number of operations remaining
> > If you want to show the number of minutes per operation, with three
> > decimal places, do
> > mins100 = 10000 ** result +5/10 ' with rounding
> > debug cr,".",dec3 mins100,cr
> > So 22.3 seconds will be displayed as 0.372 minute.
> >
> > Division by 65536 is implied in the ** operator, used in this way,
> > and that is naturally the "per 65536" factor. When the number of
> > minutes remaining get small enough, you could change to an algorithm
> > that would put the time remaining in fractions of a minute or in
> > minutes:seconds.
> >
> > regards,
> > Tracy
> >
> >
> > >
> > >Thanks,
> > >
> > >Pedro
> > >
> > >
> > >>
> > >> >Hi, friends
> > >> >
> > >> >I am building a counter (regressive and progressive) which has also
> > >'average
> > >> >of operations per hour' and 'time to end' functions. Not too
> complicated.
> > >I
> > >> >am using 16 bit math and only integer (no floating point)
operations.
> > >> >
> > >> >BUT
> > >> >
> > >> >the problem is my 'time to end' feature. I do it by multiplying the
> > >> >operations left to be done (regressive counter) by the average
number
> of
> > >> >seconds I am taking on each operation. This average is calculated by
> the
> > >> >formula:
> > >> >
> > >> >avg10=(secs/prog)*10)+(((secs//prog)*10)/prog)
> > >> >
> > >> >Prog is the progressive counter, or how many operations were already
> done
> > >in
> > >> >how many secs.
> > >> >
> > >> >By using this I have the average multiplyed by 10, what is good
> because
> > >if
> > >> >the average is 7.5, or 22.3 seconds, I will have 75 or 223 and will
> not
> > >> >loose the decimal.
> > >> >
> > >> >So, the time to end, in seconds, is:
> > >> >
> > >> >timetoend=(reg/10)*avg10
> > >> >
> > >> >I expect reg (regressive counter) to be at most 65535, and avg10 to
be
> at
> > >> >most 300 (30 secs avg), but of course they can't be at their mosts
> > >> >simultaneously, or the result will be way over 65535.
> > >> >
> > >> >BUT the most likely average is around 20s (avg10=200) which will
give
> me
> > >a
> > >> >max number of operations left = 3270 (too low !).
> > >> >
> > >> >So, the question is: what can I do to improve this solution ?
> > >> >
> > >> >The only thing I have imagined so far is to use
> timetoend=(reg/100)*avg10
> > > > >for reg greater than 3270 (knowing I will have secs/10 as a result)
> but I
> > >> >loose too much resolution, and the problem still persists for reg
> greater
> > >> >than 32700.
> > >> >
> > >> >Am I getting lost here ? Any ideas ?
> > >
> > >
> > >
> > >
> > >To UNSUBSCRIBE, just send mail to:
> > > basicstamps-unsubscribe@yahoogroups.com
> > >from the same email address that you subscribed. Text in the
> > >Subject and Body of the message will be ignored.
> > >
> > >
> > >Yahoo! Groups Links
> > >
> > >To visit your group on the web, go to:
> > > http://groups.yahoo.com/group/basicstamps/
> > >
> > >To unsubscribe from this group, send an email to:
> > > basicstamps-unsubscribe@yahoogroups.com
> > >
> > >Your use of Yahoo! Groups is subject to:
> > > http://docs.yahoo.com/info/terms/
> >
> >
> > To UNSUBSCRIBE, just send mail to:
> > basicstamps-unsubscribe@yahoogroups.com
> > from the same email address that you subscribed. Text in the Subject
and
> Body of the message will be ignored.
> >
> >
> > Yahoo! Groups Links
> >
> > To visit your group on the web, go to:
> > http://groups.yahoo.com/group/basicstamps/
> >
> > To unsubscribe from this group, send an email to:
> > basicstamps-unsubscribe@yahoogroups.com
> >
> > Your use of Yahoo! Groups is subject to:
> > http://docs.yahoo.com/info/terms/
> >
> >
> >
>
>
>
> To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
> from the same email address that you subscribed. Text in the Subject and
Body of the message will be ignored.
>
>
> Yahoo! Groups Links
>
> To visit your group on the web, go to:
> http://groups.yahoo.com/group/basicstamps/
>
> To unsubscribe from this group, send an email to:
> basicstamps-unsubscribe@yahoogroups.com
>
> Your use of Yahoo! Groups is subject to:
> http://docs.yahoo.com/info/terms/
>
>
>
Is this right?
total number of operations N.....less than 65536
operations per 10 minutes.....20 to 80
--> 2 to 8 operations per minute
--> 7.5 to 30 seconds per operation.
Total time for all operations.....up to 32768 minutes
= 22 days+18 hours+8 minutes
Is the goal still to estimate how long it will take to finish N - P
remaining operations, given P already completed in elapsed time T? T
can be in minutes. No need to deal with seconds. Is that a fair
summary?
All of those numbers fit in word variables.
Tremaining = (T/P) * (N-P) minutes
That is, on the right hand side, the average time per operation,
times the number of operations remaining. (That will be a good
estimate so long as the time per operation is constant, not speeding
up or slowing down!)
T/P is a number between 1/8 and 1/2. (T in minutes). While there are
tricks that work to divide out that ratio when T and P are relatively
small, I would cut right to a binary division loop to find T/P and
then use ** for the multiplication. I find this simple loop is one
of the most useful math tricks on the Stamp.
N VAR word 'total # operations
P VAR word ' # operations completed
T VAR word ' elapsed time minutes to compete P
X VAR word ' dummy variable for calc
Y VAR word ' ditto
Z VAR word ' ditto
J VAR nib ' loop index
' enter with N, P & T
IF P>32767 THEN X=P/2:Y=T/2 ELSE X=P:Y=T
'
binary division loop
FOR J=15 TO 0 ' 16 bits
Y=Y//X<<1 ' remainder*2
Z.bit0(J)=Y/X ' next bit of result word
NEXT
' now have Z/65536 = T/P
Z = Z ** (N-P) ' minutes remaining
debug "remaining:",DEC Z/60," hours & ",DEC Z//60," minutes",CR
The "IF-THEN" statement adjusts for values of P and T that may exceed 32767.
-- Tracy
>Oops, sorry Tracy. Correcting:
>
>20 to 80 operations per 10-minute time.
>
>Worst case:
>65000 operations left / 20 operations = 3250 (10m)
>3250 / 6 = 541 hours.
>
>What do you think ?
>
>
>
Original Message
>From: "Pedro Drummond" <p.drummond@g...>
>To: <basicstamps@yahoogroups.com>
>Sent: Wednesday, December 17, 2003 10:14 PM
>Subject: Re: [noparse][[/noparse]basicstamps] Counter math
>
>
>> Tracy, I really appreciate your help.
>> I can't use it the way you suggested, though, because:
>>
>> 1. I think "operations per minute" (the opposite) are more what I need,
>> since the average of operations will not exceed 20-something seconds.
>> 2. After prototyping with the Stamp, now I am doing this in assembly, what
>> complicates a bit.
>>
>> Your warning about problems after 6554 operations scared me, and I didn't
>> see it coming.
>>
>> This seconds approach for the avg10 seems no good. What I like about it is
>> that it keeps the average with full time and full counting, throughout the
>> whole work. Better than measuring single-operation times and averaging the
>> last n operations.
>>
>> I understand the challenge here is to keep track of the average and
>preview
>> how many minutes to the end, all this not letting any calculations exceed
>> 65535.
>>
>> I was thinking maybe adapting that formula to
>> ((prog/min)*10)+(((prog//min)*10)/min). Prog (number of operations) must
>be
>> less than 65535, and min is limited to 6554, as you pointed out. This is
>109
>> hours, which is more than ok.
>> This will give me operations per 10-minute time. Feasible averages are
>from
>> 20 to 80. But it will be of no help, since when I multiply it by 6500 (ie,
>> reg/10)...
>>
>> Maybe there is a way to separate hours left and minutes left...
>>
>> What do you suggest ?
>>
>> Again, thanks a lot for your help.
>>
>> Regards,
>>
>
> > Pedro
>>
>
This is it. Sounds easier under your structured approach.
It is a great help that you illustrate your solutions with actual programs.
One could easily get used to this ! [noparse]:)[/noparse]
Thanks again.
Pedro
Original Message
From: "Tracy Allen" <tracy@e...>
To: <basicstamps@yahoogroups.com>
Sent: Thursday, December 18, 2003 9:29 PM
Subject: Re: Fw: [noparse][[/noparse]basicstamps] Counter math
> Hi Pedro,
>
> Is this right?
> total number of operations N.....less than 65536
> operations per 10 minutes.....20 to 80
> --> 2 to 8 operations per minute
> --> 7.5 to 30 seconds per operation.
> Total time for all operations.....up to 32768 minutes
> = 22 days+18 hours+8 minutes
>
> Is the goal still to estimate how long it will take to finish N - P
> remaining operations, given P already completed in elapsed time T? T
> can be in minutes. No need to deal with seconds. Is that a fair
> summary?
>
> All of those numbers fit in word variables.
>
> Tremaining = (T/P) * (N-P) minutes
>
> That is, on the right hand side, the average time per operation,
> times the number of operations remaining. (That will be a good
> estimate so long as the time per operation is constant, not speeding
> up or slowing down!)
>
> T/P is a number between 1/8 and 1/2. (T in minutes). While there are
> tricks that work to divide out that ratio when T and P are relatively
> small, I would cut right to a binary division loop to find T/P and
> then use ** for the multiplication. I find this simple loop is one
> of the most useful math tricks on the Stamp.
>
>
> N VAR word 'total # operations
> P VAR word ' # operations completed
> T VAR word ' elapsed time minutes to compete P
> X VAR word ' dummy variable for calc
> Y VAR word ' ditto
> Z VAR word ' ditto
> J VAR nib ' loop index
>
> ' enter with N, P & T
> IF P>32767 THEN X=P/2:Y=T/2 ELSE X=P:Y=T
> '
binary division loop
> FOR J=15 TO 0 ' 16 bits
> Y=Y//X<<1 ' remainder*2
> Z.bit0(J)=Y/X ' next bit of result word
> NEXT
> ' now have Z/65536 = T/P
> Z = Z ** (N-P) ' minutes remaining
> debug "remaining:",DEC Z/60," hours & ",DEC Z//60," minutes",CR
>
>
> The "IF-THEN" statement adjusts for values of P and T that may exceed
32767.
>
> -- Tracy
>
>
>
>
>
> >Oops, sorry Tracy. Correcting:
> >
> >20 to 80 operations per 10-minute time.
> >
> >Worst case:
> >65000 operations left / 20 operations = 3250 (10m)
> >3250 / 6 = 541 hours.
> >
> >What do you think ?
> >
> >
> >
Original Message
> >From: "Pedro Drummond" <p.drummond@g...>
> >To: <basicstamps@yahoogroups.com>
> >Sent: Wednesday, December 17, 2003 10:14 PM
> >Subject: Re: [noparse][[/noparse]basicstamps] Counter math
> >
> >
> >> Tracy, I really appreciate your help.
> >> I can't use it the way you suggested, though, because:
> >>
> >> 1. I think "operations per minute" (the opposite) are more what I need,
> >> since the average of operations will not exceed 20-something seconds.
> >> 2. After prototyping with the Stamp, now I am doing this in assembly,
what
> >> complicates a bit.
> >>
> >> Your warning about problems after 6554 operations scared me, and I
didn't
> >> see it coming.
> >>
> >> This seconds approach for the avg10 seems no good. What I like about it
is
> >> that it keeps the average with full time and full counting, throughout
the
> >> whole work. Better than measuring single-operation times and averaging
the
> >> last n operations.
> >>
> >> I understand the challenge here is to keep track of the average and
> >preview
> >> how many minutes to the end, all this not letting any calculations
exceed
> >> 65535.
> >>
> >> I was thinking maybe adapting that formula to
> >> ((prog/min)*10)+(((prog//min)*10)/min). Prog (number of operations)
must
> >be
> >> less than 65535, and min is limited to 6554, as you pointed out. This
is
> >109
> >> hours, which is more than ok.
> >> This will give me operations per 10-minute time. Feasible averages are
> >from
> >> 20 to 80. But it will be of no help, since when I multiply it by 6500
(ie,
> >> reg/10)...
> >>
> >> Maybe there is a way to separate hours left and minutes left...
> >>
> >> What do you suggest ?
> >>
> >> Again, thanks a lot for your help.
> >>
> >> Regards,
> >>
> >
> > > Pedro
> >>
> >
>
> To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
> from the same email address that you subscribed. Text in the Subject and
Body of the message will be ignored.
>
>
> Yahoo! Groups Links
>
> To visit your group on the web, go to:
> http://groups.yahoo.com/group/basicstamps/
>
> To unsubscribe from this group, send an email to:
> basicstamps-unsubscribe@yahoogroups.com
>
> Your use of Yahoo! Groups is subject to:
> http://docs.yahoo.com/info/terms/
>
>
>
>Tracy, thank you very much.
>
>This is it. Sounds easier under your structured approach.
>It is a great help that you illustrate your solutions with actual programs.
>One could easily get used to this ! [noparse]:)[/noparse]
>
>Thanks again.
>
>Pedro
>
>
>
Original Message
>From: "Tracy Allen" <tracy@e...>
>To: <basicstamps@yahoogroups.com>
>Sent: Thursday, December 18, 2003 9:29 PM
>Subject: Re: Fw: [noparse][[/noparse]basicstamps] Counter math
>
>
>> Hi Pedro,
>>
>> Is this right?
>> total number of operations N.....less than 65536
>> operations per 10 minutes.....20 to 80
>> --> 2 to 8 operations per minute
>> --> 7.5 to 30 seconds per operation.
>> Total time for all operations.....up to 32768 minutes
>> = 22 days+18 hours+8 minutes
>>
>> Is the goal still to estimate how long it will take to finish N - P
>> remaining operations, given P already completed in elapsed time T? T
>> can be in minutes. No need to deal with seconds. Is that a fair
>> summary?
>>
>> All of those numbers fit in word variables.
>>
>> Tremaining = (T/P) * (N-P) minutes
>>
>> That is, on the right hand side, the average time per operation,
>> times the number of operations remaining. (That will be a good
>> estimate so long as the time per operation is constant, not speeding
>> up or slowing down!)
>>
>> T/P is a number between 1/8 and 1/2. (T in minutes). While there are
>> tricks that work to divide out that ratio when T and P are relatively
>> small, I would cut right to a binary division loop to find T/P and
>> then use ** for the multiplication. I find this simple loop is one
>> of the most useful math tricks on the Stamp.
>>
>>
>> N VAR word 'total # operations
>> P VAR word ' # operations completed
>> T VAR word ' elapsed time minutes to compete P
>> X VAR word ' dummy variable for calc
>> Y VAR word ' ditto
>> Z VAR word ' ditto
>> J VAR nib ' loop index
>>
>> ' enter with N, P & T
>> IF P>32767 THEN X=P/2:Y=T/2 ELSE X=P:Y=T
>> '
binary division loop
>> FOR J=15 TO 0 ' 16 bits
>> Y=Y//X<<1 ' remainder*2
>> Z.bit0(J)=Y/X ' next bit of result word
>> NEXT
>> ' now have Z/65536 = T/P
>> Z = Z ** (N-P) ' minutes remaining
>> debug "remaining:",DEC Z/60," hours & ",DEC Z//60," minutes",CR
> >
> >
> > The "IF-THEN" statement adjusts for values of P and T that may exceed
>32767.
> >
> > -- Tracy