- CLN-list - ginac.de

Testing CLN on MSVC
by Richard B. Kreckel 29 Aug '26

29 Aug '26

Hi, If anyone is interested in that configuration, please clone CLN from git, read INSTALL.windows, then check out 0562f5d42f64, and report back to this list how it works (make check) what exactly they did and what their environment was. We've had a self-contradictory AI-generated problem report and "solution description" here: https://codeberg.org/ginac/cln/issues/1 We do appreciate if people are being helpful and let AI generate problem reports and solutions. But we also expect the people commanding the AI to turn the AI results into concise bug reports and, if possible, patches. Thanks. Happy hacking, -richy. -- Richard B. Kreckel <https://in.terlu.de/~kreckel/>

2 3

Primary CLN repo moved to Codeberg.org
by Richard B. Kreckel 17 Feb '26

17 Feb '26

Hi! TL;DR: If you have cloned the CLN git repository, please do: $ git remote set-url origin https://codeberg.org/ginac/cln.git We have decided to move the primary CLN git repo to a modern hosted forge platform with most of the usual bells and whistles supporting fork-and-pull request workflows, issue tracker, CI, etc: <https://codeberg.org/ginac/cln> Codeberg e.V. is a Berlin-based non-profit organization dedicated to build and maintain supporting infrastructure for the creation, collection, dissemination, and archiving of Free and Open Source Software. Their platform runs the open source Forgejo software. For now, the web site <https://www.ginac.de/CLN/> and this mailing list will remain as is. Happy hacking! -richy. -- Richard B. Kreckel <https://in.terlu.de/~kreckel/>

1 0

Integer hash collision
by Florian Lorkowski 28 Nov '25

28 Nov '25

Dear Bruno and Richard, I encountered an issue with the way CLN computes hashes of small integers. The following test program computes the hashes of the integers 0-49: > #include <iostream> > #include <cln/integer.h> > > int main(int argc, char** args) { > for(int i = 0; i < 50; i++) > std::cout << "hash(" << i << ") = " << > cln::equal_hashcode(cln::cl_I(i)) << std::endl; > return 0; > } The output is > hash(0) = 0 > hash(1) = 65 > hash(2) = 66 > hash(3) = 98 > hash(4) = 67 > hash(5) = 83 > hash(6) = 99 > hash(7) = 115 > hash(8) = 68 > hash(9) = 76 > hash(10) = 84 > hash(11) = 92 > hash(12) = 100 > hash(13) = 108 > hash(14) = 116 > hash(15) = 124 > hash(16) = 69 > hash(17) = 73 > hash(18) = 77 > hash(19) = 81 > hash(20) = 85 > hash(21) = 89 > hash(22) = 93 > hash(23) = 97 > hash(24) = 101 > hash(25) = 105 > hash(26) = 109 > hash(27) = 113 > hash(28) = 117 > hash(29) = 121 > hash(30) = 125 > hash(31) = 129 > hash(32) = 70 > hash(33) = 72 > hash(34) = 74 > hash(35) = 76 > hash(36) = 78 > hash(37) = 80 > hash(38) = 82 > hash(39) = 84 > hash(40) = 86 > hash(41) = 88 > hash(42) = 90 > hash(43) = 92 > hash(44) = 94 > hash(45) = 96 > hash(46) = 98 > hash(47) = 100 > hash(48) = 102 > hash(49) = 104 Already in this range, there are several hash collisions: hash(9) = hash(35) hash(3) = hash(46) hash(10) = hash(39) hash(11) = hash(43) hash(12) = hash(47) Hash collisions should be extremely rare. The fact that they happen for such simple examples seems concerning to me. This is a problem for programs that compare hashes to check complicated expressions for equality, as expressions might appear equal despite having different integer coefficients inside them. The issue is that small integers also yield small hashes. This is incorrect behaviour for a hash function, which should return values uniformly distributed in its output range, in this case [0,2^32-1]. Larger integers sometimes give appropriate hashes, but not always, e.g.: hash(1234) = 536871000 hash(2000) = 136 The problem also affects rational numbers, whose hashes are just the difference of the hashes between their numerators and denominators, e.g.: hash(3/4) = hash(7/10) hash(12/13) = hash(25/27) I believe this is a bug in the computation of integer hashes. Is there a reason to a custom implementation of this purpose, rather than a standard algorithm such as CRC32? Best regards Florian

3 3

Re: Integer hash collision
by Bruno Haible 27 Nov '25

27 Nov '25

Florian Lorkowski wrote: > We were working on an algorithm that caches composite objects in GiNaC > by their hash value. We will implement a system to handle hash > collisions. You don't need to "implement a system to handle hash collisions". You can use the hash tables defined in cln/src/base/hash/{cl_hash.h,cl_hash1.h,cl_hash2.h}. Or, if you prefer the C++ Standard Library, I'm sure it has something for that use-case as well. Bruno

1 0

