[GNC] Transaction ordering on num field

[John Ralls]

What about 999a and 999b? Those currently evaluate equal so that the sort routine will proceed to the next criterion, date_entered.

ISTM this would be something of a special case where preserving numerical ordering makes sense only in the case of leading numbers followed by a very few alpha characters. The example of 999a vs. 1000a is simple, but what to do with 10xr79b2 vs 9z54rq8e? I think most people would agree that that should be sorted lexically so that 10xr79b2 comes before 9z54rq8e. Such a scheme would allow the possibility of 9999abcd and 100000xyz and it's not possible to tell which rule should govern when looking at that pair in isolation. Collating algorithms work pairwise. Worse, your comment about auto numbering suggests that you might want to mix the styles so even running through all of the transactions to determine a pattern would produce a result the user might not like.

Good point about case sensitivity. I can't think of any good argument for sorting to be case sensitive. Can anyone else?

The proposed change wouldn't affect auto-numbering, only sort.

Regards,
John Ralls

> On Jun 8, 2021, at 2:20 PM, David Carlson <david.carlson.417 at gmail.com> wrote:
> 
> I would prefer 999a to sort before 1000a and character sorts to be case insensitive, but I do not depend on that for any purpose.
> 
> I do, however, depend on the auto numbering function ignoring strings containing non-numeric characters as it currently does, so it currently only increments numbers and still numbers the next check correctly if I use non-numeric characters in transactions that do not represent checks.
> 
> Those are my preferences!
> 
> On Tue, Jun 8, 2021 at 1:37 PM John Ralls <jralls at ceridwen.us> wrote:
> Really the effective num field because of the split-action option, but anyway...
> 
> The submitter of PR#963 complained that sorting on the num field doesn't work right if the value is bigger than an int can hold; that's 9 digits. His knowledge of C wasn't quite up to the task of fixing it, but I've fixed his implementation and have it ready to push for GnuCash 4.6.
> 
> So far so good, but it changes the order of transactions when the num field isn't all numeric and I want to know if the change will cause trouble for anyone.
> 
> The current behavior is that a string beginning with a letter will have a sort value of 0 and one starting with a number will have a value equal to the numbers up to the first non-number character, so for example 12ab34 will have a sort value of 12, up to ±(10^10 - 1). "abc" and "def" will sort equally so the compare would fall through to the next criterion; "abc" would sort between "-12ab34" and "12ab34".
> 
> The new way is that if both strings are all numbers and there are fewer than 19 characters in each then the sort values will be their numeric values and the comparison will be numeric, so e.g. 2 sorts before 10. If those conditions aren't true then the two values will be string-compared, meaning a lexical sort: A very large number beginning with 2 will sort before a shorter number beginning with 3; "abc" will sort before "def" but after both "123" and "-123" because 1 and - sort before a. That's for an English locale; in order to accommodate UTF-8 strings the collation of the current locale.
> 
> Will that break anyone's carefully-crafted transaction ordering?
> 
> Regards,
> John Ralls
> 
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
> 
> 
> -- 
> David Carlson