How can I change it to double precision?

Could you give some hints?
I installed sollya. The output is 156 bits so it should be accurate enough for double precision. But I am not very familiar with the other part of the functions in simd_math_prims.h.

If you want double precision, then I assume you want more than 24bits relative precision. Then, you need to use a polynomial with higher degree, and the computation will slowdown accordingly. Except if you are using vectorization this might not be worth it.
Anyway, if you want more detail about the use of Sollya, you may want to read the following blog post:
http://gallium.inria.fr/blog/fast-vectorizable-math-approx/

I still have a little confusion about the magic numbers.
First, the value of double number r is:

for a bit pattern of a number like:
|S|E_10, ... , E_0| M_51, M_50, ... , M_0|
Sorry for my poor c language. I thought you used some shift technique to get the integer part and fraction part of the number. Actually, you used the val4i = (int64_t) val4; to convert double to int_64t. It looks like floor() function (at least to positive numbers). It is a type cast and approximation rather than a reinterpret_cast.  And the fraction part is obtained by some shift and mask operations.

So the idea of the implementation of exp is the following : First, you reduce to compute the exponential in base 2 by dividing by log(2). Then, you compute the floor and use the resulting value as the floatting-point exponent of the result. Finally, you approximate the exponential of the fractional part with a well-chosen polynomial. The product of the two parts give the final result.
Now, how should we implement that in practice? We can of course not use the floor function of stdlib, because it is a library function, which will lead to failure of vectorization. Casting to int directly would perfom rounding to 0, which is not what we want for negative values of the input, and, moreover, we would need one subsequent costly int->float conversion to get the fractional part.
Instead, you convert the input value to a well-chosen fixed-point format (encoded in an integer), and use the high-order bits for the integral part of the input value and the low-order bits as the fractional part. Note that (in floats) exponents are shifted by 127, so that we will need to add 127 somehow to the exponent.
When using the right fixed-point format (i.e, 23 bits for the fractional part), we only need bitwise masking (no shifting) for synthesizing the two floats in interest:
- The integral bits correspond exactly to the exponent bits of the floating-point format. So we simply mask them to synthesize the first part of the result. Adding 127 to the exponent is performed before the masking by adding 127*2^23 =<PHONE_NUMBER>.
- In order to get the fractional part (plus 1, actually), we use the fractional part bits of the fixed point as a mantissa of a 0-exponent float. We then take care of this +1 when computing the right polynomial.
So, I hope you now understand the values of the magic constants:

12102203.1615614f is 2^23/log(2). Multiplying with this constant both transform the problem to finding the base 2 exponential and allow to prepare for the fixed-point format.
Adding<PHONE_NUMBER>.f correspond to adding 127 to the exponent of the first part of the result.
Casting to int32_t finishes the fixed-point conversion.

Hope this helps...
BTW, will you be able to use my double version of the functions, in the end?

Thank you very much for the detail of implementation.
I see the fixed point algorithm. You are constructing a binary fixed point number as  a bit pattern like:
0bxxxxxx.yyyyyyyyyyyy
by using some floating point algebra operations. And convert it to int32_t type.
The steps:

a = x/log(2);
b = a*(2<<23); // Now b as a float is actually an integer because M part of float a is 23bit.
c = b+ 1272<<23;  // compensate for bias. Now c as a float is still integer valued. Actually, it should be (a+127)(2<<23)
c = min(max(c, lower_limit),upper_limit)
d = (int32_t)c; // using vcvttpd2qq instruction, convert a float integer value to int32_t.

Now, d as an int32_t is an integer. d as a bit pattern is a fixed point binary number. The integer part of d as a bit pattern can be extracted by & operation.
I still have a problem, how the upper  and lower limit `` is derived?
double exp_cst1_d =<PHONE_NUMBER>227405312.;
double exp_cst2_d = 0.;

Anyway, the exp_d works and its accuracy of rtol = 1e-9 is satisfactory even in the whole range [-300, +200] of my parameter. But log_d do not accelerate well as single precision version.
Here is the output:
(base) [root@JD SIMD-math-prims]# make
g++ test_fun.cpp -o test_fun -Wall -W -O3 -std=c++11 -march=native
(base) [root@JD SIMD-math-prims]# ./test_fun
Sin functions:
--------------
Comparing the behavior of sinapprox against sinf, in the interval [-3.14159, 3.14159]:
Bias:                   -2.560597e-09
Mean absolute error:    3.676327e-06
RMS error:              4.109845e-06
Min difference:         -5.960464e-06
Max difference:         5.938113e-06

Comparing the behavior of sinapprox_d against sin, in the interval [-3.14159, 3.14159]:
Bias:                   1.151537e-12
Mean absolute error:    7.186951e-10
RMS error:              8.026634e-10
Min difference:         -1.145714e-09
Max difference:         1.145729e-09

Benchmarking sinf...    243.8M/s
Benchmarking sinapprox...    7876.9M/s
Benchmarking sin...    341.3M/s
Benchmarking sinapprox_d...    2694.7M/s

Cos functions:
--------------
Comparing the behavior of cosapprox against cosf, in the interval [-3.14159, 3.14159]:
Bias:                   5.895721e-06
Mean absolute error:    2.777401e-05
RMS error:              3.156854e-05
Min difference:         -4.571676e-05
Max difference:         4.577637e-05

Comparing the behavior of cosapprox_d against cos, in the interval [-3.14159, 3.14159]:
Bias:                   1.367417e-11
Mean absolute error:    7.584514e-11
RMS error:              8.525821e-11
Min difference:         -1.227697e-10
Max difference:         1.227682e-10

Benchmarking cosf...    262.6M/s
Benchmarking cosapprox...    9309.1M/s
Benchmarking cos...    379.3M/s
Benchmarking cosapprox_d...    2694.7M/s

Log functions:
--------------
Comparing the behavior of logapprox against logf, in the interval [1e-10, 10]:
Bias:                   7.545441e-08
Mean absolute error:    5.554401e-06
RMS error:              6.175767e-06
Min difference:         -8.821487e-06
Max difference:         8.940697e-06

Comparing the behavior of icsi_log against logf, in the interval [1e-10, 10]:
Bias:                   1.043380e-05
Mean absolute error:    1.756708e-04
RMS error:              2.058682e-04
Min difference:         -4.689693e-04
Max difference:         4.639626e-04

Comparing the behavior of logapprox_d against log, in the interval [1e-10, 10]:
Bias:                   -1.875015e-10
Mean absolute error:    2.895113e-09
RMS error:              3.218112e-09
Min difference:         -4.531327e-09
Max difference:         4.531155e-09

Benchmarking logf...    124.9M/s
Benchmarking icsi_log...    731.4M/s
Benchmarking logapprox...    4452.2M/s
Benchmarking log...    123.4M/s
Benchmarking logapprox_d...    307.5M/s

Exp functions:
--------------
Comparing the behavior of expapprox against expf, in the interval [-10, 10]:
Relative bias:                  -8.916760e-09
Mean relative error:            2.821630e-06
RMS relative error:             3.418452e-06
Min relative difference:        -8.690718e-06
Max relative difference:        8.117646e-06

Comparing the behavior of expapprox_d against exp, in the interval [-10, 10]:
Relative bias:                  -1.935681e-11
Mean relative error:            1.417697e-09
RMS relative error:             1.573945e-09
Min relative difference:        -2.218639e-09
Max relative difference:        2.218602e-09

Benchmarking expf...    131.3M/s
Benchmarking expapprox...    3413.3M/s
Benchmarking exp...    204.8M/s
Benchmarking expapprox_d...    1383.8M/s

(base) [root@JD SIMD-math-prims]# uname -a
Linux JD 3.10.0-957.el7.x86_64 #1 SMP Thu Nov 8 23:39:32 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
(base) [root@JD SIMD-math-prims]# lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                2
On-line CPU(s) list:   0,1
Thread(s) per core:    2
Core(s) per socket:    1
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 85
Model name:            Intel(R) Xeon(R) Gold 6146 CPU @ 3.20GHz
Stepping:              4
CPU MHz:               3192.500
BogoMIPS:              6385.00
Hypervisor vendor:     KVM
Virtualization type:   full
L1d cache:             32K
L1i cache:             32K
L2 cache:              4096K
L3 cache:              16384K
NUMA node0 CPU(s):     0,1
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch ibrs ibpb fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx avx512f avx512dq rdseed adx smap clflushopt clwb avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 arat spec_ctrl
(base) [root@JD SIMD-math-prims]# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/rh/devtoolset-8/root/usr/libexec/gcc/x86_64-redhat-linux/8/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,lto --prefix=/opt/rh/devtoolset-8/root/usr --mandir=/opt/rh/devtoolset-8/root/usr/share/man --infodir=/opt/rh/devtoolset-8/root/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --with-default-libstdcxx-abi=gcc4-compatible --enable-plugin --enable-initfini-array --with-isl=/builddir/build/BUILD/gcc-8.3.1-20190311/obj-x86_64-redhat-linux/isl-install --disable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix
gcc version 8.3.1 20190311 (Red Hat 8.3.1-3) (GCC)

