Re: code128.py

Hi Klaas,

I think this new case and the case 12

> 12: START_B b b b b 1 2 3 4 5 STOP(11) --> START_B b b b b 1 2 3 4 5
> STOP(11)
> Here we could make a win if we can convert to:
>  START_B b b b b 1 TO_C 23 45 STOP(10)

are both examples of needing the transformation to be delayed by 1 so that they 
can continue to a point where we don't have to convert back to the original 
code. I think you are trying to do a more global optimization and that this is 
coding to C in reverse order.

I think we have to delay implementing the calculation of the C savings until we 
know the end conditions. So for any sequence of c codes we can have 2 ways 
(forward and reverse) to convert to a TO_C sequence; I think the problematic 
case is when forward ends like

cc c END

where END = STOP; if END was TO_A or TO_B we could still do the forward change ie

b b b c c c c c TO_B --> b b b TO_C cc cc TO_B c b

since all c inputs can be coded in A or B.


In the special cases we could calculate the reverse case and see if it is 
better. This makes the algorithm fairly complex. Is the gain worth it for this 
special case?

I'll try and take a look soon.


On 11/01/2016 13:43, Klaas Feenstra wrote:
> A new testcase:
> START_B b b b b 1 2 3 4 5 6 7 STOP(13)  has to be converted to
> START_B b b b b 1 TO_C 23 45 67 STOP(11)
>
> With actual code this will be converted to:
> START_B b b b b TO_C 12 34 56 TO_B 7 STOP(12)
>
> On Mon, Jan 11, 2016 at 2:36 PM, Klaas Feenstra <[email protected]> wrote:
>
>> Hi Robin,
>>
...........

-- 
Robin Becker