Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #8261

Re: Looking for simple brute force solution

Show all headers | View raw

On 1/4/18 11:46 AM, root wrote:
> Richard Damon <Richard@Damon-Family.org> wrote:
>> On 1/4/18 5:14 AM, root wrote:
>>> cost of materials 100.
>>> cost of assembly   45.
>>> cost of item      145.
>>> cost of shipping   11.
>>> total cost        156.
>>>
>>>
>>> In this list it is easy to see that we can take the
>>> first, second, and fourth items to account for the total
>>> cost. We have to ignore the intermediate term 145.
>>
>> It sounds like your goal is to transform that list into something like;
>>
>>
>>           100   Cost of materials
>>            45   Cost of Assembly
>>       145      Cost of Item
>>        11      Cost of Shipping
>> 156         Total Cost
>>
>> Where you assign everything a 'level' (the grand sum being level 0) and
>> a given level is the sum of all the items 1 level higher between it and
>> the previous item of its level. It sounds like you also want to allow
>> some items to be negated for the sum, as credits/debits aren't carefully
>> indicated (which actually make the process much tougher). If at all
>> possible, I would try to understand the category names and assign a sign
>> to them, even if I had to try a couple possibilities, as only having
>> sums and no differences makes things much simpler.
> 
> It would make sense that in the income statement expenses would always
> have a minus sign, but in my data that isn't true. In order for the
> numbers to work out, some of the expenses have to be added to
> income. For example, the entry "Total Interest Expense" has to
> be subtracted from income. Several lines down, "Other Interest Expense"
> has to be added to income for the numbers to hang together. It would
> make sense that Other Interest Expense should be ignored as having
> already been included in Total Interest Expense.
> 
> I am resorting to the brute force method because too many of the
> items I see don't make sense to me.
>>
>> Now if 'running sums' aren't actually right after the items they are the
>> sum for, then you probably need to brute force the solution.
> 
> In my case, the running sums are generally ahead of the individual
> items, but are not identified as running sums. Not only that, but
> some items which are identified as "expense" are added to income
> instead of subtracted.

If they are consistently in front, then it should still be possible to 
try to identify the possible running sums (you just start at the bottom 
and work up).

I suppose if you are a bit sloppy with terms, and 'expense' could 
sometimes be something you bill your customers, and thus be an income 
category (likely with some other expense item somewhere else that 
decreases income as a justification for it, a bit like the added fees in 
a lot of services which indirectly reference government fees and taxes 
that they are sort of forwarding to their customers).

> 
>>
>> IF you can try assigning signs to values to make it so you are always
>> adding, then you can work starting at the top of the list with the
>> second item (as the first can't be a running sum) and see if that item
>> is the sum of some number of items before it that aren't part of a
>> previously detected running sum, and if you find such a case, mark it as
>> a running sum, and push everything that went into it up a level (and
>> things that made them up a level too).
>>
>> Note, this means that Cost of Shipping would only check if it was 'sum
>> of Cost of Item, and not include Cost of Assembly, as this is already
>> accounted for.
>>
>> There is a chance that you may miss-detect some running sums if the
>> numbers aren't accurate or just happen to add up, and for a one-off,
> 
> My numbers are only good for 4 digits. That means that when my best
> understanding is off by a "little" I can't be sure that I haven't
> made a mistake.

If by 4 digits, you mean something like order of a million, but only 
reported to thousands, so there is some round off, this adds a bit of 
complication to detecting possible running sums, but should be 
manageable. Basically the tolerance of a sum is based on how many terms 
that make it up. If you really mean 4 digits, so numbers in the 100 
thousands are reported to 100s, while numbers in the millions are 
reported to thousands, that sounds very strange. If they actually report 
numbers with 'significant digits' (non-zero) that might actually wrong, 
that is very strange to me, but again, could be handled by tolerancing 
the definition of matching to the various numbers in the sum.

> 
> There are three types of reports in financial statements: income, balance,
> and cash-flow. The numbers in all three reports have to be consistent,
> and that is a higher level of difficulty. Whatever I deduce from the
> income statement has to correspond to what I infer from the cash-flow
> statement and that isn't working out given the accuracy of the numbers
> I have.

If you really have 3 columns of numbers for the same category line 
items, that could provide a strong test to remove a lot of false running 
sums.
> 
>> just outputting that detection may be enough (or even do it by hand, as
>> the human brain is better at detecting suspicious conditions) for you to
>> manually adjust things.
>>
>> If you really need to do it programmatically, you can add back tracking
>> where you systematically undo marking things as possible running sums
>> until you get to a suitable result.
> 
> That is what the brute force method is doing.
>>

The difference is that if you do a bit of the work to decide which terms 
might be running sums (and thus mask off their component parts) you 
greatly break down the combitorial explosion.

Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Looking for simple brute force solution root <NoEMail@home.org> - 2018-01-03 23:18 +0000
  Re: Looking for simple brute force solution fir <profesor.fir@gmail.com> - 2018-01-03 16:49 -0800
    Re: Looking for simple brute force solution fir <profesor.fir@gmail.com> - 2018-01-03 17:11 -0800
      Re: Looking for simple brute force solution root <NoEMail@home.org> - 2018-01-04 10:14 +0000
        Re: Looking for simple brute force solution Richard Damon <Richard@Damon-Family.org> - 2018-01-04 10:52 -0500
          Re: Looking for simple brute force solution root <NoEMail@home.org> - 2018-01-04 16:46 +0000
            Re: Looking for simple brute force solution Richard Damon <Richard@Damon-Family.org> - 2018-01-04 12:37 -0500
  Re: Looking for simple brute force solution Richard Damon <Richard@Damon-Family.org> - 2018-01-03 21:28 -0500
    Re: Looking for simple brute force solution root <NoEMail@home.org> - 2018-01-04 09:42 +0000
      Re: Looking for simple brute force solution Richard Damon <Richard@Damon-Family.org> - 2018-01-04 10:16 -0500
        Re: Looking for simple brute force solution root <NoEMail@home.org> - 2018-01-04 17:26 +0000
          Re: Looking for simple brute force solution root <NoEMail@home.org> - 2018-01-04 21:19 +0000
  Re: Looking for simple brute force solution Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-01-04 02:29 +0000
    Re: Looking for simple brute force solution root <NoEMail@home.org> - 2018-01-04 09:55 +0000
      Re: Looking for simple brute force solution Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-01-04 14:29 +0000
        Re: Looking for simple brute force solution root <NoEMail@home.org> - 2018-01-04 16:55 +0000
          Re: Looking for simple brute force solution Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-01-04 20:36 +0000
      Re: Looking for simple brute force solution Robert Wessel <robertwessel2@yahoo.com> - 2018-01-04 12:03 -0600
        Re: Looking for simple brute force solution root <NoEMail@home.org> - 2018-01-04 21:28 +0000
          Re: Looking for simple brute force solution root <NoEMail@home.org> - 2018-01-04 21:50 +0000
            Re: Looking for simple brute force solution root <NoEMail@home.org> - 2018-01-04 23:06 +0000
            Re: Looking for simple brute force solution Richard Damon <Richard@Damon-Family.org> - 2018-01-04 21:35 -0500
              Re: Looking for simple brute force solution root <NoEMail@home.org> - 2018-01-05 05:59 +0000
                Re: Looking for simple brute force solution root <NoEMail@home.org> - 2018-01-05 16:48 +0000
                Re: Looking for simple brute force solution Richard Damon <Richard@Damon-Family.org> - 2018-01-06 08:50 -0500
                Re: Looking for simple brute force solution root <NoEMail@home.org> - 2018-01-06 16:47 +0000

csiph-web