(base) [root@JD SIMD-math-prims]# gcc -march=native -Q --help=target
The following options are target specific:
  -m128bit-long-double                  [enabled]
  -m16                                  [disabled]
  -m32                                  [disabled]
  -m3dnow                               [disabled]
  -m3dnowa                              [disabled]
  -m64                                  [enabled]
  -m80387                               [enabled]
  -m8bit-idiv                           [disabled]
  -m96bit-long-double                   [disabled]
  -mabi=                                sysv
  -mabm                                 [enabled]
  -maccumulate-outgoing-args            [disabled]
  -maddress-mode=                       long
  -madx                                 [enabled]
  -maes                                 [enabled]
  -malign-data=                         compat
  -malign-double                        [disabled]
  -malign-functions=                    0
  -malign-jumps=                        0
  -malign-loops=                        0
  -malign-stringops                     [enabled]
  -mandroid                             [disabled]
  -march=                               skylake-avx512
  -masm=                                att
  -mavx                                 [enabled]
  -mavx2                                [enabled]
  -mavx256-split-unaligned-load         [disabled]
  -mavx256-split-unaligned-store        [disabled]
  -mavx5124fmaps                        [disabled]
  -mavx5124vnniw                        [disabled]
  -mavx512bitalg                        [disabled]
  -mavx512bw                            [enabled]
  -mavx512cd                            [enabled]
  -mavx512dq                            [enabled]
  -mavx512er                            [disabled]
  -mavx512f                             [enabled]
  -mavx512ifma                          [disabled]
  -mavx512pf                            [disabled]
  -mavx512vbmi                          [disabled]
  -mavx512vbmi2                         [disabled]
  -mavx512vl                            [enabled]
  -mavx512vnni                          [disabled]
  -mavx512vpopcntdq                     [disabled]
  -mbionic                              [disabled]
  -mbmi                                 [enabled]
  -mbmi2                                [enabled]
  -mbranch-cost=<0,5>                   3
  -mcall-ms2sysv-xlogues                [disabled]
  -mcet
  -mcet-switch                          [disabled]
  -mcld                                 [disabled]
  -mclflushopt                          [enabled]
  -mclwb                                [enabled]
  -mclzero                              [disabled]
  -mcmodel=                             [default]
  -mcpu=
  -mcrc32                               [disabled]
  -mcx16                                [enabled]
  -mdispatch-scheduler                  [disabled]
  -mdump-tune-features                  [disabled]
  -mf16c                                [enabled]
  -mfancy-math-387                      [enabled]
  -mfentry                              [disabled]
  -mfma                                 [enabled]
  -mfma4                                [disabled]
  -mforce-drap                          [disabled]
  -mforce-indirect-call                 [disabled]
  -mfp-ret-in-387                       [enabled]
  -mfpmath=                             sse
  -mfsgsbase                            [enabled]
  -mfunction-return=                    keep
  -mfused-madd
  -mfxsr                                [enabled]
  -mgeneral-regs-only                   [disabled]
  -mgfni                                [disabled]
  -mglibc                               [enabled]
  -mhard-float                          [enabled]
  -mhle                                 [enabled]
  -miamcu                               [disabled]
  -mieee-fp                             [enabled]
  -mincoming-stack-boundary=            0
  -mindirect-branch-register            [disabled]
  -mindirect-branch=                    keep
  -minline-all-stringops                [disabled]
  -minline-stringops-dynamically        [disabled]
  -mintel-syntax
  -mlarge-data-threshold=<number>       65536
  -mlong-double-128                     [disabled]
  -mlong-double-64                      [disabled]
  -mlong-double-80                      [enabled]
  -mlwp                                 [disabled]
  -mlzcnt                               [enabled]
  -mmemcpy-strategy=
  -mmemset-strategy=
  -mmitigate-rop                        [disabled]
  -mmmx                                 [enabled]
  -mmovbe                               [enabled]
  -mmovdir64b                           [disabled]
  -mmovdiri                             [disabled]
  -mmpx                                 [disabled]
  -mms-bitfields                        [disabled]
  -mmusl                                [disabled]
  -mmwaitx                              [disabled]
  -mno-align-stringops                  [disabled]
  -mno-default                          [disabled]
  -mno-fancy-math-387                   [disabled]
  -mno-push-args                        [disabled]
  -mno-red-zone                         [disabled]
  -mno-sse4                             [disabled]
  -mnop-mcount                          [disabled]
  -momit-leaf-frame-pointer             [disabled]
  -mpc32                                [disabled]
  -mpc64                                [disabled]
  -mpc80                                [disabled]
  -mpclmul                              [enabled]
  -mpcommit                             [disabled]
  -mpconfig                             [disabled]
  -mpku                                 [disabled]
  -mpopcnt                              [enabled]
  -mprefer-avx128
  -mprefer-vector-width=                256
  -mpreferred-stack-boundary=           0
  -mprefetchwt1                         [disabled]
  -mprfchw                              [enabled]
  -mpush-args                           [enabled]
  -mrdpid                               [disabled]
  -mrdrnd                               [enabled]
  -mrdseed                              [enabled]
  -mrecip                               [disabled]
  -mrecip=
  -mrecord-mcount                       [disabled]
  -mred-zone                            [enabled]
  -mregparm=                            6
  -mrtd                                 [disabled]
  -mrtm                                 [enabled]
  -msahf                                [enabled]
  -msgx                                 [disabled]
  -msha                                 [disabled]
  -mshstk                               [disabled]
  -mskip-rax-setup                      [disabled]
  -msoft-float                          [disabled]
  -msse                                 [enabled]
  -msse2                                [enabled]
  -msse2avx                             [disabled]
  -msse3                                [enabled]
  -msse4                                [enabled]
  -msse4.1                              [enabled]
  -msse4.2                              [enabled]
  -msse4a                               [disabled]
  -msse5
  -msseregparm                          [disabled]
  -mssse3                               [enabled]
  -mstack-arg-probe                     [disabled]
  -mstack-protector-guard-offset=
  -mstack-protector-guard-reg=
  -mstack-protector-guard-symbol=
  -mstack-protector-guard=              tls
  -mstackrealign                        [disabled]
  -mstringop-strategy=                  [default]
  -mstv                                 [enabled]
  -mtbm                                 [disabled]
  -mtls-dialect=                        gnu
  -mtls-direct-seg-refs                 [enabled]
  -mtune-ctrl=
  -mtune=                               skylake-avx512
  -muclibc                              [disabled]
  -mvaes                                [disabled]
  -mveclibabi=                          [default]
  -mvect8-ret-in-mem                    [disabled]
  -mvpclmulqdq                          [disabled]
  -mvzeroupper                          [enabled]
  -mwbnoinvd                            [disabled]
  -mx32                                 [disabled]
  -mxop                                 [disabled]
  -mxsave                               [enabled]
  -mxsavec                              [enabled]
  -mxsaveopt                            [enabled]
  -mxsaves                              [disabled]

  Known assembler dialects (for use with the -masm= option):
    att intel

  Known ABIs (for use with the -mabi= option):
    ms sysv

  Known code models (for use with the -mcmodel= option):
    32 kernel large medium small

  Valid arguments to -mfpmath=:
    387 387+sse 387,sse both sse sse+387 sse,387

  Known indirect branch choices (for use with the -mindirect-branch=/-mfunction-return= options):
    keep thunk thunk-extern thunk-inline

  Known data alignment choices (for use with the -malign-data= option):
    abi cacheline compat

  Known vectorization library ABIs (for use with the -mveclibabi= option):
    acml svml

  Known address mode (for use with the -maddress-mode= option):
    long short

  Known preferred register vector length (to use with the -mprefer-vector-width= option)
    128 256 512 none

  Known stack protector guard (for use with the -mstack-protector-guard= option):
    global tls

  Valid arguments to -mstringop-strategy=:
    byte_loop libcall loop rep_4byte rep_8byte rep_byte unrolled_loop vector_loop

  Known TLS dialects (for use with the -mtls-dialect= option):
    gnu gnu2

I also tried to use estrin's scheme from sleef, it does not accelerate.

I just found that in order to obtain better performance, I need to use -mavx512f -mavx512dq option in GCC.
With godbolt.org, I confirm that zmmxx register are used with that option.
(base) [root@JD SIMD-math-prims]# g++ test_fun.cpp -o test_fun -Wall -W -O3 -std=c++11  -mavx512f -mavx512dq
(base) [root@JD SIMD-math-prims]# test_fun
-bash: test_fun: command not found
(base) [root@JD SIMD-math-prims]# ./test_fun
Sin functions:
--------------
Comparing the behavior of sinapprox against sinf, in the interval [-3.14159, 3.14159]:
Bias:                   -2.560597e-09
Mean absolute error:    3.676327e-06
RMS error:              4.109845e-06
Min difference:         -5.960464e-06
Max difference:         5.938113e-06

Comparing the behavior of sinapprox_d against sin, in the interval [-3.14159, 3.14159]:
Bias:                   1.151537e-12
Mean absolute error:    7.186951e-10
RMS error:              8.026634e-10
Min difference:         -1.145714e-09
Max difference:         1.145729e-09

Benchmarking sinf...    243.8M/s
Benchmarking sinapprox...    14628.6M/s
Benchmarking sin...    341.3M/s
Benchmarking sinapprox_d...    4876.2M/s

Cos functions:
--------------
Comparing the behavior of cosapprox against cosf, in the interval [-3.14159, 3.14159]:
Bias:                   5.895721e-06
Mean absolute error:    2.777401e-05
RMS error:              3.156854e-05
Min difference:         -4.571676e-05
Max difference:         4.577637e-05

Comparing the behavior of cosapprox_d against cos, in the interval [-3.14159, 3.14159]:
Bias:                   1.367417e-11
Mean absolute error:    7.584514e-11
RMS error:              8.525821e-11
Min difference:         -1.227697e-10
Max difference:         1.227682e-10

Benchmarking cosf...    262.6M/s
Benchmarking cosapprox...    17066.7M/s
Benchmarking cos...    379.3M/s
Benchmarking cosapprox_d...    4876.2M/s

Log functions:
--------------
Comparing the behavior of logapprox against logf, in the interval [1e-10, 10]:
Bias:                   7.545441e-08
Mean absolute error:    5.554401e-06
RMS error:              6.175767e-06
Min difference:         -8.821487e-06
Max difference:         8.940697e-06

Comparing the behavior of icsi_log against logf, in the interval [1e-10, 10]:
Bias:                   1.043380e-05
Mean absolute error:    1.756708e-04
RMS error:              2.058682e-04
Min difference:         -4.689693e-04
Max difference:         4.639626e-04

Comparing the behavior of logapprox_d against log, in the interval [1e-10, 10]:
Bias:                   -1.875015e-10
Mean absolute error:    2.895113e-09
RMS error:              3.218112e-09
Min difference:         -4.531327e-09
Max difference:         4.531155e-09

Benchmarking logf...    124.9M/s
Benchmarking icsi_log...    787.7M/s
Benchmarking logapprox...    7876.9M/s
Benchmarking log...    124.9M/s
Benchmarking logapprox_d...    1932.1M/s

Exp functions:
--------------
Comparing the behavior of expapprox against expf, in the interval [-10, 10]:
Relative bias:                  -8.916760e-09
Mean relative error:            2.821630e-06
RMS relative error:             3.418452e-06
Min relative difference:        -8.690718e-06
Max relative difference:        8.117646e-06

Comparing the behavior of expapprox_d against exp, in the interval [-10, 10]:
Relative bias:                  2.779902e-09
Mean relative error:            5.930965e-08
RMS relative error:             6.559258e-08
Min relative difference:        -9.237607e-08
Max relative difference:        9.237933e-08

Benchmarking expf...    129.6M/s
Benchmarking expapprox...    6023.5M/s
Benchmarking exp...    209.0M/s
Benchmarking expapprox_d...    2560.0M/s

I still have a problem, how the upper and lower limit `` is derived?
double exp_cst1_d =<PHONE_NUMBER>227405312.;
double exp_cst2_d = 0.;

These values are chosen to prevent overflow when synthesizing the exponent floating point number.

If the value is lower than 0, then the exponent is going to be lower than 0 (i.e., invalid).
If the value is larger than<PHONE_NUMBER>227405312 = 2^52*(2^11-1), then the exponent is going to be larger than 2047 (i.e., invalid)

