Re: Time precision

[Yuri Pryadkin <yuri@who.isi.edu>]

I forgot to mention that the fix is almost as you've suggested:
changing "%g to "%.15g".  [15 from float.h, if you have it on your
system, is the max # of significant digits in a double]. First I
thought that it wouldn't be quite nice, as there would be too many
digits printed out.  Then I realized that we're rounding time to six
digits after the decimal anyway before printing it, and since %g
suppresses trailing zeros we're OK.

I've updated test results as well and the change should appear in the
next daily snapshot (there were some transient errors today).

  -Yuri

Yuri Pryadkin <yuri@ISI.EDU> writes:

> It's been fixed.  Thanks!
> 
>  -Yuri
> 
> Pablo Molinero Fernandez <molinero@stanford.edu> writes:
> 
> > Hi Massimo,
> > 
> > I agree with you. I think that in the next ns release they should maintain
> > the precission of the traces throughout the simulation. It is a simple
> > matter of changing lines 255 and 276 in ns-2/ns-2/trace.cc from:
> > 
> > sprintf(wrk_, "%c %g %d %d %s %d %s %d %s%s %s%s %d %d",
> > 
> > to:
> > 
> > sprintf(wrk_, "%c %.9g %d %d %s %d %s %d %s%s %s%s %d %d",
> > 
> > or:
> > 
> > sprintf(wrk_, "%c %.9f %d %d %s %d %s %d %s%s %s%s %d %d",
> > 
> > Pablo
> > 
> > On Tue, 15 Jun 1999, Massimo Pegorer - Stage wrote:
> > 
> > > Running some simulations I've noticed that time in ns output files is
> > > always given with the six most significant digits, and this fact gives
> > > me some problems in postprocessing these files because of the rounding;
> > > for example, when the time goes beyond 100 seconds, fractions of msec
> > > are lost:
> > > 
> > > [...]
> > > - 99.9961 0 1 cbr 1000 ------- 0 0.0 1.0 19803 19803
> > > r 99.9962 0 1 cbr 1000 ------- 0 0.0 1.0 19801 19801
> > > r 100.001 0 1 cbr 1000 ------- 0 0.0 1.0 19802 19802
> > > + 100.003 0 1 cbr 1000 ------- 0 0.0 1.0 19804 19804
> > > [...]
> > > 
> > > This has curious consequences for nam, too. For absurde, if you have a
> > > cbr flow with 5ms interval time between packets (interval_=0.005) and it
> > > starts at 1000, packets #0 and #1 will have the same start-time (1000)
> > > and nam will visualize only packet #1 and not #0!
> > > 
> > > + 1000 0 1 cbr 1000 ------- 0 0.0 1.0 0 0
> > > - 1000 0 1 cbr 1000 ------- 0 0.0 1.0 0 0
> > > + 1000 0 1 cbr 1000 ------- 0 0.0 1.0 1 1
> > > - 1000 0 1 cbr 1000 ------- 0 0.0 1.0 1 1
> > > + 1000.01 0 1 cbr 1000 ------- 0 0.0 1.0 2 2
> > > - 1000.01 0 1 cbr 1000 ------- 0 0.0 1.0 2 2
> > > r 1000.01 0 1 cbr 1000 ------- 0 0.0 1.0 0 0
> > > + 1000.01 0 1 cbr 1000 ------- 0 0.0 1.0 3 3
> > > - 1000.01 0 1 cbr 1000 ------- 0 0.0 1.0 3 3
> > > r 1000.01 0 1 cbr 1000 ------- 0 0.0 1.0 1 1
> > > r 1000.02 0 1 cbr 1000 ------- 0 0.0 1.0 2 2
> > > [...]
> > > 
> > > I think this depends on sprintf %g default precisions (in
> > > Trace::format), but in my opinion it would be more useful to have always
> > > time with the same format and with six digits after the decimal-point
> > > (microsec), such as with %f.
> > > I hope not to have annoyed you with tedious questions. Thanks for
> > > suggest.
> > > 
> > > max
> > > 
> > > 
> > > --
> > > Massimo Pegorer, student
> > > Dipartimento di Elettronica e Informatica
> > > Universita' degli Studi di Padova
> > > Padova - ITALIA
> > > 
> > > 
> > 
> > -------------------------------------------------
> > Pablo Molinero Fern�ndez
> > (650) 497-7490 (home)
> > (650) 723-1414 (office)
> > http://www.stanford.edu/~molinero
> > Snail-mail:  Gates Building 3A, Room 342
> >              Stanford, CA 94305-9030