What "standard" are you referring to? If you're arguing for the simplest possible that would be strcmp() that numerically compares each corresponding byte in two arrays of bytes. That works only for English encoded in ASCII. Doesn't work at all well for German, never mind Chinese. Glib provides a localization-supporting UTF-8 function that does work for all languages, g_utf8_compare().
The C and C++ standard sort functions are designed so that programs can easily implement sorts that support the use-cases being addressed: They take a callback function that returns 0 if the two arguments are equal, an int < 0 if the first one goes first and an int > 0 if the second one does. strcmp() and g_utf8_compare do that because the standard sort functions were designed around strcmp() and g_utf8_compare was designed as a drop-in replacement for strcmp(). But string comparison on its own doesn't work for ordering transactions by the num field in GnuCash. GnuCash has an obvious use-case where the num field contains serial numbers. As noted earlier it has keybindings for retrieving the last-used serial number and incrementing or decrementing it. It follows that numeric sorting is appropriate when it can be established that the field contains numbers, and that's what the current ordering callback does as long as the numbers fit in an int (±2 billion or so). But not all users do that, and it's complicated by the ability to use the split's action field for the transaction number so that one can have different values in different registers. It's a free text field: The input isn't (and never has been) checked to make sure that it's all numeric. The current ordering function behaves oddly in that case and a user brought that to our attention in https://github.com/Gnucash/gnucash/pull/983. That means that a hybrid approach is called for. It's pretty easily implemented, too. This is the evolution of GnuCash in action. Regards, John Ralls > On Jun 11, 2021, at 10:09 PM, flywire <flywi...@gmail.com> wrote: > > The question is about custom changes to the sorting algorithm (with an > undocumented feature) and I'm questioning actually using a *non-standard* > sorting algorithm. Using the 80:20 rule most of the benefit of the system > comes from a small part of it. How can GnuCash evolve if custom code is > carried forward forever? That may well involve a major change and as Will > pointed out it is easy to add leading zeros. > > ----- > > "The Reserve Bank of Australia (RBA) is Australia's central bank... It does > this by conducting monetary policy" https://www.rba.gov.au/about-rba/ > >> https://www.rba.gov.au/speeches/2020/sp-ag-2020-06-03.html#there-are-a-number-of-policy-implications >> https://www.rba.gov.au/speeches/2020/images/sp-ag-2020-06-03-graph01.gif >> "Is this suggesting the end of the cheque system? I think it may well >> be..." > > > > -- > Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html > _______________________________________________ > gnucash-user mailing list > gnucash-user@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. _______________________________________________ gnucash-user mailing list gnucash-user@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.