Anyway, the exp_d works and its accuracy of rtol = 1e-9 is satisfactory even in the whole range
[-300, +200] of my parameter.

Good. BTW, if you want an extra burst of performance, you can remove these bounds checks, which actually take quite a bit of time.

I just found that in order to obtain better performance, I need to use -mavx512f -mavx512dq option in GCC.

That's interesting, because your gcc -march=native -Q --help=target seems to indicate that these flags are already activated...
Anyway, is there anything I can do now, or can I close the issue?

Comparing the behavior of expapprox_d against exp, in the interval [-10, 10]:
Relative bias:                  2.779902e-09
Mean relative error:            5.930965e-08
RMS relative error:             6.559258e-08
Min relative difference:        -9.237607e-08
Max relative difference:        9.237933e-08

Have you changed the implementation of expapprox_d? On my computer, the error seems much better.

I still have some problem. logapprox_d cannot be vectorized with avx2's 256 bit instructions.
g++ test_fun.cpp -o test_fun -Wall -W -O3 -std=c++11 -march=native -mprefer-vector-width=256 -fopt-info
/opt/rh/devtoolset-8/root/usr/include/c++/8/bits/stl_algobase.h:753:13: note: Loop 2 distributed: split to 0 loops and 1 library calls.
test_fun.cpp:138:3: note: loop vectorized
test_fun.cpp:136:3: note: loop vectorized
test_fun.cpp:126:3: note: loop vectorized
###   bench_fun_f(logapprox_d, 1000000L); is at line no. 128. Not vectorized.
test_fun.cpp:115:3: note: loop vectorized
test_fun.cpp:113:3: note: loop vectorized
test_fun.cpp:105:3: note: loop vectorized
test_fun.cpp:103:3: note: loop vectorized
/opt/rh/devtoolset-8/root/usr/include/c++/8/bits/random.tcc:409:42: note: loop vectorized
/opt/rh/devtoolset-8/root/usr/include/c++/8/bits/random.tcc:401:32: note: loop vectorized
test_fun.cpp:90:5: note: loop with 2 iterations completely unrolled (header execution count 7087540)

# test result
Comparing the behavior of logapprox_d against log, in the interval [1e-10, 10]:
Bias:                   -1.875015e-10
Mean absolute error:    2.895113e-09
RMS error:              3.218112e-09
Min difference:         -4.531327e-09
Max difference:         4.531155e-09

Benchmarking logf...    126.4M/s
Benchmarking icsi_log...    731.4M/s
Benchmarking logapprox...    4452.2M/s
Benchmarking log...    123.4M/s
Benchmarking logapprox_d...    308.4M/s

But I see there are a lot of ymm** register used in godbolt

With -mprefer-vector-width=512 option. gcc 8.3.1-3 works as expected.
(base) [root@JD SIMD-math-prims]# g++ test_fun.cpp -o test_fun -Wall -W -O3 -std=c++11 -march=native -mprefer-vector-width=512 -fopt-info
/opt/rh/devtoolset-8/root/usr/include/c++/8/bits/stl_algobase.h:753:13: note: Loop 2 distributed: split to 0 loops and 1 library calls.
test_fun.cpp:138:3: note: loop vectorized
test_fun.cpp:136:3: note: loop vectorized
test_fun.cpp:128:3: note: loop vectorized
test_fun.cpp:126:3: note: loop vectorized
test_fun.cpp:115:3: note: loop vectorized
test_fun.cpp:113:3: note: loop vectorized
test_fun.cpp:105:3: note: loop vectorized
test_fun.cpp:103:3: note: loop vectorized
/opt/rh/devtoolset-8/root/usr/include/c++/8/bits/random.tcc:409:42: note: loop vectorized
/opt/rh/devtoolset-8/root/usr/include/c++/8/bits/random.tcc:401:32: note: loop vectorized
/opt/rh/devtoolset-8/root/usr/include/c++/8/bits/random.tcc:409:42: note: loop with 3 iterations completely unrolled (header execution count 7087537)
test_fun.cpp:90:5: note: loop with 2 iterations completely unrolled (header execution count 7087540)

I just found it seems even 256bit version of vpsraq instruct is from avx512DQ or avx512VL.

I still have some problem. logapprox_d cannot be vectorized with avx2's 256 bit instructions.

It seems like godbolt did the vectorization, but the GCC you are using on your machine did not.

COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/rh/devtoolset-8/root/usr/libexec/gcc/x86_64-redhat-linux/8/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,lto --prefix=/opt/rh/devtoolset-8/root/usr --mandir=/opt/rh/devtoolset-8/root/usr/share/man --infodir=/opt/rh/devtoolset-8/root/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --with-default-libstdcxx-abi=gcc4-compatible --enable-plugin --enable-initfini-array --with-isl=/builddir/build/BUILD/gcc-8.3.1-20190311/obj-x86_64-redhat-linux/isl-install --disable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix
gcc version 8.3.1 20190311 (Red Hat 8.3.1-3) (GCC)

(base) [root@JD SIMD-math-prims]# g++ test_fun.cpp -o test_fun -Wall -W -O3 -std=c++11 -march=native -mprefer-vector-width=512 -mavx512dq -fopt-info
/opt/rh/devtoolset-8/root/usr/include/c++/8/bits/stl_algobase.h:753:13: note: Loop 2 distributed: split to 0 loops and 1 library calls.
test_fun.cpp:138:3: note: loop vectorized
test_fun.cpp:136:3: note: loop vectorized
test_fun.cpp:128:3: note: loop vectorized // vectorized!
test_fun.cpp:126:3: note: loop vectorized
test_fun.cpp:115:3: note: loop vectorized
test_fun.cpp:113:3: note: loop vectorized
test_fun.cpp:105:3: note: loop vectorized
test_fun.cpp:103:3: note: loop vectorized
/opt/rh/devtoolset-8/root/usr/include/c++/8/bits/random.tcc:409:42: note: loop vectorized
/opt/rh/devtoolset-8/root/usr/include/c++/8/bits/random.tcc:401:32: note: loop vectorized
/opt/rh/devtoolset-8/root/usr/include/c++/8/bits/random.tcc:409:42: note: loop with 3 iterations completely unrolled (header execution count 7087537)
test_fun.cpp:90:5: note: loop with 2 iterations completely unrolled (header execution count 7087540)
(base) [root@JD SIMD-math-prims]# g++ test_fun.cpp -o test_fun -Wall -W -O3 -std=c++11 -march=native -mprefer-vector-width=256 -mavx512dq -fopt-info
/opt/rh/devtoolset-8/root/usr/include/c++/8/bits/stl_algobase.h:753:13: note: Loop 2 distributed: split to 0 loops and 1 library calls.
test_fun.cpp:138:3: note: loop vectorized
test_fun.cpp:136:3: note: loop vectorized
test_fun.cpp:126:3: note: loop vectorized //line 128 is not vectorized.
test_fun.cpp:115:3: note: loop vectorized
test_fun.cpp:113:3: note: loop vectorized
test_fun.cpp:105:3: note: loop vectorized
test_fun.cpp:103:3: note: loop vectorized
/opt/rh/devtoolset-8/root/usr/include/c++/8/bits/random.tcc:409:42: note: loop vectorized
/opt/rh/devtoolset-8/root/usr/include/c++/8/bits/random.tcc:401:32: note: loop vectorized
test_fun.cpp:90:5: note: loop with 2 iterations completely unrolled (header execution count 7087540)

-v -Q --help=target -march=native output:

this is from godbolt using gcc 8.3.0

