about check number heuristics
Ethy H. Brito
ethy.brito at inexo.com.br
Fri Jan 26 11:59:16 EST 2007
On Thu, 25 Jan 2007 10:00:54 -0500
Derek Atkins <warlord at MIT.EDU> wrote:
> >> Are you offering to code this and send in a patch? :-D
> > yes I am. In fact I am working on the idea reading the code to catch your
> > programing style and propose something that fits in.
> Cool! I look forward to your patch. :)
Here go my thoughts:
I think the "problem" has to be dealed at check number increment/decrement.
If this is done correctly, the import matching do not have to be smart
(a simple str[n]cmp will do the job as it is today)
Please correct me. I have no deep knowledge of GC innards.
Then I thought about a print function.
It may deal with some format string and parse whatever the user writes, formatting accordingly something like this:
1- print numbers against a (C like) pattern
c - alfabetic chars from A to Z
h - alfabetic chars from 0 to 9 and from A to F
d - alfabetic chars from 0 to 9
u - a user defined ASCII sequence (in any order) up to 36 chars
As examples printing decimal number 123 under the format string:
"dddddd" -> 000123
"dddcdddddd" -> 000A000123 (also number 123. "A" is equiv. to 0)
In this last example we have three groups:
the first with 3 digits
the secont: a single alphabetic char
the third: 6 digits
2- Each group of identical type will be inc/decremented separately
adding the carry bit from the group at its left
For instance the format string "ddd ccddd" will give us
"000 ZZ999" + 1 = "001 AA000"
(just for fun: don't have any ideia what "000 ZZ999" decimal number is)
3- Some flags may controls when strip leading zeroes from target or
to honor the carry from previous operations.
4- Overflows/wrapping are governed by each field length
Too complex? Any hard impacts on GC as it is now?
Comments please (if this deserves any!).
More information about the gnucash-devel