<div dir="ltr"><div><div><div><div><div><div>this is "round off error".  It always is possible in a finite system (all computers).  It is possible to minimize the probability of a round off error, but the issue can never be completely eliminated.  In this case, ZoomBar::update_clocks() is updating the text boxes with the current selection.   I created an example and captured it in the debugger, with the following results (suitably trimmed of irrelevant debug output)<br><br>Run till exit from #0  LocalSession::get_selectionend (this=0x73e23a0, highlight_only=1) at localsession.C:422<br>Value returned is $10 = 12.283999999999999<br>Run till exit from #0  LocalSession::get_selectionstart (this=0x73e23a0, highlight_only=1) at localsession.C:408<br>length_value->update_position(mwindow->edl->local_session->get_selectionend(1) - <br>Value returned is $11 = 4.7839999999999998<br><br></div>note that neither are "exact", but both are very close.  The normalized mantissa of a double variable is 49 bits, which can represent 49 * log(2)/log(10) = 14.75 digits.  The debugger output is over-specified to help with the issues of round off errors, and is showing 16 fraction digits (53+ bits).  Anyhow, these are subtracted for the selection duration, and the result is used to update the selection length textbox as:<br><br>LengthTextBox::update_position (this=0x545f410, new_position=7.4999999999999991) at zoombar.C:632<br><br></div>this is converted to the selected time units via Units::totext, and because the current format is set to TIME_HMS, this code is used to display the result:<br><br>176             case TIME_HMS: {<br>177                     seconds = fabs(seconds);<br>178                     hour = seconds/3600;<br>179                     minute = seconds/60 - hour*60;<br>180                     second = seconds - (hour*3600 + minute*60);<br>181                     seconds -= (int64_t)seconds;<br>182                     thousandths = (int64_t)(seconds*1000) % 1000;<br>183                     sprintf(text, "%d:%02d:%02d.%03d",<br>184                             (int)hour, minute, second, thousandths);<br>185                     break; }<br><br></div>Because all of these calculations use truncation (round down), the reuslt is that it displays:<br>(gdb) p text<br>$21 = 0x5460a44 "0:00:07.499"<br><br></div>It is fairly common to try to round the least significant digit when displaying a number.  Since there are always 3 significant digits in the fraction, line 177 could be changed to:<br>177                     seconds = fabs(seconds) + 0.5e-3;<br></div>which will cause the fraction to be rounded to the nearest digit, instead of rounded down.<br><br></div>Since you have put such effort into this, I will add these rounding constants... but I have to say, it only moves the issue to another spot (which may be less likely in fact to be an issue), but the problem is inherent to all computers.  We all live with round off error.<br><br><br><div><div>gg<br><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 26, 2016 at 11:06 AM, igor_ubuntu <span dir="ltr"><<a href="mailto:sitelve@gmail.com" target="_blank">sitelve@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><br></blockquote><div class="gmail_extra"><br><div class="gmail_quote">2016-10-26 18:01 GMT+03:00 Einar Rünkaru <span dir="ltr"><<a href="mailto:einarrunkaru@gmail.com" target="_blank">einarrunkaru@gmail.com</a>></span>:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span class="m_1644583741052537207gmail-">
On 10/26/2016 03:39 PM, Good Guy wrote:<br>
<blockquote style="margin-top:0px;margin-bottom:0px" class="gmail_quote">
It may be because the align cursor on frames setting is applied.  The<br>
cursor alignment is adding a frame in cases where the selection is not<br>
already frame aligned (this is a guess).<br>
gg<br>
</blockquote>
<br></span>
'align cursor on frames' cuts tracks to equival length.<span class="m_1644583741052537207gmail-HOEnZb"><font color="#888888"><br>
<br>
Einar</font></span><br></blockquote><div><br></div><div>The same situation and without the settings "align cursor on frames" <br></div><div>Look this screencast <a href="https://www.datafilehost.com/d/508b3520" target="_blank">https://www.datafilehost.com/<wbr>d/508b3520</a><br> <span id="m_1644583741052537207gmail-result_box" class="m_1644583741052537207gmail-" lang="en"><span class="m_1644583741052537207gmail-">It shows</span> <span class="m_1644583741052537207gmail-">strange behavior</span> <span>and a unstable</span> <span class="m_1644583741052537207gmail-"></span></span><span id="m_1644583741052537207gmail-result_box" class="m_1644583741052537207gmail-" lang="en"><span class="m_1644583741052537207gmail-">calculation of selection </span></span><span id="m_1644583741052537207gmail-result_box" class="m_1644583741052537207gmail-" lang="en"><span class="m_1644583741052537207gmail-">length.<br></span></span><span class="m_1644583741052537207gmail-" id="m_1644583741052537207gmail-result_box" lang="en"><span class="m_1644583741052537207gmail-alt-edited">I did not yet</span> <span>check </span><span>your</span> <span>recent changes</span> <span>in git</span><span>.</span></span><br></div></div><br></div></div>
<br>______________________________<wbr>_________________<br>
Cinelerra mailing list<br>
<a href="mailto:Cinelerra@lists.cinelerra-cv.org">Cinelerra@lists.cinelerra-cv.<wbr>org</a><br>
<a href="http://lists.cinelerra-cv.org/cgi-bin/mailman/listinfo/cinelerra" rel="noreferrer" target="_blank">http://lists.cinelerra-cv.org/<wbr>cgi-bin/mailman/listinfo/<wbr>cinelerra</a><br>
<br></blockquote></div><br></div>