Issues with modern compilers?
by David van der Spoel 20 Sep '25

20 Sep '25

Hi, I'm trying to compile my software that optionally uses CLN, but it seems that some constructs in the CLN library are offensive to the C++17 standard, for instance: - mixing of class and struct for the same object: In file included from /Users/spoel/tools/include/cln/cln.h:27: /Users/spoel/tools/include/cln/string.h:28:9: error: class 'cl_string' was previously declared as a struct; this is valid, but may result in linker errors under the Microsoft C++ ABI [-Werror,-Wmismatched-tags] 28 | friend class cl_string; | ^ /Users/spoel/tools/include/cln/string.h:13:8: note: previous use is here 13 | struct cl_string; | ^ - invalid void * casts: In file included from /Users/spoel/tools/include/cln/cln.h:110: /Users/spoel/tools/include/cln/GV_complex.h:49:15: error: cast from 'void (*)(std::ostream &, const cl_print_flags &, const cl_N &)' (aka 'void (*)(basic_ostream<char> &, const cln::cl_print_flags &, const cln::cl_N &)') to 'void (*)(std::ostream &, const cl_print_flags &, const cl_number &)' (aka 'void (*)(basic_ostream<char> &, const cln::cl_print_flags &, const cln::cl_number &)') converts to incompatible function type [-Werror,-Wcast-function-type-mismatch] 49 | (void (*) (std::ostream&, const cl_print_flags&, const cl_number&)) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 50 | (void (*) (std::ostream&, const cl_print_flags&, const cl_N&)) | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 51 | &print_complex, | ~~~~~~~~~~~~~~ Unless I am doing something wrong, it seems these issues should be fixed, and I would be happy to help update the code by sending a patch. It would be even easier if the code was hosted on github but that is another step of course. -- David van der Spoel, Ph.D., Professor of Computational Molecular Biophysics Uppsala University. http://virtualchemistry.org

2 2

Upgrade of mailing list software
by Richard B. Kreckel 04 Jul '25

04 Jul '25

Greetings, due to obsolescence reasons, we have migrated this mailing list from GNU Mailman 2 to Mailman 3. All list memberships have (hopefully) been retained, so you should be able to continue using this list as before. All old list passwords, however, are gone. This also means no more monthly membership and password reminders. If you wish to manage your subscriptions using a web interface, you need to head to: https://lists.ginac.de/ and create an account ("Sign Up") using the same email address with which you are subscribed to this list (there will be a verification step for that address). This is optional - you can also manage you subscription via email to the special "-request" or "-unsubscribe" list addresses. The footer of this mail should give an example. The new list archives are located here: https://lists.ginac.de/archives/list/cln-list@ginac.de/ and now provide a fulltext search feature. If you encounter any issues, please do not hesitate to contact us directly. -- Richard B. Kreckel <https://in.terlu.de/~kreckel/>

1 0

Issue about CLN installation
by Michele Dradi 16 Jan '24

16 Jan '24

Hello to everybody, I don't know if the CLN mail list can be used also as help forum, if this is not the case I'm sorry for this spam. I'm writing this email because I have encountered an error that I'm not able to solve when running the make command in the installation procedure of cln-1.3.6. I'm currently using macOS Sonoma 14.2.1 with M2. The problem is that when I run make I obtain the error base/low/cl_low_div.cc:13:8: error: declaration of 'divu_16_rest' in global scope conflicts with declaration with C language linkage uint16 divu_16_rest; ^ ./base/cl_low.h:447:21: note: declared with C language linkage here extern "C" uint16 divu_16_rest; // -> Rest r ^ base/low/cl_low_div.cc:104:8: error: declaration of 'divu_32_rest' in global scope conflicts with declaration with C language linkage uint32 divu_32_rest; ^ ./base/cl_low.h:597:21: note: declared with C language linkage here extern "C" uint32 divu_32_rest; // -> Rest r ^ base/low/cl_low_div.cc:210:8: error: declaration of 'divu_64_rest' in global scope conflicts with declaration with C language linkage uint64 divu_64_rest; ^ ./base/cl_low.h:987:21: note: declared with C language linkage here extern "C" uint64 divu_64_rest; // -> Rest r ^ 3 errors generated. make[1]: *** [base/low/cl_low_div.lo] Error 1 make: *** [all-recursive] Error 1 It seems that the installation is in conflict with my c++ compiler, that is gcc with version Apple clang version 15.0.0 (clang-1500.1.0.2.5) Target: arm64-apple-darwin23.2.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin Unfortunately, I don't know how to solve and install cln. Thanks to everybody, Michele Dradi

2 3

CLN defines macro As in global space
by Junges, J.S.L. (Sebastian) 23 Oct '23

23 Oct '23

Dear Richard, others, We, developers of the model checker Storm, are long-time users of CLN. Thanks for all your work. We recently got a bug message that boils down to a conflict between different libraries. In particular, CLN adds the Macro AS in include/cln/number.h in line 274. This macro is globally defined upon including CLN and uses conflicts, e.g., MLPACK. While we can work around this issue, we thought it may be possible to rename the macro to CL_AS or even _CL_AS. Best, Sebastian Junges

