On 19 October 2011 11:08, Leonardo Robol <l...@robol.it> wrote:
> Do you think the patch could be included upstream? I think that many
> broken-batteries people would be glad to have a consistent estimate of
> the remaining lifetime.

Yes, this sounds cool. Back when all the estimation code was in g-p-m
I used a moving average, and you're right, it leads to much better
prediction results. You just have to remember to clear the cache if
the power source changes in any way, e.g. charging->discharging or if
the battery is changed.

> I understand, though, that this change make the rate change slowly in
> response to some events (like starting heavy computations or so...) but
> I still think that taking the average on some more points is nicer.

Agreed.

> I'm attaching the patch to this email.

Some quick comments:

* g_malloc_n() -> g_new0()

* A lot of the curly brackets don't match the existing code, do:

if (foo) {
<tab>bar();
}

* Same for "for (foo) {"

* You probably want to initialize the values with "0.0f" not "0" to
make it clear they are doubles, not integers.

> P.S.: The memmove() call are not the best way to handle prepending new
> entries in the array; if you think it's nicer I could write a simple
> circular buffer to store energy_old values and timespecs.

Yes, I think just storing an index pointing to the start of the buffer
would make things a lot nicer.

Otherwise, I like it. Thanks.

Richard
_______________________________________________
devkit-devel mailing list
devkit-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/devkit-devel

Reply via email to