Albin Ahlbäck
Albin Ahlbäck
In relation to #1832, it would be nice to implement different subroutines in `fft_small` based on register width (128 bits for NEON, 256 bits for AVX2, etc.) and the number...
Since we use Make for everything, perhaps the best thing would be to integrate it into there?
Hmm, yeah, I misunderstood. This should be possible.
For REGEX stuff, we can use PCRE2. Should be available on most modern systems. Will try to fix this during next week.
I do like the renaming, so I think this would be very suitable. Moreover, I do think it would be wise to pass it by reference. For four-inputted functions with...
> * Lots of `nmod` functions currently abort when encountering an impossible inverse. We should put in proper error handling instead. Yes, and we should avoid a lot of text-based...
In general, isn't it true that an `arb_t` is on the form $x = a 2^{m} \pm b 2^{n}$ with $a, b, m, n \in \mathbb{Z}$ and $|b 2^{n}| >...
> mulhi? I agree arbs would like this, but Newton's method likes mulmid more. I have been experimenting with the function > > ``` > ulong mpn_mulmid_approx(ulong* x, ulong xlo,...
No problem! I think it is under [this section of the documentation](https://flintlib.org/doc/acb_hypgeom.html#confluent-hypergeometric-functions). If you are only interested in the real-valued function, please see [this part of the documentation](https://flintlib.org/doc/arb_hypgeom.html#confluent-hypergeometric-functions) instead.
Why just not use the function `arb_hypgeom_1f1` (aka `arb_hypgeom_m`)? Is there a reason for using that specific algorithm?