Closed orlitzky closed 2 years ago
Uh, a branch please?
John, L-functions question here...
For the first doctest, the PARI implementation (only available for real input) gives a different answer at 0:
sage: chi = DirichletGroup(5)[2]
sage: chi.lfunction().hardy(0)
0.793597201093544
EDIT
but Pari doc of "lfunhardy" says this gives a "Variant of the Hardy Z-function"
For the second doctest, the values are indeed zeroes, according to pari :
sage: chi = DirichletGroup(5)[1]
sage: f = chi.lfunction()
sage: f(1/2+6.18357819545086*I)
2.61452836816118e-15 + 6.48370608217824e-15*I
sage: f(1/2+8.45722917442320*I)
3.51419504210656e-14 - 3.69407271406328e-14*I
sage: f(1/2-4.13290370521286*I)
-4.69010768657543e-15 - 8.53389710587884e-15*I
EDIT
But that doc says that "L.find_zeros_via_N(3)" is supposed to find 3 zeroes, ignoring negative ones !
Replying to @mkoeppe:
Uh, a branch please?
I hacked together the minimal changes needed to get this to compile (bonus: it doesn't crash), but all of the patches in the description should be viewed with great suspicion. It will take some more time to sort out the right things to do here.
Replying to @fchapoton:
EDIT
But that doc says that "L.find_zeros_via_N(3)" is supposed to find 3 zeroes, ignoring negative ones !
There used to be a parameter called do_negative
that made it look for zeros with a negative imaginary part, but the new libLfunction computes do_negative
on its own:
bool do_negative=is_complex();
...
template <class ttype>
bool L_function <ttype>::
is_complex(){
if(my_verbose>2) cout << "# start is_complex()" << endl;
bool do_negative=false;
int n=0;
if(what_type_L!=-1) //if not the zeta function, check if self dual. If so, do_negative stays false
do{
n++;
if(abs(imag(Complex(dirichlet_coefficient[n])))>.00001){
do_negative=true;
if(my_verbose>2) cout << "# is_complex: Dirichlet co\
eff " << n << " " << setprecision(DIGITS) << dirichlet_coefficient[n] << endl;
}
}while(n<number_of_dirichlet_coefficients&&!do_negative);
if(my_verbose>2) cout << "# is_complex() = " << do_negative<\
< endl;
return do_negative;
}
So maybe it's just the documentation that needs to be updated. I don't know what self-dual means, or what it's ultimately checking to make that decision in this case.
FWIW, here is my reading of this code: If all of the coefficients of the Dirichlet series are real (up to a tolerance of .00001
), then the conjugate of any root is also a root. (This is what "self-dual" must mean.) We do not need to look for roots below the real axis in this case (because they are conjugates of roots that are above the real axis), so do_negative
is set to False
. Otherwise, do_negative
is set to True
.
Replying to @orlitzky:
Replying to @fchapoton: ... So maybe it's just the documentation that needs to be updated. I don't know what self-dual means, or what it's ultimately checking to make that decision in this case.
Branch: public/lcalc_version_2
here is a first branch, just changing version, checksums and lcalc_sage.h
New commits:
61be05d | first steps towards lcalc 2.0.0 |
should we remove all the old patches ?
Replying to @fchapoton:
should we remove all the old patches ?
Yep, all patches are obsolete. The spkg-install.in should now be,
sdh_configure --with-pari
sdh_make_install
and we can add an spkg-check.in containing,
sdh_make_check
Branch pushed to git repo; I updated commit sha1. New commits:
7f68936 | lcalc 2.0.0 removing all patches |
Branch pushed to git repo; I updated commit sha1. New commits:
ef80bc3 | update installation scripts |
Branch pushed to git repo; I updated commit sha1. New commits:
76226d7 | lcalc 2.0.0 no dependency to mpfr |
should we "cd src" in spkg-install ?
I have not managed to install so far with the current branch, "sage -i lcalc" complains as follows
[lcalc-2.0.0] Uninstalling 'lcalc' with legacy uninstaller
[lcalc-2.0.0] Package 'lcalc' is currently not installed
[lcalc-2.0.0] Now building lcalc, example programs and the shared library...
[lcalc-2.0.0] Building lcalc-2.0.0
[lcalc-2.0.0] make[3]: *** No targets specified and no makefile found. Stop.
I don't understand anything about the build system, so it's likely that this is noise (in which case I apologize), but dimpase says not to use "sage -i":
we are trying to switch to a sane building scheme:
./bootstrap
./configure
make build
make pynormaliz
sage -i is an old hack noone should use...
So maybe you are supposed to try "make lcalc" ?
Branch pushed to git repo; I updated commit sha1. New commits:
aa2bb03 | Trac #32037: update spkg-configure.m4 for lcalc-2.0.0. |
Should .m4 files mix tabs and spaces?
Branch pushed to git repo; I updated commit sha1. New commits:
849de4b | Trac #32037: fixup: kill tabs in build/pkgs/lcalc/spkg-configure.m4. |
Replying to @slel:
Should .m4 files mix tabs and spaces?
According to me, no. According to emacs, at every opportunity.
Using "make lcalc", I am still not able to build, with or without "cd src".
Complains of missing makefile, as in comment:17
Replying to @fchapoton:
Using "make lcalc", I am still not able to build, with or without "cd src".
Complains of missing makefile, as in comment:17
I think you have to get rid of spkg-build.in
, too.
Branch pushed to git repo; I updated commit sha1. New commits:
7327388 | lcalc 2.0.0 towards a working make |
ok, now "make lcalc" starts doing something and stops at
[lcalc-2.0.0] Thread model: posix
[lcalc-2.0.0] gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)
...
[lcalc-2.0.0] checking for gengetopt... no
[lcalc-2.0.0] configure: error: GNU gengetopt is required
Description changed:
---
+++
@@ -2,6 +2,7 @@
There are a few issues that need to be addressed during the upgrade.
+0. The build requires GNU gengetopt, so we'll need a new gengetopt SPKG for lcalc to depend on. (It doesn't need to go in the DEPCHECK macro though, since it's a build-only dependency.)
1. The build system is now sane. This should make life easier in the long run, but means that spkg-* need to be rewritten. `./configure --with-pari` should suffice.
2. The lcalc spkg shouldn't depend on mpfr (I'm not sure why it ever did).
Well the good news is that it's supposed to do that, but the bad news is that we'll have to add another gengetopt SPKG for lcalc to depend on.
Dependencies: #32061
I posted a branch for review on #32061 to add the missing dependency.
Changed branch from public/lcalc_version_2 to u/mjo/ticket/32037
I figured out how to fix the build scripts... and then found a typo in the upstream configure.ac that I had to release a 2.0.1 to fix. I think this will actually work now.
Replying to @DaveWitteMorris:
FWIW, here is my reading of this code: If all of the coefficients of the Dirichlet series are real (up to a tolerance of
.00001
), then the conjugate of any root is also a root. (This is what "self-dual" must mean.) We do not need to look for roots below the real axis in this case (because they are conjugates of roots that are above the real axis), sodo_negative
is set toFalse
. Otherwise,do_negative
is set toTrue
.
These functions are supposed to "return the first n
zeros." That's vague, but scrutable if you're starting from the real axis and moving up: basically, the numbers (imaginary parts) it outputs get bigger. I guess when do_negative
is true, we output the first n
zeros in magnitude?
Description changed:
---
+++
@@ -1,4 +1,4 @@
-I've just tagged a 2.0.0 release of lcalc: https://gitlab.com/sagemath/lcalc/-/tags/2.0.0
+I've just tagged a 2.0.1 release of lcalc: https://gitlab.com/sagemath/lcalc/-/tags/2.0.1
There are a few issues that need to be addressed during the upgrade.
Branch pushed to git repo; I updated commit sha1. This was a forced push. Last 10 new commits:
f248552 | Trac #32061: add distro package information for GNU Gengetopt. |
37299ed | Trac #32061: add spkg-check.in for gengetopt. |
fd445a4 | first steps towards lcalc 2.0.0 |
62e2f2e | lcalc 2.0.0 removing all patches |
2658f0d | update installation scripts |
a09e5a1 | lcalc 2.0.0 no dependency to mpfr |
de1c43d | Trac #32037: update spkg-configure.m4 for lcalc-2.0.0. |
101ec5f | Trac #32037: have lcalc depend on gengetopt. |
24928e9 | Trac #32037: upgrade lcalc to v2.0.1. |
4d5fc58 | Trac #32037: fix build scripts for lcalc SPKG. |
Replying to @orlitzky:
Replying to @DaveWitteMorris:
... I guess when
do_negative
is true, we output the firstn
zeros in magnitude?
Yes, I'm pretty sure that is correct. For example, a comment introducing the find_zeros
function says "Finds zeros of L(1/2+It) or of L(1/2+It)*L(1/2-It) (depending on whether self dual or not)". (The second form will combine the zeros with negative imaginary into the ones with positive imaginary part.) And a comment in the code of the function says "in the self dual case we only count half the zeros with |t|<T".
Branch pushed to git repo; I updated commit sha1. New commits:
8d70dfd | Trac 32037: fixup lcalc header name in sage/libs/lcalc/lcalc_sage.h. |
The new lcalc 2.0.3 has been released. Note in particular:
lcalc/L.h
find_zeros_via_N_v()
function was removed and replaced byfind_zeros()
In this ticket we upgrade to lcalc 2.0.3 and:
Depends on #32061 Depends on #31837
CC: @JohnCremona @antonio-rojas @kiwifb @dimpase
Component: packages: standard
Author: Michael Orlitzky, Frédéric Chapoton
Branch:
cbb7908
Reviewer: Antonio Rojas, Dima Pasechnik
Issue created by migration from https://trac.sagemath.org/ticket/32037