Groups | Search | Server Info | Login | Register


Groups > comp.lang.c > #397300

Re: Why is this happening?

From Michael S <already5chosen@yahoo.com>
Newsgroups comp.lang.c
Subject Re: Why is this happening?
Date 2026-03-30 13:06 +0300
Organization A noiseless patient Spider
Message-ID <20260330130632.0000722f@yahoo.com> (permalink)
References (5 earlier) <10qb613$1ib53$1@dont-email.me> <10qcdc6$20lg0$1@dont-email.me> <10qd8hj$282cq$1@dont-email.me> <20260330112332.0000325c@yahoo.com> <10qdf0k$29vuo$1@dont-email.me>

Show all headers | View raw


On Mon, 30 Mar 2026 11:16:04 +0200
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

> On 2026-03-30 10:23, Michael S wrote:
> > On Mon, 30 Mar 2026 09:25:39 +0200
> > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> >   
> >> On 2026-03-30 01:41, Mike Terry wrote:  
> >>> On 29/03/2026 13:30, Janis Papanagnou wrote:  
> >>>> On 2026-03-28 21:58, Josef Möllers wrote:  
> >>>>> On 27.03.26 17:02, Scott Lurndal wrote:  
> >>>>>> =?UTF-8?Q?Josef_M=C3=B6llers?= <josef@invalid.invalid> writes:
> >>>>>>  
> >>>>>>> On 27.03.26 05:46, Janis Papanagnou wrote:  
> >>>>>>>> Subject: Why is this happening?
> >>>>>>>>
> >>>>>>>> I think because you are doing wrong calculations here:
> >>>>>>>>
> >>>>>>>>    > return ((stop.tv_sec-started.tv_sec) + (stop.tv_nsec-
> >>>>>>>> started.tv_nsec)) / B;
> >>>>>>>>
> >>>>>>>> You should not subtract the components s/ns separately when
> >>>>>>>> scaling. Instead build the float stop number and started
> >>>>>>>> number separately and then subtract.  
> >>>>>>>
> >>>>>>> I usually subtract the nsec parts and if the result is
> >>>>>>> negative, adjust
> >>>>>>> the sec and the nsec parts accordingly:  
> >>>>
> >>>> That's fine if you operate on the integer parts separately. (I'm
> >>>> sometimes doing a similar thing if I'm working with the integral
> >>>> components of a calendar date, for example.)
> >>>>
> >>>> Generally I prefer to use types that fit the element I'm
> >>>> operating on. That's why I prefer to express  dT = stop_time -
> >>>> start_time in the case above as
> >>>>     (stop_s + F * stop_ns) - (start_s + F * start_ns)   with
> >>>> F=1e-9 to easily see the application entities and logic.
> >>>>
> >>>> I think that's the clearest expression, and it's an expression
> >>>> without conditional. (A habit from the early days of programming
> >>>> where conditionals were suboptimal. Nowadays it's meaningless,
> >>>> and huge amounts of time wasted at other places; using suboptimal
> >>>> algorithms, or over-complicated processes, or just bloat.) The
> >>>> expressions in your variant appear to me unnecessary confusing
> >>>> with using '1000000000UL', for example. - As said, basically a
> >>>> matter of personal preference, despite the rationale of clarity,
> >>>> which is also mostly subjective.
> >>>>     
> >>> We have a calculation here, which ignoring precision issues is of
> >>> the form
> >>>
> >>>      (A1  +  A2)  -  (B1  +  B2)
> >>>
> >>> The magnitudes are such that A1,B1 are some order of magnitude
> >>> greater than A2,B2, but the differences A1-B1, A2-B2 are of
> >>> broadly similar magnitude (in the scenario we're considering).
> >>> If we were using a single integral type for everything, or some
> >>> kind of infinite precision real numbers, the order of calculation
> >>> would not matter, but floating point is not like that - the order
> >>> of calculation can give different results, due to the finite
> >>> precision limits.
> >>>
> >>> In such a situation, it's surely good practice to subtract the
> >>> components of similar magnitude first, then add the results, as
> >>> this avoids unnecessarily dropping the precision of the final
> >>> result.  That seems more important than how subjectively clear the
> >>> expression might look to someone. :)
> >>>
> >>> So I'd go with the original (A1-B1) + (A2-B2) expression, even if
> >>> someone does some calculation to show that on a particular
> >>> architecture, with the actual float/time types being used, the
> >>> "logical/clearest expression" ordering ((A1+A2) - (B1+B2)) is
> >>> /sufficiently/ precise for purposes.  
> >>
> >> Mike, I see where you're coming from; from numerical mathematics.
> >> In cases where you have to accumulate many values of different
> >> magnitude what you describe is necessary to not lose the values of
> >> minor value in the final sum, since a large amount of such values
> >> may contribute. Here we were calculating run-times. A "problem"
> >> arises if you cannot represent huge seconds values combined with
> >> high resolution nano-sec values in one, say, double variable. If
> >> one thinks that, say, with runtime of minutes or hours the least
> >> nanoseconds resolution is (for your case) of interest you may do
> >> that. (And mind that we're still not accumulating many such
> >> values!) But usually an IEEE double float with 64 bit and ~16
> >> decimal figures should suffice for that purpose.  
> > 
> > No, it isn't.
> > IEEE binary64 a.k.a. C double is capable to represent exact
> > nanoseconds only up to 104 days. [...]  
> 
> So it's even better than my conservative "minutes or hours". Thanks
> for making my point.
> 
> Besides that you seem to have completely missed what I actually said.
> 
> With your figures; do you need in runtime measurements of 104 days a
> resolution of nanoseconds? - If so[*], as I already said above, you
> may do that (i.e. using other methods than using a IEEE double float).
> In my experience for such purposes there's other requirements than
> 64 bit of resolution. (In yours it may be different; "YMMV" as I say.)
> 
> [*] And if that resolution is supported by the respective OSes in the
> first place of course.
> 
> >> YMMV.  
> > 
> > No, it is not a matter of mileage.  
> 
> If you have other requirements that's (in my understanding) an issue
> of mileages. (My English may not be good enough, though, so I may
> misunderstand what mileage means, or what you might mean by that.)
> 