The following options are target specific:

  -m128bit-long-double        		[enabled]

  -m16                        		[disabled]

  -m32                        		[disabled]

  -m3dnow                     		[disabled]

  -m3dnowa                    		[disabled]

  -m64                        		[enabled]

  -m80387                     		[enabled]

  -m8bit-idiv                 		[disabled]

  -m96bit-long-double         		[disabled]

  -mabi=                      		sysv

  -mabm                       		[enabled]

  -maccumulate-outgoing-args  		[disabled]

  -maddress-mode=             		long

  -madx                       		[enabled]

  -maes                       		[enabled]

  -malign-data=               		compat

  -malign-double              		[disabled]

  -malign-functions=          		0

  -malign-jumps=              		0

  -malign-loops=              		0

  -malign-stringops           		[enabled]

  -mandroid                   		[disabled]

  -march=                     		skylake-avx512

  -masm=                      		intel

  -mavx                       		[enabled]

  -mavx2                      		[enabled]

  -mavx256-split-unaligned-load 	[disabled]

  -mavx256-split-unaligned-store 	[disabled]

  -mavx5124fmaps              		[disabled]

  -mavx5124vnniw              		[disabled]

  -mavx512bitalg              		[disabled]

  -mavx512bw                  		[enabled]

  -mavx512cd                  		[enabled]

  -mavx512dq                  		[enabled]

  -mavx512er                  		[disabled]

  -mavx512f                   		[enabled]

  -mavx512ifma                		[disabled]

  -mavx512pf                  		[disabled]

  -mavx512vbmi                		[disabled]

  -mavx512vbmi2               		[disabled]

  -mavx512vl                  		[enabled]

  -mavx512vnni                		[disabled]

  -mavx512vpopcntdq           		[disabled]

  -mbionic                    		[disabled]

  -mbmi                       		[enabled]

  -mbmi2                      		[enabled]

  -mbranch-cost=<0,5>         		3

  -mcall-ms2sysv-xlogues      		[disabled]

  -mcet-switch                		[disabled]

  -mcld                       		[disabled]

  -mclflushopt                		[enabled]

  -mclwb                      		[enabled]

  -mclzero                    		[disabled]

  -mcmodel=                   		[default]

  -mcpu=

  -mcrc32                     		[disabled]

  -mcx16                      		[enabled]

  -mdispatch-scheduler        		[disabled]

  -mdump-tune-features        		[disabled]

  -mf16c                      		[enabled]

  -mfancy-math-387            		[enabled]

  -mfentry                    		[disabled]

  -mfma                       		[enabled]

  -mfma4                      		[disabled]

  -mforce-drap                		[disabled]

  -mforce-indirect-call       		[disabled]

  -mfp-ret-in-387             		[enabled]

  -mfpmath=                   		sse

  -mfsgsbase                  		[enabled]

  -mfunction-return=          		keep

  -mfused-madd

  -mfxsr                      		[enabled]

  -mgeneral-regs-only         		[disabled]

  -mgfni                      		[disabled]

  -mglibc                     		[enabled]

  -mhard-float                		[enabled]

  -mhle                       		[enabled]

  -miamcu                     		[disabled]

  -mieee-fp                   		[disabled]

  -mincoming-stack-boundary=  		0

  -mindirect-branch-register  		[disabled]

  -mindirect-branch=          		keep

  -minline-all-stringops      		[disabled]

  -minline-stringops-dynamically 	[disabled]

  -mintel-syntax

  -mlarge-data-threshold=<number> 	65536

  -mlong-double-128           		[disabled]

  -mlong-double-64            		[disabled]

  -mlong-double-80            		[enabled]

  -mlwp                       		[disabled]

  -mlzcnt                     		[enabled]

  -mmemcpy-strategy=

  -mmemset-strategy=

  -mmitigate-rop              		[disabled]

  -mmmx                       		[enabled]

  -mmovbe                     		[enabled]

  -mmovdir64b                 		[disabled]

  -mmovdiri                   		[disabled]

  -mmpx                       		[disabled]

  -mms-bitfields              		[disabled]

  -mmusl                      		[disabled]

  -mmwaitx                    		[disabled]

  -mno-align-stringops        		[disabled]

  -mno-default                		[disabled]

  -mno-fancy-math-387         		[disabled]

  -mno-push-args              		[disabled]

  -mno-red-zone               		[disabled]

  -mno-sse4                   		[disabled]

  -mnop-mcount                		[disabled]

  -momit-leaf-frame-pointer   		[disabled]

  -mpc32                      		[disabled]

  -mpc64                      		[disabled]

  -mpc80                      		[disabled]

  -mpclmul                    		[enabled]

  -mpcommit                   		[disabled]

  -mpconfig                   		[disabled]

  -mpku                       		[enabled]

  -mpopcnt                    		[enabled]

  -mprefer-avx128

  -mprefer-vector-width=      		256

  -mpreferred-stack-boundary= 		0

  -mprefetchwt1               		[disabled]

  -mprfchw                    		[enabled]

  -mpush-args                 		[enabled]

  -mrdpid                     		[disabled]

  -mrdrnd                     		[enabled]

  -mrdseed                    		[enabled]

  -mrecip                     		[disabled]

  -mrecip=

  -mrecord-mcount             		[disabled]

  -mred-zone                  		[enabled]

  -mregparm=                  		6

  -mrtd                       		[disabled]

  -mrtm                       		[enabled]

  -msahf                      		[enabled]

  -msgx                       		[disabled]

  -msha                       		[disabled]

  -mshstk                     		[disabled]

  -mskip-rax-setup            		[disabled]

  -msoft-float                		[disabled]

  -msse                       		[enabled]

  -msse2                      		[enabled]

  -msse2avx                   		[disabled]

  -msse3                      		[enabled]

  -msse4                      		[enabled]

  -msse4.1                    		[enabled]

  -msse4.2                    		[enabled]

  -msse4a                     		[disabled]

  -msse5

  -msseregparm                		[disabled]

  -mssse3                     		[enabled]

  -mstack-arg-probe           		[disabled]

  -mstack-protector-guard-offset=

  -mstack-protector-guard-reg=

  -mstack-protector-guard-symbol=

  -mstack-protector-guard=    		tls

  -mstackrealign              		[disabled]

  -mstringop-strategy=        		[default]

  -mstv                       		[enabled]

  -mtbm                       		[disabled]

  -mtls-dialect=              		gnu

  -mtls-direct-seg-refs       		[enabled]

  -mtune-ctrl=

  -mtune=                     		skylake-avx512

  -muclibc                    		[disabled]

  -mvaes                      		[disabled]

  -mveclibabi=                		[default]

  -mvect8-ret-in-mem          		[disabled]

  -mvpclmulqdq                		[disabled]

  -mvzeroupper                		[enabled]

  -mwbnoinvd                  		[disabled]

  -mx32                       		[disabled]

  -mxop                       		[disabled]

  -mxsave                     		[enabled]

  -mxsavec                    		[enabled]

  -mxsaveopt                  		[enabled]

  -mxsaves                    		[enabled]

  Known assembler dialects (for use with the -masm= option):

    att intel

  Known ABIs (for use with the -mabi= option):

    ms sysv

  Known code models (for use with the -mcmodel= option):

    32 kernel large medium small

  Valid arguments to -mfpmath=:

    387 387+sse 387,sse both sse sse+387 sse,387

  Known indirect branch choices (for use with the -mindirect-branch=/-mfunction-return= options):

    keep thunk thunk-extern thunk-inline

  Known data alignment choices (for use with the -malign-data= option):

    abi cacheline compat

  Known vectorization library ABIs (for use with the -mveclibabi= option):

    acml svml

  Known address mode (for use with the -maddress-mode= option):

    long short

  Known preferred register vector length (to use with the -mprefer-vector-width= option)

    128 256 512 none

  Known stack protector guard (for use with the -mstack-protector-guard= option):

    global tls

  Valid arguments to -mstringop-strategy=:

    byte_loop libcall loop rep_4byte rep_8byte rep_byte unrolled_loop

    vector_loop

  Known TLS dialects (for use with the -mtls-dialect= option):

    gnu gnu2

Using built-in specs.

COLLECT_GCC=/opt/compiler-explorer/gcc-8.3.0/bin/gcc

Target: x86_64-linux-gnu

Configured with: ../gcc-8.3.0/configure --prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap --enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --enable-clocale=gnu --enable-languages=c,c++,fortran,ada --enable-ld=yes --enable-gold=yes --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto --enable-plugins --enable-threads=posix --with-pkgversion=Compiler-Explorer-Build

Thread model: posix

gcc version 8.3.0 (Compiler-Explorer-Build)

COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' './output.s' '-masm=intel' '-S' '-v' '-O3' '-ffast-math' '-fopenmp' '-march=native' '-Q' '--help=target' '-pthread'

 /opt/compiler-explorer/gcc-8.3.0/bin/../libexec/gcc/x86_64-linux-gnu/8.3.0/cc1 -v -imultiarch x86_64-linux-gnu -iprefix /opt/compiler-explorer/gcc-8.3.0/bin/../lib/gcc/x86_64-linux-gnu/8.3.0/ -D_REENTRANT help-dummy -march=skylake-avx512 -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mno-sgx -mbmi2 -mno-pconfig -mno-wbnoinvd -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mrtm -mhle -mrdrnd -mf16c -mfsgsbase -mrdseed -mprfchw -madx -mfxsr -mxsave -mxsaveopt -mavx512f -mno-avx512er -mavx512cd -mno-avx512pf -mno-prefetchwt1 -mclflushopt -mxsavec -mxsaves -mavx512dq -mavx512bw -mavx512vl -mno-avx512ifma -mno-avx512vbmi -mno-avx5124fmaps -mno-avx5124vnniw -mclwb -mno-mwaitx -mno-clzero -mpku -mno-rdpid -mno-gfni -mno-shstk -mno-avx512vbmi2 -mno-avx512vnni -mno-vaes -mno-vpclmulqdq -mno-avx512bitalg -mno-movdiri -mno-movdir64b --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=33792 -mtune=skylake-avx512 -dumpbase help-dummy -masm=intel -auxbase-strip ./output.s -g -O3 -version -fdiagnostics-color=always -ffast-math -fopenmp --help=target -o ./output.s

GNU C17 (Compiler-Explorer-Build) version 8.3.0 (x86_64-linux-gnu)

	compiled by GNU C version 7.3.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

Compiler returned: 0

This is from my vps

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/rh/devtoolset-8/root/usr/libexec/gcc/x86_64-redhat-linux/8/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,lto --prefix=/opt/rh/devtoolset-8/root/usr --mandir=/opt/rh/devtoolset-8/root/usr/share/man --infodir=/opt/rh/devtoolset-8/root/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --with-default-libstdcxx-abi=gcc4-compatible --enable-plugin --enable-initfini-array --with-isl=/builddir/build/BUILD/gcc-8.3.1-20190311/obj-x86_64-redhat-linux/isl-install --disable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix
gcc version 8.3.1 20190311 (Red Hat 8.3.1-3) (GCC)
COLLECT_GCC_OPTIONS='-march=native' '-Q' '--help=target' '-v'
 /opt/rh/devtoolset-8/root/usr/libexec/gcc/x86_64-redhat-linux/8/cc1 -v help-dummy -march=skylake-avx512 -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mno-sgx -mbmi2 -mno-pconfig -mno-wbnoinvd -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mrtm -mhle -mrdrnd -mf16c -mfsgsbase -mrdseed -mprfchw -madx -mfxsr -mxsave -mxsaveopt -mavx512f -mno-avx512er -mavx512cd -mno-avx512pf -mno-prefetchwt1 -mclflushopt -mxsavec -mno-xsaves -mavx512dq -mavx512bw -mavx512vl -mno-avx512ifma -mno-avx512vbmi -mno-avx5124fmaps -mno-avx5124vnniw -mclwb -mno-mwaitx -mno-clzero -mno-pku -mno-rdpid -mno-gfni -mno-shstk -mno-avx512vbmi2 -mno-avx512vnni -mno-vaes -mno-vpclmulqdq -mno-avx512bitalg -mno-movdiri -mno-movdir64b --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=16384 -mtune=skylake-avx512 -dumpbase help-dummy -auxbase help-dummy -version --help=target -o /tmp/cc3URSRH.s
