Incorrect summaries after entering partial fill-ups

2 views
Skip to first unread message

wandering_goat

unread,
Sep 20, 2010, 1:21:58 AM9/20/10
to webos_rbtwhiz
Hi there:

Just wanted to point out and suggest some improvements to the way the
calculations in the fuel summary section are done, after having
entered some partial fill-ups (eg. $10 in the tank). I'm Canadian, so
I'll be using metric figures to illustrate my point.

Now, the consumption / mileage is being calculated correctly, which
I'm very happy with. For example, if I put $5 in and the next time I
fill up the tank completely, the L/100KM figure in the second fill-up
reflects both amounts (so the total distance traveled both before and
after the $5 fill-up, and the combined litres entered in the two fill-
ups are accounted for). This in turn also reflects well in the fuel
summary figures for L/100KM and KM/L, which are all good. I don't know
yet if this will hold up with multiple partial fill-ups in a row,
though.


Where it starts to run into some trouble is where the partial fill-ups
are ignored and where they aren't. Here are the sections in particular
which have issues:


Kilometers total - This does not include the KM entered for the trip
in the partial fill-up. I don't see any (non-technical) reason that
people wouldn't want these distances included. Myself, I only do
partial fill-ups when I don't have my credit card on me and I need the
gas (ie. when I've gotten almost a full tanks worth of travel), so
this cuts out a large chunk of my distance traveled.

Litres Total - This does not include the amount of L put into partial
fill-ups.

Cost per Litre - Every partial fill-up here is included in the
calculation, but at a cost of $0. Needless to say, this dramatically
lowers the mean cost / L. I think that the partial fill-ups should be
included at their exact values (both amount of litres and amount of
dollars paid).

Cost total - This does not include the cost of partial fill-ups.
-----------------------------------------------------------------------------

I'll also comment on the other areas, from what I can see so far, just
in case. I can't really tell if they're correct or only seem correct,
without having exact figures / formulas:


Estimated KM - Seems correct, after recalculating based on the
(correct) mileage / consumption figures, which include all
transactions.

KM / L & L/100KM - Both are good, include all transactions.

Litres per event & cost per event - Both are correct, includes partial-
fill ups as well, as you can see the mean on the graph dip down with
partial fill-ups.

Cost per KM - This one, I think it doesn't include the cost of partial
fill-ups (as the orange line on the graph dips down to 0), but the
mean isn't really affected by this. I think this is because it doesn't
include both the cost and the km for partial fill-ups, thus leaving
mean unchanged, but I'm just guessing there. It's hard to tell because
the numbers it yields are low and thus can't be really analyzed well
(under 10cents per km, with no fractions of a cent).
-----------------------------------------------------------------------------

Anyway, I hope that's helpful. I'm not sure about the way that this is
programmed, but given that mileage / consumption is calculated right
(meaning it keeps track of total distance and total km), perhaps the
above items could be fixed as well in future updates?

Love the program, by the way. It's easy to enter, graphs are nice, and
I like that you can enter partial fill-ups and have it calculate
mileage correctly, which is my biggest need (I have an auto
maintenance program on my computer that can't do this, and you have to
combine partial and complete fill-ups together to get the mileage!)
Keep up the good work!

Rob (rbtwhiz)

unread,
Sep 21, 2010, 10:53:46 AM9/21/10
to webos_rbtwhiz
Multiple partial fill events in succession should not present any
issues that a single partial fill event doesn't; the mechanism for
capturing partial events is exactly the same regardless of the number
of occurrences, the only thing that changes is the number of
iterations.

I'll have to trace the summary building routines to identify where
what you describe might be introduced. Thank you for the report, it is
helpful.

-Rob

Brian Kezar

unread,
Sep 21, 2010, 11:44:33 AM9/21/10
to webos_...@googlegroups.com
Hi Rob, loved your program on the Pre. Will you be doing one for the iPhone ? Tks Brian

Sent from my iPhone

> --
> You received this message because you are subscribed to the Google Groups "webos_rbtwhiz" group.
> To post to this group, send email to webos_...@googlegroups.com.
> To unsubscribe from this group, send email to webos_rbtwhi...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/webos_rbtwhiz?hl=en.
>

Rob (rbtwhiz)

unread,
Sep 22, 2010, 3:04:45 AM9/22/10
to webos_rbtwhiz
I've isolated and corrected the issues with the totals. They appear to
have been introduced in 0.9.13 or 0.9.14, when the averaging algorithm
was re-written. Totals (and offsets in the case of partial events)
were calculated a bit differently prior to these builds.

I may have also fixed the cost per volume [mean], but I'm still doing
some tests on this one.

-Rob

On Sep 19, 11:21 pm, wandering_goat <p.gronow...@gmail.com> wrote:

Rob (rbtwhiz)

unread,
Sep 22, 2010, 3:09:13 AM9/22/10
to webos_rbtwhiz
Thanks, Brian. It isn't completely out of the realm of possibility,
but I don't have any specific plans to develop for the iPhone at the
moment. I appreciate the interest, though.

-Rob

On Sep 21, 9:44 am, Brian Kezar <brianke...@gmail.com> wrote:
> Hi Rob, loved your program on the Pre. Will you be doing one for the iPhone ? Tks Brian
>
> Sent from my iPhone
>

wandering_goat

unread,
Sep 22, 2010, 10:37:11 PM9/22/10
to webos_rbtwhiz
Wow, very cool. Thanks for your hard work, looking forward to the
update and to your future plans for the program!
Reply all
Reply to author
Forward
0 new messages