bug#56558: [PATCH] build: Simpler percentage calculation.

[Csepp <raingloom@riseup.net>]

Liliana Marie Prikler <liliana.prikler@ist.tugraz.at> writes:

> Am Freitag, dem 15.07.2022 um 12:17 +0200 schrieb Csepp:
>> 
>> Liliana Marie Prikler <liliana.prikler@ist.tugraz.at> writes:
>> 
>> > Am Donnerstag, dem 14.07.2022 um 16:58 +0200 schrieb raingloom:
>> > > * build-aux/compile-all (%): Simpler calculation that avoids
>> > > intermediate float.
>> > > ---
>> > >  build-aux/compile-all.scm | 2 +-
>> > >  1 file changed, 1 insertion(+), 1 deletion(-)
>> > > 
>> > > diff --git a/build-aux/compile-all.scm b/build-aux/compile-
>> > > all.scm
>> > > index 9ffbce43ad..6fdbe0dea8 100644
>> > > --- a/build-aux/compile-all.scm
>> > > +++ b/build-aux/compile-all.scm
>> > > @@ -89,7 +89,7 @@ (define (parallel-job-count*)
>> > >  
>> > >  (define (% completed total)
>> > >    "Return the completion percentage of COMPLETED over TOTAL as
>> > > an
>> > > integer."
>> > > -  (inexact->exact (round (* 100. (/ completed total)))))
>> > > +  (quotient (* 100 completed) total))
>> > I am fairly certain that this changes the semantics of %.  Try for
>> > example (% 23 24).
>> > 
>> > Cheers
>> 
>> It rounds down instead of up, which, :shrug:.
>> If that's a deal breaker, feel free to close this.
> It's not simply "rounding up", you need to round towards the nearest,
> which can be done with just quotient and remainder, but is probably
> more complicated than the float solution.

Yeah, I meant it rounds up in that case. Since it's only used for
indicating progress to the user, being off by 1% is not something I'd
worry about, but whatevs, I guess we can leave it as is.