The following options are target specific:
  -m128bit-long-double                  [enabled]
  -m16                                  [disabled]
  -m32                                  [disabled]
  -m3dnow                               [disabled]
  -m3dnowa                              [disabled]
  -m64                                  [enabled]
  -m80387                               [enabled]
  -m8bit-idiv                           [disabled]
  -m96bit-long-double                   [disabled]
  -mabi=                                sysv
  -mabm                                 [enabled]
  -maccumulate-outgoing-args            [disabled]
  -maddress-mode=                       long
  -madx                                 [enabled]
  -maes                                 [enabled]
  -malign-data=                         compat
  -malign-double                        [disabled]
  -malign-functions=                    0
  -malign-jumps=                        0
  -malign-loops=                        0
  -malign-stringops                     [enabled]
  -mandroid                             [disabled]
  -march=                               skylake-avx512
  -masm=                                att
  -mavx                                 [enabled]
  -mavx2                                [enabled]
  -mavx256-split-unaligned-load         [disabled]
  -mavx256-split-unaligned-store        [disabled]
  -mavx5124fmaps                        [disabled]
  -mavx5124vnniw                        [disabled]
  -mavx512bitalg                        [disabled]
  -mavx512bw                            [enabled]
  -mavx512cd                            [enabled]
  -mavx512dq                            [enabled]
  -mavx512er                            [disabled]
  -mavx512f                             [enabled]
  -mavx512ifma                          [disabled]
  -mavx512pf                            [disabled]
  -mavx512vbmi                          [disabled]
  -mavx512vbmi2                         [disabled]
  -mavx512vl                            [enabled]
  -mavx512vnni                          [disabled]
  -mavx512vpopcntdq                     [disabled]
  -mbionic                              [disabled]
  -mbmi                                 [enabled]
  -mbmi2                                [enabled]
  -mbranch-cost=<0,5>                   3
  -mcall-ms2sysv-xlogues                [disabled]
  -mcet
  -mcet-switch                          [disabled]
  -mcld                                 [disabled]
  -mclflushopt                          [enabled]
  -mclwb                                [enabled]
  -mclzero                              [disabled]
  -mcmodel=                             [default]
  -mcpu=
  -mcrc32                               [disabled]
  -mcx16                                [enabled]
  -mdispatch-scheduler                  [disabled]
  -mdump-tune-features                  [disabled]
  -mf16c                                [enabled]
  -mfancy-math-387                      [enabled]
  -mfentry                              [disabled]
  -mfma                                 [enabled]
  -mfma4                                [disabled]
  -mforce-drap                          [disabled]
  -mforce-indirect-call                 [disabled]
  -mfp-ret-in-387                       [enabled]
  -mfpmath=                             sse
  -mfsgsbase                            [enabled]
  -mfunction-return=                    keep
  -mfused-madd
  -mfxsr                                [enabled]
  -mgeneral-regs-only                   [disabled]
  -mgfni                                [disabled]
  -mglibc                               [enabled]
  -mhard-float                          [enabled]
  -mhle                                 [enabled]
  -miamcu                               [disabled]
  -mieee-fp                             [enabled]
  -mincoming-stack-boundary=            0
  -mindirect-branch-register            [disabled]
  -mindirect-branch=                    keep
  -minline-all-stringops                [disabled]
  -minline-stringops-dynamically        [disabled]
  -mintel-syntax
  -mlarge-data-threshold=<number>       65536
  -mlong-double-128                     [disabled]
  -mlong-double-64                      [disabled]
  -mlong-double-80                      [enabled]
  -mlwp                                 [disabled]
  -mlzcnt                               [enabled]
  -mmemcpy-strategy=
  -mmemset-strategy=
  -mmitigate-rop                        [disabled]
  -mmmx                                 [enabled]
  -mmovbe                               [enabled]
  -mmovdir64b                           [disabled]
  -mmovdiri                             [disabled]
  -mmpx                                 [disabled]
  -mms-bitfields                        [disabled]
  -mmusl                                [disabled]
  -mmwaitx                              [disabled]
  -mno-align-stringops                  [disabled]
  -mno-default                          [disabled]
  -mno-fancy-math-387                   [disabled]
  -mno-push-args                        [disabled]
  -mno-red-zone                         [disabled]
  -mno-sse4                             [disabled]
  -mnop-mcount                          [disabled]
  -momit-leaf-frame-pointer             [disabled]
  -mpc32                                [disabled]
  -mpc64                                [disabled]
  -mpc80                                [disabled]
  -mpclmul                              [enabled]
  -mpcommit                             [disabled]
  -mpconfig                             [disabled]
  -mpku                                 [disabled]
  -mpopcnt                              [enabled]
  -mprefer-avx128
  -mprefer-vector-width=                256
  -mpreferred-stack-boundary=           0
  -mprefetchwt1                         [disabled]
  -mprfchw                              [enabled]
  -mpush-args                           [enabled]
  -mrdpid                               [disabled]
  -mrdrnd                               [enabled]
  -mrdseed                              [enabled]
  -mrecip                               [disabled]
  -mrecip=
  -mrecord-mcount                       [disabled]
  -mred-zone                            [enabled]
  -mregparm=                            6
  -mrtd                                 [disabled]
  -mrtm                                 [enabled]
  -msahf                                [enabled]
  -msgx                                 [disabled]
  -msha                                 [disabled]
  -mshstk                               [disabled]
  -mskip-rax-setup                      [disabled]
  -msoft-float                          [disabled]
  -msse                                 [enabled]
  -msse2                                [enabled]
  -msse2avx                             [disabled]
  -msse3                                [enabled]
  -msse4                                [enabled]
  -msse4.1                              [enabled]
  -msse4.2                              [enabled]
  -msse4a                               [disabled]
  -msse5
  -msseregparm                          [disabled]
  -mssse3                               [enabled]
  -mstack-arg-probe                     [disabled]
  -mstack-protector-guard-offset=
  -mstack-protector-guard-reg=
  -mstack-protector-guard-symbol=
  -mstack-protector-guard=              tls
  -mstackrealign                        [disabled]
  -mstringop-strategy=                  [default]
  -mstv                                 [enabled]
  -mtbm                                 [disabled]
  -mtls-dialect=                        gnu
  -mtls-direct-seg-refs                 [enabled]
  -mtune-ctrl=
  -mtune=                               skylake-avx512
  -muclibc                              [disabled]
  -mvaes                                [disabled]
  -mveclibabi=                          [default]
  -mvect8-ret-in-mem                    [disabled]
  -mvpclmulqdq                          [disabled]
  -mvzeroupper                          [enabled]
  -mwbnoinvd                            [disabled]
  -mx32                                 [disabled]
  -mxop                                 [disabled]
  -mxsave                               [enabled]
  -mxsavec                              [enabled]
  -mxsaveopt                            [enabled]
  -mxsaves                              [disabled]

  Known assembler dialects (for use with the -masm= option):
    att intel

  Known ABIs (for use with the -mabi= option):
    ms sysv

  Known code models (for use with the -mcmodel= option):
    32 kernel large medium small

  Valid arguments to -mfpmath=:
    387 387+sse 387,sse both sse sse+387 sse,387

  Known indirect branch choices (for use with the -mindirect-branch=/-mfunction-return= options):
    keep thunk thunk-extern thunk-inline

  Known data alignment choices (for use with the -malign-data= option):
    abi cacheline compat

  Known vectorization library ABIs (for use with the -mveclibabi= option):
    acml svml

  Known address mode (for use with the -maddress-mode= option):
    long short

  Known preferred register vector length (to use with the -mprefer-vector-width= option)
    128 256 512 none

  Known stack protector guard (for use with the -mstack-protector-guard= option):
    global tls

  Valid arguments to -mstringop-strategy=:
    byte_loop libcall loop rep_4byte rep_8byte rep_byte unrolled_loop vector_loop

  Known TLS dialects (for use with the -mtls-dialect= option):
    gnu gnu2

GNU C17 (GCC) version 8.3.1 20190311 (Red Hat 8.3.1-3) (x86_64-redhat-linux)
        compiled by GNU C version 8.3.1 20190311 (Red Hat 8.3.1-3), GMP version 6.0.0, MPFR version 3.1.1, MPC version 1.0.1, isl version isl-0.16.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-march=native' '-Q' '--help=target' '-v'
 /opt/rh/devtoolset-8/root/usr/libexec/gcc/x86_64-redhat-linux/8/as -v --64 -o /tmp/ccBg1zy2.o /tmp/cc3URSRH.s
GNU assembler version 2.30 (x86_64-redhat-linux) using BFD version version 2.30-54.el7

Alright, I found the issue. This should work with the current master. I was simply using bench_fun_f instead of bench_fun_d. This means that the code was computing the logarithm in double, but with float operands/results. This resulted in float<->double conversions, which apparently are not supported if the vector size is 256.

Is is possible to circumvent this problem by some magic like this for a limited range and little endian cpu only ?
inline int double2int( double d )
{
   union Cast
   {
      double d;
      int i;
    }  c;
   const double magic = 1.5*(1LL<<52);
   c.d = d + magic;
   return c.i;
}

from: https://stackoverflow.com/a/429812

What problem are you speaking about?

Sorry, maybe my last reply is irrelevant to this issue.
Because of the algorithmic right shift operation >>52 is inevitable but it cannot be vectorized without avx512dq instructions, I can never expect to get this double version code accelerated as much as float32 version in non-avx512dq CPU, even the CPU have avx2 instruction set and 256bit registers available. Right?

Indeed, I don't see a way to do that. The right shift is not the only issue: conversions between 64bits integers and doubles are neither available.


Incorrect query syntax + s3 handling in SageMaker ipynb

This code in the ipynb throws a syntax error:

query = """
DESCRIBE {}.{}
""".format(DB_NAME, TABLE_NAME)

it should be
query = """
DESCRIBE "{}"."{}"
""".format(DB_NAME, TABLE_NAME)

When following the instructions associated with this notebook, you correctly create a SageMaker IAM role with access to TimeStream and s3, however the bucket "ts-sagemaker" is not created in anyway that's reflected in your S3 console and the included code throws a false permission error. If you try to create a bucket with that name S3 says the bucket exists, yet S3 says you have no buckets and the ipynb code returns a permission error even with full S3 access granted to the SageMaker execution role. A solution is to create your own bucket manually (e.g. "ts-sagemaker-1") and update the ipynb accordingly.

@hack-r
Thanks for posting the issue. I was unable to re-create your syntax error. Testing with Anaconda locally and with an S3 bucket I could successfully execute this query in Timestream_SageMaker_Demo notebook.ipynb. You are correct about the missing step for S3 bucket creation. I will try to get the documentation updated. If you have anymore information on why your query throws a Syntax error I can try to re-create, otherwise I think this issue should be closed.

OK, thanks. That was like 2 years ago, so if you need me to reproduce then I will need a day or 2.On Aug 14, 2023, at 7:03 PM, Forest Vey @.***> wrote:
@hack-r
Thanks for posting the issue. I was unable to re-create your syntax error. Testing with Anaconda locally and with an S3 bucket I could successfully execute this query in Timestream_SageMaker_Demo notebook.ipynb. You are correct about the missing step for S3 bucket creation. I will try to get the documentation updated. If you have anymore information on why your query throws a Syntax error I can try to re-create, otherwise I think this issue should be closed.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>


nivoslider and https ssl issue

Hi
I am using nivoslider in a website and it works perfect on http url but I just got and set up a SSL on the website and now when go to https version of the site, the nivoslider has stopped working and none of the slideshow images are displayed, can anyone help please or had this issue before and how to resolve it
Thank you
Ian

Sorry just sussed it, I just updated the js googleapis file to use https so is now the following in case anyone else needs to know how to solve it
FROM

TO

One of our website is using the Gravida theme which has the nivoslider and found "nivo-slider.css" had the issue. Was that you case too?

I can't remember now, it was so long ago haha. I remember it was a hand coded site and not using WP

No problem. Have a great day, IanHaney.


support for rfc7692 message deflate

Description
Adds support for querying rsv1 flag of websocket header. Needed to implement per message deflate as RFC7692.
https://datatracker.ietf.org/doc/html/rfc7692#section-9.2

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Aligning main with our development branch

First pass at creating a stand-alone schematron file for any EAS schema.

Just a note that squash and merge should be fine for the initial pull request.