"Other requirements" are original requirements. Both A1 and B1 taken
from tv_sec field of 'struct timespec' that is returned by either
timespec_get() or clock_gettime(). The base for those values, IIRC, is
not specified by C Standard, but on majority of "hosted" C
environments, even non-Unix, it follows Unix tradition (and POSIX
requirements ?) of being seconds since start of Unix Epoch.

> > There is a correct way (Mike's and
> > DFS's and of just about everybody else's who posted in this thread)
> > and incorrect way - yours.  
> 
> (You presented many times already that you have a personal problem.
> You don't need to constantly expose your mindset. Please calm down.
> Myself I'm not interested in personal attacks.)
> 

I have problems with people that express full confidence while
discussing issues they have only very basic ideas about.
You are not the only one like that in c.l.c but in your case I have a
hope that conditions are curable. The latter is the only part that you
can take as personal.

> If, OTOH, I missed something essential you said (that considers what
> I said, of course), you're welcome to clarify that without constantly
> playing your offending game.
> 
> Janis
>




Back to comp.lang.c | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Why is this happening? DFS <nospam@dfs.com> - 2026-03-27 00:12 -0400
  Re: Why is this happening? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-27 05:46 +0100
    Re: Why is this happening? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-27 06:01 +0100
      Re: Why is this happening? DFS <nospam@dfs.com> - 2026-03-27 02:31 -0400
    Re: Why is this happening? Josef Möllers <josef@invalid.invalid> - 2026-03-27 10:15 +0100
      Re: Why is this happening? scott@slp53.sl.home (Scott Lurndal) - 2026-03-27 16:02 +0000
        Re: Why is this happening? Josef Möllers <josef@invalid.invalid> - 2026-03-28 21:58 +0100
          Re: Why is this happening? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-29 14:30 +0200
            Re: Why is this happening? scott@slp53.sl.home (Scott Lurndal) - 2026-03-29 18:56 +0000
              Re: Why is this happening? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-30 02:00 +0200
            Re: Why is this happening? Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2026-03-30 00:41 +0100
              Re: Why is this happening? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-30 09:25 +0200
                Re: Why is this happening? Michael S <already5chosen@yahoo.com> - 2026-03-30 11:23 +0300
                Re: Why is this happening? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-30 11:16 +0200
                Re: Why is this happening? Michael S <already5chosen@yahoo.com> - 2026-03-30 13:06 +0300
      Re: Why is this happening? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-28 01:46 +0000
        Re: Why is this happening? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-27 20:41 -0700
          Re: Why is this happening? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-28 05:17 +0100
            Re: Why is this happening? David Brown <david.brown@hesbynett.no> - 2026-03-28 10:09 +0100
              Re: Why is this happening? Bart <bc@freeuk.com> - 2026-03-28 11:33 +0000
                Re: Why is this happening? David Brown <david.brown@hesbynett.no> - 2026-03-28 16:35 +0100
                Re: Why is this happening? Richard Harnden <richard.nospam@gmail.invalid> - 2026-03-28 16:56 +0000
                Re: Why is this happening? Richard Harnden <richard.nospam@gmail.invalid> - 2026-03-28 16:58 +0000
                Re: Why is this happening? James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-03-28 19:24 -0400
                Re: Why is this happening? David Brown <david.brown@hesbynett.no> - 2026-03-29 11:33 +0200
                Re: Why is this happening? Richard Harnden <richard.nospam@gmail.invalid> - 2026-03-29 16:30 +0100
                Re: Why is this happening? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-29 10:37 -0700
                Re: Why is this happening? David Brown <david.brown@hesbynett.no> - 2026-03-31 16:20 +0200
                Re: Why is this happening? Richard Harnden <richard.nospam@gmail.invalid> - 2026-03-31 17:19 +0100
                Re: Why is this happening? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-03-29 13:19 -0700
                Re: Why is this happening? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-03-29 13:26 -0700
                Re: Why is this happening? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-29 14:14 -0700
                Re: Why is this happening? James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-03-29 20:47 -0400
                Re: Why is this happening? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-29 13:57 -0700
                Re: Why is this happening? David Brown <david.brown@hesbynett.no> - 2026-03-31 16:26 +0200
          Re: Why is this happening? scott@slp53.sl.home (Scott Lurndal) - 2026-03-28 15:14 +0000
            Re: Why is this happening? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-28 10:18 -0700
              Re: Why is this happening? scott@slp53.sl.home (Scott Lurndal) - 2026-03-29 18:50 +0000
            Re: Why is this happening? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-28 19:12 -0700
              Re: Why is this happening? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-28 22:31 -0700
                Re: Why is this happening? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-06 12:11 -0700
                Re: Why is this happening? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-06 14:20 -0700
                Re: Why is this happening? Michael S <already5chosen@yahoo.com> - 2026-04-07 02:05 +0300
                Re: Why is this happening? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-04-06 17:42 -0700
              Re: Why is this happening? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-29 14:43 -0700
            Re: Why is this happening? Michael S <already5chosen@yahoo.com> - 2026-03-29 11:50 +0300
              Re: Why is this happening? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-29 13:54 -0700
                Re: Why is this happening? Michael S <already5chosen@yahoo.com> - 2026-03-30 02:05 +0300
                Re: Why is this happening? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-29 16:22 -0700
                Re: Why is this happening? Michael S <already5chosen@yahoo.com> - 2026-03-30 10:57 +0300
                Re: Why is this happening? James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-03-30 20:37 -0400
                Re: Why is this happening? Michael S <already5chosen@yahoo.com> - 2026-03-31 11:48 +0300
                Re: Why is this happening? James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-03-31 10:51 -0400
                Re: Why is this happening? candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2026-03-31 19:00 +0000
        Re: Why is this happening? Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-04-03 02:41 +0100

csiph-web