2 2

Re: [CLN-list] Error building cln on M1 Mac
by Bruno Haible 15 Aug '23

15 Aug '23

Ron Garret wrote: > I took the plunge and installed autoconf and all the other thing you need to build the git version, and that worked. > > So I guess the only issue is that the latest official release is a little behind. Good finding! Indeed, the fix was committed by Richard on 2021-11-04. Bruno

2 9

[PATCH] Add support for LoongArch
by Xiaotian Wu 01 Jun '23

01 Jun '23

--- include/cln/types.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/include/cln/types.h b/include/cln/types.h index 25284ff..d243865 100644 --- a/include/cln/types.h +++ b/include/cln/types.h @@ -47,7 +47,7 @@ #else #error "No 64 bit integer type?" #endif - #if (defined(__alpha__) || defined(__ia64__) || defined(__mips64__) || defined(__powerpc64__) || defined(__s390x__) || (defined(__sparc__) && defined(__arch64__)) || (defined(__x86_64__) || defined(_M_AMD64)) || defined(__aarch64__) || (defined(__riscv) && __riscv_xlen == 64) || defined(__e2k__)) + #if (defined(__alpha__) || defined(__ia64__) || defined(__mips64__) || defined(__powerpc64__) || defined(__s390x__) || (defined(__sparc__) && defined(__arch64__)) || (defined(__x86_64__) || defined(_M_AMD64)) || defined(__aarch64__) || (defined(__riscv) && __riscv_xlen == 64) || defined(__e2k__) || defined(__loongarch_lp64)) // 64 bit registers in hardware #define HAVE_FAST_LONGLONG #endif @@ -73,7 +73,7 @@ // Integer type used for counters. // Constraint: sizeof(uintC) >= sizeof(uintL) - #if (defined(HAVE_FAST_LONGLONG) && (defined(__alpha__) || defined(__ia64__) || defined(__powerpc64__) || defined(__s390x__) || (defined(__sparc__) && defined(__arch64__)) || defined(__x86_64__) || defined(__aarch64__) || defined(__mips64__) || (defined(__riscv) && __riscv_xlen == 64) || defined(__e2k__))) + #if (defined(HAVE_FAST_LONGLONG) && (defined(__alpha__) || defined(__ia64__) || defined(__powerpc64__) || defined(__s390x__) || (defined(__sparc__) && defined(__arch64__)) || defined(__x86_64__) || defined(__aarch64__) || defined(__mips64__) || (defined(__riscv) && __riscv_xlen == 64) || defined(__e2k__) || defined(__loongarch_lp64))) #define intCsize long_bitsize typedef long sintC; typedef unsigned long uintC; @@ -85,7 +85,7 @@ // Integer type used for lfloat exponents. // Constraint: sizeof(uintE) >= sizeof(uintC) - #if (defined(__alpha__) || defined(__ia64__) || defined(__powerpc64__) || defined(__s390x__) || (defined(__sparc__) && defined(__arch64__)) || defined(__x86_64__) || defined(__i386__) || defined(__mips__) || defined(__rs6000__) || defined(__aarch64__) || (defined(__riscv) && __riscv_xlen == 64) || defined(__e2k__)) + #if (defined(__alpha__) || defined(__ia64__) || defined(__powerpc64__) || defined(__s390x__) || (defined(__sparc__) && defined(__arch64__)) || defined(__x86_64__) || defined(__i386__) || defined(__mips__) || defined(__rs6000__) || defined(__aarch64__) || (defined(__riscv) && __riscv_xlen == 64) || defined(__e2k__) || defined(__loongarch_lp64)) #define intEsize 64 typedef sint64 sintE; typedef uint64 uintE; @@ -126,7 +126,7 @@ typedef int sintD; typedef unsigned int uintD; #else // we are not using GMP, so just guess something reasonable - #if (defined(HAVE_FAST_LONGLONG) && (defined(__alpha__) || defined(__ia64__) || defined(__powerpc64__) || (defined(__sparc__) && defined(__arch64__)) || defined(__s390x__) || defined(__x86_64__) || defined(__aarch64__) || defined(__mips64__) || (defined(__riscv) && __riscv_xlen == 64) || defined(__e2k__))) + #if (defined(HAVE_FAST_LONGLONG) && (defined(__alpha__) || defined(__ia64__) || defined(__powerpc64__) || (defined(__sparc__) && defined(__arch64__)) || defined(__s390x__) || defined(__x86_64__) || defined(__aarch64__) || defined(__mips64__) || (defined(__riscv) && __riscv_xlen == 64) || defined(__e2k__) || defined(__loongarch_lp64))) #define intDsize 64 typedef sint64 sintD; typedef uint64 uintD; -- 2.40.0

2 1