Allow other options to be passed into the inbox call

For example,  "private_domain: true"

bump

Hi @skaasten, thanks a lot for the contribution. This looks like a legit change we can include in the gem. As listed in the documentation we can actually pass options like "private_domain: true" to the Email class as well.
Could you please add the same change to the Email class so it can benefit from your change also?
And would be really nice to add some tests for this new behaviour.
Regarding the broken tests you can just merge master in and it should be fixed.
Thanks.

Closing due to lack of activity.
The PR https://github.com/ainformatico/mailinator/pull/13 might include some changes related to this PR.


Dimensions

This seems like a really cool project! I was wondering if you'd thought about adding a dimensions system, which would be a nice fit with Lean, since it requires somewhat dependent types.
For example, a quantity like momentum has dimensions $MLT^{-1}$ (mass, length, inverse time), so can only be added to another quantity with those dimensions, but can be multiplied by a quantity with any dimensions. One could translate this into a type system by having numbers like n : (Dim (M 1) (L 1) (T (-1)) with appropriate types for addition and multiplication.
Keeping track of dimensions and ensuring that dimensional errors aren't made seems like a nice use-case of something like SciLean for physical problems like Hamiltonian mechanics.

Yes that is definitely on the agenda. I already did some experimentation with physical units, have a look here . It keeps track of units and not only of dimensions. So you do not accidentally mix up metric system with imperial.
However, it is just an experiment. It is limited to mass, length and time. It is not easily extensible. Also it should play nicely with the rest of the code, for example if you differentiate trajectory of a particle then the derivative should have naturally dimensions of velocity.
It needs a lot more thought and experimentation, maybe get inspired by this project that has dimensional analysis. Also I feel that keeping track of only dimensions is not enough in practice. You really want to keep track of units as that is the biggest source of mistakes and frustration. Any thoughts on this?


What's the reason of the downgrading from original parameter-server?

The  original implementation of parameter-server has implemented the important features in the osdi 2014 paper of "Scaling Distributed Machine Learning with the Parameter Server",  such as replication, bounded delay consistency,...,etc.  It seems current ps-lite is a much simpler implementation, it's just a simple ps solution with BSP and ASP, what's the reason for such a downgrading?

After reviewing the codes of ps-lite and parameter-server(ps), here are my conclusions:

Bounded-delay is algorithm specific.  It requires synchronous operation at the ps server side.
In most cases, only BSP or ASP are used for both ps-lite and ps.
ps-lite has better interfaces


Support building android-ndk-maven-plugin project itself with Java 8

currently fails when running mvn release:prepare at least.. Have to check again what it was but I think javadoc stuff. To check we should make sure
mvn clean install -P it
and
mvn site-deploy
work at least.

The project builds (mvn clean install -P it) but not sure I have the credentials for the deploy.


Problem with links on hackage.haskell.org

Looking into http://hackage.haskell.org/package/pipes-4.0.0/docs/Pipes-Prelude.html
concat :: ([LINK1]Monad m, [LINK2]Foldable f) => [LINK3]Pipe (f a) a m r
Has following links:
LINK1=file:///packages/archive/base/<IP_ADDRESS>/doc/html/Control-Monad.html#t:Monad
LINK2=file:///packages/archive/base/<IP_ADDRESS>/doc/html/Data-Foldable.html#t:Foldable
LINK3=http://hackage.haskell.org/package/pipes-4.0.0/docs/Pipes-Core.html#t:Pipe
Why is that? Is it haddock problem or hackage-s?

out of date


Confusing text on “suppose” vs. “assume” in Section 4.6

I found the following text rather confusing in Section 4.6 More on the Proof Language:

Using the keyword assume for this purpose would result in a syntactic ambiguity, since the expression assume h k could mean "assume h and assume k", leaving Lean to infer the relevant hypotheses from the context, or "assume proposition h k without a label". Using suppose avoids the problem. As with the anonymous have, the assumption can also be invoked by enclosing the assertion in backticks later in the proof.

First, it wasn't clear what “this” was referring to in the first sentence. Only later did I realize that it was referring to the following example code (I think). If so, then that fact should be made more clear, since “this” usually refers to something already referenced.
Second, I don't understand how assume results in syntactic ambiguity. Either (1) you are talking about something that you haven't introduced yet (one can assume proposition h k without a label?), or (2) you are comparing apples to oranges by comparing suppose with hypotheses to assume without hypotheses, or (3) there is something else or some combination of the above going on.

You are right, it is a lousy explanation. I'll fix it. The issue is that there is an asymmetry: you can write both
have H : x = 0, ...

and
have x = 0, ...

but for assumptions, you have to write either
assume H : x = 0

or
suppose x = 0

I was trying to explain why we cannot allow anonymous "assume". The problem is Lean also lets you write
assume H, ...

to introduce the hypothesis with label H, and let Lean infer the proposition that is being asumed. I is equivalent to
assume H : _, ...

But if we were to allow anonymous assume, there would be ambiguity with assume H: it could mean, infer the proposition that we are assuming, and label it H, or assume the proposition H, with implicit label this.
Does that make sense?

Does that make sense?

Yep. Thanks!

Actually, I think it's important that this is a question of language design rather than user usage. In other words, you explained here why the language designer would not allow for an anonymous assume. But from a tutorial perspective, it should perhaps be more of a “Hey, watch out for this potential syntax gotcha!”
(It just occurred to me that one shouldn't just assume one can be anonymous with assume. Punny!)


Wrongly shows error for read-only contract calls

In VS Code, an error is shown for the following contract
(define-read-only (flip-coin-delegate)
  (contract-call? .flip-coin flip-coin)
)

flip-coin.flip-coin is a read-only function

Related issue: https://github.com/blockstack/stacks-blockchain/issues/1630

Addressed with latest!


Can't add spaces at end of text

I want to add a space at the end of some sentences as I am using this for a website with the specific requirement.
However, I can't due to the markdown removing any trailing spaces by stripping the text. I am wondering if there is a way to prevent this? Is there any extensions of such that can allow this?

There is no reason to support this in Markdown as Browsers condense multiple whitespace characters in HTML into a single space anyway. However, in HTML you can work around this by using non-breaking spaces. As Markdown accepts raw HTML, you can do the same within Markdown.
Specifically, use the HTML entity ( ). However, to save on typing, you only need every other space to be non-breaking. Therefore, to add four spaces to the end of a paragraph, try this:
A Markdown paragraph.


How can I keep the image aspect ratio? Thanks!

the image is background-image css
so you can change css class slider-image-inner -> background-size : contain;
 .slider-image-inner{
      position: absolute;
      top:0;
      left: 0;
      right: 0;
      bottom: 0;
      height: 100%;
      width: 100%;
      background-size: cover;
      background-position: 50% 50%;
      background-repeat: no-repeat;
     overflow: hidden;
    }


Error on parallel execution with imported manifests

Running into a strange error when trying to modularize my modules into different manifests. Getting the following error when providing a --start-block and triggering parallel execution:
Error: rpc error: code = Internal desc = error building pipeline: failed setup request: parallel processing run: scheduler run: process job result for target "deployment:store_deployments": worker ended in error: receiving stream resp: rpc error: code = ResourceExhausted desc = grpc: received message larger than max (6029944 vs. 4194304)

Here is the graph with all modules in a single manifest:
graph TD;
  map_factories[map: map_factories]
  sf.ethereum.type.v2.Block[source: sf.ethereum.type.v2.Block] --> map_factories
  store_factories[store: store_factories]
  map_factories --> store_factories
  map_deployments[map: map_deployments]
  sf.ethereum.type.v2.Block[source: sf.ethereum.type.v2.Block] --> map_deployments
  store_factories --> map_deployments
  store_deployments[store: store_deployments]
  map_deployments --> store_deployments
  map_safe_setup[map: map_safe_setup]
  sf.ethereum.type.v2.Block[source: sf.ethereum.type.v2.Block] --> map_safe_setup
  store_deployments --> map_safe_setup

And here it is after separating into different manifests
graph TD;
  map_safe_setup[map: map_safe_setup]
  sf.ethereum.type.v2.Block[source: sf.ethereum.type.v2.Block] --> map_safe_setup
  deployment:store_deployments --> map_safe_setup
  deployment:map_deployments[map: deployment:map_deployments]
  sf.ethereum.type.v2.Block[source: sf.ethereum.type.v2.Block] --> deployment:map_deployments
  deployment:factory:store_factories --> deployment:map_deployments
  deployment:store_deployments[store: deployment:store_deployments]
  deployment:map_deployments --> deployment:store_deployments
  deployment:factory:map_factories[map: deployment:factory:map_factories]
  sf.ethereum.type.v2.Block[source: sf.ethereum.type.v2.Block] --> deployment:factory:map_factories
  deployment:factory:store_factories[store: deployment:factory:store_factories]
  deployment:factory:map_factories --> deployment:factory:store_factories

To be clear, it all works in single threaded execution so I don't think its a manifest/configuration problem. It also works in parallel execution when everything is contained within a single manifest.
Using the latest release binary (v0.2.0)

Note: this affects imports from both other manifest files, as well as other packaged substream modules
i.e.
imports:
  eth: https://github.com/streamingfast/sf-ethereum/releases/download/v0.10.2/ethereum-v0.10.4.spkg
  deployment: ../deployment/substreams.yaml

or
imports:
  eth: https://github.com/streamingfast/sf-ethereum/releases/download/v0.10.2/ethereum-v0.10.4.spkg
  deployment: ../deployment/masterfile-deployment-v0.1.0.spkg

both have same error

Created reproducible example here:
https://github.com/ghardin1314/substreams-issue

I was able to reproduce. It seems some internal message exchanged internally goes over the 4MiB default limit allowed for message.

The issue only arises when using ServiceDiscovery (XDS), so it is hard to reproduce with local server...

Fixed here :
https://github.com/streamingfast/dgrpc/commit/75702708cf92ed47a3c770313b2de183ddd282df
bumped here:
https://github.com/streamingfast/firehose-ethereum/commit/28387e2fc4d875cefab77f3fbe7d3747028226d6 and
and deployed to our polygon environment polygon.streamingfast.io. I can no longer reproduce the issue on our environment with this.
Let me know if you experience the issue again, you can always reopen this ticket.
Note that the fix is not pushed on our other environments for now, but it will come.
it came from our


BUG: Fix LSODA interpolation scheme

Reference issue

Closes gh-14480
What does this implement/fix?

As explained in #14480, LsodaDenseOutput fails to reproduce y(t_old). It looks to me that this only occurs when LSODA plans on changing the method order (i.e. NQU != NQCUR, equivalent to self._lsoda_solver._integrator.iwork[13] != self._lsoda_solver._integrator.iwork[14]). To be clear, this is not exactly a bug in Scipy - Scipy perfectly implements Taylor's theorem and applies the scaling explained in DLSODA. Instead, it is likely a mistake either in the FORTRAN implementation or in its associated docstring.
Taking #14480 again as an example, the implemented formula in Scipy is equivalent to:
(1.71524262e-06
 + -1.24130739e-06 * (0.06342019780923039 - 0.06402588986309915) / 0.00019480871245159827
 + 1.88400737e-07 * ((0.06342019780923039 - 0.06402588986309915) / 0.00019480871245159827) ** 2)

which yields 7.395919849794794e-06.
The proposed formula reads:
(1.71524262e-06
 + -1.24130739e-06 * (0.06342019780923039 - 0.06402588986309915) / 0.00019480871245159827
 + 1.88400737e-07 * ((0.06342019780923039 - 0.06402588986309915) / 0.00019480871245159827) ** 2
 + -4.87455807e-07 * ((0.06342019780923039 - 0.06402588986309915) / 0.0006056920538687616) ** 3)

and yields 7.883375656794793e-06, which is the correct result.
In the formulas above, [1.71524262e-06, -1.24130739e-06, 1.88400737e-07, -4.87455807e-07] is the Nordsieck history array YH, obtained in that case through self._lsoda_solver._integrator.rwork[20:24]; 0.06342019780923039 is t_old; 0.06402588986309915 is t; 0.00019480871245159827 is self._lsoda_solver._integrator.rwork[11], HCUR; and 0.0006056920538687616 is self._lsoda_solver._integrator.rwork[10], HU.
Therefore, it looks like one term is missing when NQCUR < NQU. According to the docstring, the number of terms included in the formula should be controlled by NQCUR. However, I have found that it is really NQU that should be used. In the case where NQU == NQCUR, nothing changes. When NQCUR < NQU, as highlighted above, one term is added, and, interestingly, it must use HU instead of HCUR. Finally, when NQCUR > NQU, the proposed implementation discards one term compared to the current implementation. I have tested locally all the possible scenarios with both method order and step size changing; the proposed implementation yields the right result every time.
I do not have an explanation for the why behind all of this. Perhaps someone motivated can have a careful look through DSTODA - I feel that the reason lies there somewhere.
Additional information

ODEPACK is available here.

@tylerjereddy @tupui Any chance for some feedback on this PR? Could you potentially add the proper tags (scipy.integrate and defect I imagine) and request a review from someone familiar with solve_ivp within the SciPy community? Thank you for your help.

Thanks @tylerjereddy. I agree I would also like to provide the proper explanation as to why this behaviour is happening. Having a look again at the last update I posted on gh-14480, it looks to me like a proper bug in the FORTRAN implementation of either DLSODA, DSTODA or DINTDY. The reason I am saying this is that I can exactly reproduce the value given by SciPy using the lines of code within DINTDY and replacing the values of all the relevant variables with what SciPy gives.
I would not be surprised that LsodaDenseOutput is lacking some testing, because otherwise this bug would have been caught earlier. The tricky thing here is that it is not obvious to test because you need to rely on the fact that DLSODA will decide to change the order of the method used during integration, which is almost impossible to predict. One thing I can think of is to hardcode a few cases where the order of the method is indeed observed to change, but this is very fragile.

@tylerjereddy I have just found the following comment, which corresponds exactly to the bug I have reported. I will push a commit to remove this if condition and see if CI stays green.

It turns out that these tests were passing anyway even without the changes proposed in this PR. I have tried to further replicate the behaviour I have previously described, but I could not achieve any success without hard-coding values. I have also tried to use the tests already present in test_ivp.py but, here again, no success. Nevertheless, I think I have finally found something. The core of the issue I have reported is that interpolants for LSODA are inaccurate within the interval [t_old, t[. The only way to demonstrate it is to compare the interpolant calculated at t and evaluated at t_old with the algorithm solution at t_old. This is almost what is happening while events are handled because brentq evaluates the interpolant both at t_old and t and checks that obtained values bracket 0. If they do not, then it clearly means that the interpolant value for t_old is wrong as the one for t is, by construction, equal to the algorithm solution. However, once the integration is complete, such a comparison is not possible anymore as the interpolants are combined in such a way that evaluation at a given t value that was used by the algorithm during integration always results in calling the interpolant when that t value was equal to t, and not t_old. However, one can easily modify this behaviour, i.e. use the interpolant for when ŧ was equal to t_old instead. I will push a commit that includes this modification and reverts my changes in lsoda.py. This should yield AssertionError in multiple tests within test_ivp.py. Once testing is done, I will re-apply my changes in lsoda.py while keeping the modified behaviour, and this should, hopefully, execute without any error.

FYI, you will need to merge master for the CI to run due to recent changes on master. For the PR itself, I am afraid I am not qualified as well.

@tupui Thanks for the heads-up!
CI is back to green, so I can give more detail about what happened over the last few commits. Reverting the changes in lsoda.py and inverting the behaviour of the interpolant in common.py (combined with merging master into the fork) triggered four AssertionError within test_ivp.py, which we can separate in two groups: test_OdeSolution and the rest. test_OdeSolution failed because of the changes in common.py as test_OdeSolution makes use of solutions that are discontinuous. At the discontinuity, the value given by the interpolant depends on if the interpolant selects the segment before or after the discontinuity. As a result, inverting the behaviour of the interpolant will indeed change the value at the discontinuity and, thereby, lead to failing assertions there. For the second group of errors, let's look at the last commit. In there, I re-apply the changes proposed in this PR to lsoda.py and adjust values in test_OdeSolution to avoid the failure just described. In doing so, all four AssertionError disappear. In particular, for the second group of errors, this demonstrates that the failures described before the last commit were due to LSODA as a result of the change in interpolant behaviour. What is interesting here is that this change does not seem to affect other solvers, meaning that evaluating the solution at t_old from both the interpolants calculated at t and t_old yields the correct results for all solvers, except LSODA (that is, without this PR included). However, it does affect discontinuous solutions such as the ones used in test_OdeSolution and, therefore, it leads to a backwards-incompatible change. The good news here is that the changes in common.py and test_OdeSolution are not strictly speaking needed: I only committed them to perhaps more clearly highlight the origin of the bug at the root of this PR and also demonstrate that currently implemented tests in SciPy do fail if the bug in LSODA is exposed to them. A final concern is that codecov still indicates that the proposed change in lsoda.py to account for the method changing order is untested. Again, I cannot manage to think of an elegant way to have this condition tested other than hard-coding a case where it is used.

Update regarding the last commits
Through a short discussion with the developer of the Julia wrapper around the C implementation of LSODA, I realised that the way I was describing the issue here at SciPy was not fully accurate. Indeed, I was presenting the bug as resulting from an error in the interpolation scheme, and the fix I had implemented clearly differentiated the case with a method order decrease from the other ones. However, this does not make sense as the scheme used for interpolation is standard and, therefore, must be the same for all cases of method order changes. As a result, I pushed the first of the previous four commits, which clearly demonstrates that the method order used to extract derivative values was wrong and that there is a scaling issue for the highest order derivative when the method order decreases. The resulting behaviour of lsoda.py does not change from the first proposed fix (CI stayed green); I simply put the emphasis on where the problem really is.
Furthermore, I realised that decreases in method order within LSODA occur when solution values become small. As a result, I was able to design a simple test case specifically for LSODA which I pushed in the second of the previous four commits. Also, I updated comments and docstrings in common.py to reflect the change in segment selection behaviour. Finally, I reverted the proposed fix in lsoda.py to highlight that, without it, CI becomes red, which it did. The great outcome of that commit is full coverage of _dense_output_impl within lsoda.py, as highlighted by codecov and which was missing before.
In the third commit, I re-applied the proposed changes to lsoda.py to demonstrate that CI would go back to green. It almost did, as only CircleCI reported an unrelated failure, which I thought I could fix by merging master into my fork (commit 4), but no luck. In any case, this fully establishes that the proposed changes to common.py allow revealing the current bug in SciPy associated with LSODA, which the newly implemented test in test_ivp.py does capture fully.
Summary of this PR

The current bug associated with the LSODA solver corresponds to the interpolant not being able to reproduce expected, correct values when the method order used by the solver changes across a step.

During a solver step, the method order used for the next step is determined. There are three possible cases:

The method order stays the same. The number of terms considered when evaluating Taylor's theorem, which is equal to order + 1, can only be correct as there is only one order value to choose from. Hence, the interpolant produces correct values.
The method order increases. The number of terms is still order +1, but this time there are two possible values for order. SciPy uses the value of the next step, which is incorrect and leads to inaccuracies in the interpolant through the addition of an extra term into the formula.
The method order decreases. Here again, there are two possible values for order. SciPy incorrectly uses the value for the next step and, therefore, misses one term, leading to interpolation errors. Additionally, this extra term is not properly scaled when the timestep is set to change across the next solver step.

Proposed changes in lsoda.py include using the correct method order value and re-scaling the highest-order-derivative term when the method order decreases (this could be further restricted to when the timestep changes as well, but that would not change the results).

There are at least two reasons why current tests implemented within SciPy do not capture this bug:

Comparing solver solutions at solver-chosen steps to dense output interpolation of the same solver-chosen steps. The current behaviour implemented in SciPy is to assemble the full dense output functionality by selecting interpolant segments that correspond to segments calculated when the steps chosen by the solver were the current step within the solver, as opposed to the previous step. By construction, the LSODA interpolant is exact at the current step, and hence it is impossible to assess if the interpolant is doing its job properly.
Assessing comparisons between analytical and interpolated solutions by checking that a computed error metric is small enough given solver tolerances. This is a pretty standard and valid approach. However, errors generated through the present bug by the LSODA interpolant are small enough so that they pass under the radar. Nevertheless, they are big enough to generate errors while handling events, as highlighted in the issue associated with this PR.

Proposed changes in this PR mainly address the first reason just stated through changes in common.py and test_ivp.py. Selected interpolant segments at a given solver-chosen step now correspond to calculated segments when the step was the previous step in the solver. An additional test allows capturing both method order increases and decreases; the latter was missing.

Proposed changes in this PR only deal with consequences, as opposed to causes. It is extremely likely that the root of this bug is an error in scaling the highest order derivative stored in the Nordsieck history array when the method order is set to decrease. It looks to me that this only influences the behaviour of the interpolant, and not the one of the solver, otherwise asserting equality between analytical and solver-produced solutions would fail. Nevertheless, it would be best to confirm this hypothesis, which may prove tedious.

@tylerjereddy @tupui Can you confirm that the CircleCI failure is unrelated to this PR? Additionally, considering the progress made on this PR, is there any chance for it to be included in the v1.8.0 release?

Can you confirm that the CircleCI failure is unrelated to this PR?

Looks like it is unrelated from a quick look through the connected functions, and we have had a few timeout issues with CI benchmarks recently. I'm not an expert on the benchmarked code or the code adjusted here though.

Additionally, considering the progress made on this PR, is there any chance for it to be included in the v1.8.0 release?

1.8.0 is still a few months away (usually in December for the "winter release"), and for bug fixes we even consider backporting to i.e., 1.7.x. Main challenge remains an expert reviewer--perhaps we could ping the Julia maintainer you mention? From reading through some of the (detailed) descriptions above, it sounds like we do now have executable evidence/testing that something was fixed? So, that sounds a fair bit more promising as a non-expert at least.

@nmayorov Would you have some time to take a look at this PR? It would be nice to have this bug fixed.

Just a small comment that #15860 seems to be fixed by the changes made to lsoda.py in this PR.

@mdhaber I have rewritten the commit history of this PR and now have only two commits. The first one introduces changes in OdeSolution, re-activates testing of LSODA in some tests, and adds a new test targeting the accuracy of LSODA's interpolant. These changes basically expose the bug in the current main branch of SciPy. In the second commit, I patch this bug. Do you think there is any chance you could review these changes, or would we still want @nmayorov input?

I will try to decide this weekend whether I can review this.

I had given the content of the first commit here---the choice of segment sides---some thought in https://github.com/scipy/scipy/pull/15667#issuecomment-1052889956 (which I should've posted here originally, too), which I wanted to follow up on. (I haven't checked the LSODA internals myself to be able comment on the fix in the second commit.)
The addition of the alt_segment flag to OdeSolution seems like the right move to me per my previous comment---it's flexible to methods with polynomial interpolant nodes at the beginning of the timestep interval (e.g., RK methods) or the end (LSODA and BDF, I think). But I'm confused: it doesn't seem anything was changed to actually use alt_segment=True, such that c417b7d doesn't actually make any behavioral changes. Am I inferring correctly that the (now passing) tests that evaluate LSODA interpolants at the nodes/breakpoints are still "trivial" (in the sense that the polynomials are evaluated with argument 0)? My memory was that enabling a nontrivial test of the LSODA interpolants' evaluation at breakpoints was the motivation for such a change.

Thanks, @zachjweiner, it is true that the discussion you linked is the one that made me think of this alt_segment argument. It took me forever to finally get to write it down, but here we are. Thank you also for pointing out again that BDF uses the same interpolant construction choice as LSODA; I had missed that. And indeed, thank you for the careful comment regarding the missing change: for some reason, I forgot to include it.
I have also taken the opportunity to update the additional test I contributed to test_ivp.py. The main purpose of this test was to cover the added if condition of _dense_output_impl, but it is also useful to highlight the failure that I had initially reported in gh-14480.

I've been trying to understand the logic in LSODA with order and step size and how it affects "yh".
Theoretically when the order increases the highest derivative of the new model polynom should be zero, according to this paragraph:

But we see that it is not the case with LSODA. Maybe this last column in yh is in some "utility" state at this point and we indeed should not use it (and thus use the order in the last step).
As of the decreasing order, @Patol75 can you provide me with an example of the problem when the order decrease is triggered?

Hi @nmayorov,
Thank you for looking into this PR. As for providing an example of the problem when order decreases, the new test implemented in this PR does exactly that. If you look at the CI run associated with the first commit above, you can see a failure being reported for this new test.

Just checking in, any chance for an update on the review status of this PR?

I'm sorry this hasn't received further review yet. I'm not an expert on the code in question, but I may be able to take a look. However, it's unlikely that this makes it into 1.11, which is due to branch very soon, so I'm bumping the milestone for now. If things get resolved in time, we can of course change it back again.

@Patol75 I've looked carefully through the relevant Fortran code in stoda.f and lsoda.f, and now understand what the issue is.
Your solution appears correct. What follows is my understanding of what's going on:
This is not due to a bug in ODEPACK. For getting dense output, what we want is the approximating polynomial for the last successful step. As you noticed, SciPy's wrapper is currently taking the approximating polynomial to order nq, the order to be attempted next, rather than nqu, the last successful order. Replacing order = iwork[14] with order = iwork[13] is the correct fix here.
After each call to stoda, the Nordsieck history array, yh, will be in the state needed for attempting the next step, not in the state for the last successful attempt.
The columns of the Nordsieck array are of the form
$$\frac{h^j}{j!}P^{(j)}(t)$$
for j from 0 to the order q, and where $P(t)$ is a vector of length $n$ where $n$ is the number of equations. I read Nordsieck (1962) and found that t can not change when modifying the array for attempting the next step, what can change is the order q and the step size h. Change in the order is handled by adding or removing a term, and a change in h is handled by rescaling.
Looking at the dense output implementation code

    def _call_impl(self, t):
        if t.ndim == 0:
            x = ((t - self.t) / self.h) ** self.p
        else:
            x = ((t - self.t) / self.h) ** self.p[:, None]

        return np.dot(self.yh, x)

the particular value of h used doesn't actually matter. It's being scaled out. What matters is that all of the entries of the Nordsieck history array are using the same value of h. However, when the order is being reduced within stoda, because the Nordsieck array yh needs to end up in the state needed for the next step, what is the last column for the current order will be dropped from consideration, so stoda does not need to rescale it. All of the other columns are rescaled for the h to be attempted next. This is why when the order is decreasing, you need to rescale only the last column. Your fix  is correct.
I'm sorry if this not clear yet. I've written it up hastily. Please let me know if you have any questions. I think there should be a comment added to _dense_output_impl explaining the changes you've made. I can suggest something in a review comment. I should have the full review completed today.

@Patol75 Do you have any thoughts on the suggested comments? If you think they look fine I think this is ready to merge.

@steppi I am very, very grateful for the reviewing work you have done here. What you uncovered makes a lot of sense to me and explains perfectly the behaviour that I had noticed and documented. The added comments are, I believe, extremely helpful for anyone who would try to understand how the interpolant is built. I think I owe you a massive thank you!
I agree that the PR should now be ready for merging provided the CI returns green. For now, I see that CircleCI reports a failure while attempting to build SciPy, but it seems to be related to some code in special.

@steppi I am very, very grateful for the reviewing work you have done here. What you uncovered makes a lot of sense to me and explains perfectly the behaviour that I had noticed and documented. The added comments are, I believe, extremely helpful for anyone who would try to understand how the interpolant is built. I think I owe you a massive thank you!
I agree that the PR should now be ready for merging provided the CI returns green. For now, I see that CircleCI reports a failure while attempting to build SciPy, but it seems to be related to some code in special.

No problem, happy to help! Thanks for sorting out this problem.
The CircleCI failure is due to that build using Python 3.8, while the type hints used are only available in what is now the minimum required version: 3.9.
I'm not sure what's causing the MannWhitneyU failure in linux_aarch64_test and macos_arm64_test, but it's definitely unrelated. I plan to merge this later today.
Feel free to ping me if you need a review for any PRs in the future.


update licenses (DAT-18710)

Impact

[ ] Bug fix (non-breaking change which fixes expected existing functionality)
[ ] Enhancement/New feature (adds functionality without impacting existing logic)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Description

Things to be aware of

Things to worry about

Additional Context

@StevenMassaro artifact creation failure
https://github.com/liquibase/liquibase/actions/runs/11261452469/job/31315956168?pr=6411
Comparing the contents of the tar.gz with the expected contents (using baseline file in liquibase-dist directory) to ensure that no new files were accidentally added. A failure here indicates that a new file was added to the tar.gz, and it should either be rectififed or added to the baseline.


Mention registry in the section defining extensions

The registry is not overly full, but it exists and hopefully will grow over time. Should the section defining extensions mention the registry and link to it and encourage people to (a) consider re-using extensions, and/or (b) consider creating reusable extensions? Following the lead of IETF/IANA that would require for registered extensions to be well-defined and well-described, because otherwise reuse is almost impossible.

@dret PR #3861 adds links to both the registry and the learn site near the top of the spec, and to the format registry in the data types section.  But I forgot about the extension section, so I'll add that to the PR as well.

@dret I have added a commit with this change (and generally rewrote that section a bit as I found its wording a bit hard to follow).

Looks all good to me and I think we can safely close this issue. Thanks, @handrews!


Implemented logging for packager using common logging utility.

Lint fails due to common header being in parent repo. Will fix after spaceport


python 3.11

I'm trying to read the book again to help some friends out who are reading it.  When I last attempted it python3.11 was the latest version and opening up a vagrant instance running on the centos container and python 3.6 stuff was broken.  Hoping to attempt installing python3.6 venv will cause it all to work.

See related: https://github.com/geerlingguy/ansible-for-devops/issues/589


Can't pull to a different file type

I pushed a .properties file, everythings works well.
But I can't pull to a XLIFF file.
This is what I did :
mojito push -r MyRepo -ft PROPERTIES -sr messages.fr.properties
mojito pull -r MyRepo -ft XLIFF

This is the message returned :
Pull localized asset from repository: MyRepo

Finished

And there are no files in output.

@BThibaut  Yes that's by design. The pull command is to generate the localized files corresponding the what was pushed with the push command (keeping the same file type).
What are you trying to do exactly? There are other commands that generate XLIFFs, but it is either to create kit for translation or export the translation memory.

The purpose is to push a simple key/value file used by the developers and pull a XLIFF file which is readable by a web application (Symfony).
Is it a workable way to do with Mojito ?

I see, no we don't support that use case out of the box. The output type is the same as input when working with pull/push commands.
You could use the tm-export command though to have something similar. That command exports the whole repository as XLIFF files so you'd get an XLIFF that should be similar to what you want. The only problem is that the file name of the XLIFF will be different, it is basically {reponame}-{assetnumber}_{locale}.xliff
mojito demo-create -n test
cd test
mojito tm-export -r test

will give you something like
demo.properties
test2-1_de-DE.xliff
test2-1_en-GB.xliff
test2-1_fr-CA.xliff
test2-1_ja-JP.xliff
test2-1_nl-NL.xliff
test2-1_ru-RU.xliff
test2-1_zh-CN.xliff
test2-1.xliff
test2-1_en-AU.xliff
test2-1_es-ES.xliff
test2-1_fr-FR.xliff
test2-1_ko-KR.xliff
test2-1_pl-PL.xliff
test2-1_sv-SE.xliff
test2-1_zh-TW.xliff
test2-1_da-DK.xliff
test2-1_en-CA.xliff
test2-1_fi-FI.xliff
test2-1_it-IT.xliff
test2-1_nb-NO.xliff
test2-1_pt-BR.xliff
test2-1_tr-TR.xliff

Thank your for your answer, I tried it and it replies to my issue.