> Pattern code for:
>> no., [...] year, week (3rd try)
>> ["1","0","8","1","a","no","i","(year)","j","(week)","w","w"]
>> Holding code:
>> ["4","1","8","1","a","52","i",2010,"j",51]
>>
>>
> Indeed, the predictions from the above example are very bizarre. I get
> 'no53(2011:48)'
> 'no54(2012:45)'
> 'no55(2013:42)'
> 'no56(2014:39)'
> and so on. That's presumably a bug unless there's some MFHD subtlety I
> can't get my head around. Perhaps David would be kind enough to chime in
> again on this one?
This might be a bug. There's only one level of enumeration but two levels of
date, so the code is creating one number per year. I have no idea how it's
picking the date of that one no. I'm guessing that the correct format should
be a continuous issue count that doesn't reset after every year, giving a
correct pattern of
'no53(2011:1)'
'no54(2011:2)'
...
>
> Pattern code for:
>> vol., year, week (5th try)
>> ["2","0","8","1","a","vol","i","(year)","j","(week)","w","w"]
>> Holding code:
>> ["4","1","8","1","a","10","i",2010,"j",52]
>>
>
>
> The above example exhibits similarly unexpected predictions as the one two
> examples higher, for which I'm soliciting David's help. I'm not sure what's
> happening at this time.
>
This is essentially the same as the previous example, except the issues are
labelled as "vol." rather than as "no." in the first case, and it fails for
the same reason.
