MixedMath - explorations in math and programinghttps://davidlowryduda.comDavid's personal blog.en-usCopyright David Lowry-Duda (2022) - All Rights Reserved.admin@davidlowryduda.comadmin@davidlowryduda.comFri, 27 Sep 2024 21:11:51 +0000Fri, 27 Sep 2024 21:11:51 +0000mixedmathapp/generate_rss.py v0.1https://cyber.harvard.edu/rss/rss.htmlhttps://davidlowryduda.com/static/images/favicon-32x32.pngMixedMathhttps://davidlowryduda.comFourier expansions at different cuspshttps://davidlowryduda.com/fexp-cuspsDavid Lowry-DudaThis post is larger than 10000 bytes, which is above the limit for this RSS feed. Perhaps it is long or has embedded images or code. Please view it directly at the url.https://davidlowryduda.com/fexp-cuspsFri, 27 Sep 2024 03:14:15 +0000Explicit equations for cubic surfaceshttps://davidlowryduda.com/explicit-cubic-surfacesDavid Lowry-DudaThis post is larger than 10000 bytes, which is above the limit for this RSS feed. Perhaps it is long or has embedded images or code. Please view it directly at the url.https://davidlowryduda.com/explicit-cubic-surfacesFri, 20 Sep 2024 03:14:15 +0000Noteshttps://davidlowryduda.com/notesDavid Lowry-Duda<p>The notes below are approximately sorted into areas.</p> <h2>Notes on Number Theory</h2> <ol> <li> <p>Explicit equations for cubic surfaces, 2024.<br /> <a href="/wp-content/uploads/2024/09/cubic_equations.pdf">The note</a><br /> <a href="/explicit-cubic-surfaces/">discussion page</a></p> </li> <li> <p>Some details on Hecke algebras, 2024.<br /> <a href="/wp-content/uploads/2024/09/hecke.pdf">The note</a><br /> <a href="/hecke-algebra-details/">discussion page</a></p> </li> <li> <p>Bounds on partial sums from functional equations, 2024.<br /> <a href="/wp-content/uploads/2024/09/CNandBounds.pdf">The note</a><br /> <a href="/bounds-on-partial-sums-from-fe/">discussion page</a></p> </li> <li> <p>Computing Petersson inner products, 2023.<br /> <a href="/wp-content/uploads/2024/09/compute_petersson.pdf">The note</a></p> </li> <li> <p>Visualizing Modular Curves, a short technical note on implementation details for modular curve visualizations, 2022.<br /> <a href="/wp-content/uploads/2022/12/VisualizingModularCurves.pdf">The note</a><br /> <a href="/modcurveviz/">discussion page</a></p> </li> <li> <p>A note on <a href="/wp-content/uploads/2016/04/gaussian_integers_note.pdf">Gaussian Integers</a>, and a note on <a href="/wp-content/uploads/2016/04/gaussian_primes_note.pdf">Gaussian primes</a>, supplements for an elementary number theory course.</p> </li> </ol>https://davidlowryduda.com/notesTue, 10 Sep 2024 03:14:15 +0000Hecke Algebra detailshttps://davidlowryduda.com/hecke-algebra-detailsDavid Lowry-DudaThis post is larger than 10000 bytes, which is above the limit for this RSS feed. Perhaps it is long or has embedded images or code. Please view it directly at the url.https://davidlowryduda.com/hecke-algebra-detailsTue, 10 Sep 2024 03:14:15 +0000A note on sums over primeshttps://davidlowryduda.com/note-sums-primesDavid Lowry-DudaThis post is larger than 10000 bytes, which is above the limit for this RSS feed. Perhaps it is long or has embedded images or code. Please view it directly at the url.https://davidlowryduda.com/note-sums-primesWed, 24 Jul 2024 03:14:15 +0000Maass forms in the LMFDBhttps://davidlowryduda.com/maass-forms-now-in-lmfdbDavid Lowry-Duda<p>Rigorous Maass forms are now in the $L$-functions and modular forms database <a href="https://www.lmfdb.org/">LMFDB</a>. This is something I've been working on for a while, and it's nice to actually make the data available.<span class="aside"> This naturally follows certain talks I've given before, include <a href="/talk-on-computing-maass-forms">this one</a> and <a href="/talk-computing-and-verifying-maass-forms">this one</a>, as well as various chalk talks over the last couple fo years.</span></p> <p>The computations of the actual Maass forms uses work of Kieran Child, Andrei Seymour-Howell, and me. A variety of underlying techniques are used, including rigorous implementations of the Selberg trace formula, rigorous Hejhal's algorithm, and certification strategies.<sup>1</sup> <span class="aside"><sup>1</sup>See <a href="https://arxiv.org/abs/2204.11761"><em>Certification of Maass cuso forms of arbitrary level and character</em></a> by Child and <em>Dimensions of the spaces of cusp forms and newforms on $\Gamma_0(N)$ and $\Gamma_1(N)$</em> by Booker, Strömbergsson, and Venkatesh. I haven't talked much about these before.</span> And this all builds on the earlier heuristic approaches of Hejhal, later refined significantly by Strömberg, Lemurell, and Then. (And all data for $\mathrm{GL}(3)$ or $\mathrm{GL}(4)$ forms comes from completely different techniques of Farmer, Lemurell, and others).</p> <p>For now, the Maass forms are <a href="https://beta.lmfdb.org/ModularForm/GL2/Q/Maass/">on the LMFDB Beta</a>. If nothing breaks (and I hope it won't), then they'll soon be on the main LMFDB too.</p> <p>For the rest of this note, I want to describe a couple interesting facets of the newly available database.</p> <h1>Consecutive Maass Forms</h1> <p>One of our promises in the LMFDB is to not miss any Maass forms. For any given level, we have <em>every</em> Maass form with spectral parameter $0 < r < R$ for some $R$ (that currently depends strongly on the level). This guarantee comes largely from the trace formula: we can guarantee that we haven't missed any forms.<sup>2</sup> <span class="aside"><sup>2</sup>Or rather, any missing forms come from an implementation mistake, not a theoretical mistake.</span></p> <p>Thus when you look at all Maass forms in some data range, we know that they are all there. This should be a big help with experimentation.</p> <h1>Labels</h1> <p>One advantage of having consecutive Maass forms is that we can <em>label</em> Maass forms in a systematic way. For a (cuspidal, Hecke, new) Maass form on $M_k(\Gamma_0(N), \chi)$, we assign it the label <code>N.k.a.m.d</code>, where</p> <ul> <li>$N$ is the level,</li> <li>$k$ is the weight,</li> <li>$N.a$ is the Conrey label of the Dirichlet character $\chi$,</li> <li>$m$ is the <strong>spectral index</strong>, and</li> <li>$d$ is a disambiguation index if multiple Maass forms share the same earlier data. (This currently never happens).</li> </ul> <p>The <strong>spectral index</strong> is the index of the spectral parameter $R$ in the list of all spectral parameters for a given weight, level, and character, starting from $1$ if $R > 0$. The special case when the spectral index $m = 0$ is reserved for Maass forms induced from Hecke characters. These are not currently in the LMFDB, but they will be at some point in the future.</p> <p>In addition, if $k = 0$, $a = 1$, and $d = 1$, (which accounts for every Maass form currently in the LMFDB), then we assign the <em>short label</em> <code>N.m</code>.</p> <h2>Labels in the LMFDB</h2> <p>Labels can be a big deal in the LMFDB. We don't like changing labels, ever. Once we give a form a name, we want that name to never change. This means that there can be big label discussions.</p> <p>This time I tried designing what I thought was a robust label format, implementing it, and then asking for confirmation. This worked well! David Roe had the idea of adding the <em>short label</em>, which makes things look nicer.</p> <h1>Plots of Maass Forms</h1> <p>With new objects in the LMFDB, there comes new portraits.</p> <figure class="center"> <img src="/wp-content/uploads/2024/06/sample_maass_plot.png" /> </figure> <p>These are similar to the portraits we made for classical modular forms. But the Maass forms we currently have are all real-valued, and thus only take on two separate hues. (And unlike the classical modular forms, we included hints at contours to indicate a bit more).</p> <p>I overengineered portrait creation. I actually have <em>a lot</em> to say about it, and I'll write that down another time.</p> <h1>Check out the Maass Forms</h1> <p>So go forth and check them out! Right now they're on beta. If you manage to break anything, let me know and I'll fix it.</p> <p>Happy mathing!</p>https://davidlowryduda.com/maass-forms-now-in-lmfdbWed, 05 Jun 2024 03:14:15 +0000Another year, another TeXLive reinstallationhttps://davidlowryduda.com/another-year-another-texliveDavid Lowry-Duda<p>Every year, <a href="https://www.tug.org/texlive/">TeX Live</a> updates in a breaking way. This year it was on 13 March 2024.</p> <p>I don't notice until I need to do something somewhat uncommon with my TeX distribution, such as compiling a new template or style file. Today, I'm writing a funding proposal and was (re)compiling a similar proposal I wrote a couple of years ago. It happens to use the <code>extdash</code> package, which I don't have installed. But trying to install it now (via <code>tlmgr</code>) throws an error saying that my distribution is 2023, and now it's 2024, so it's time to upgrade.</p> <p>LaTeX distributions come in two forms: the main binaries and packages. Packages are updated continually and can be updated throughout the year. The main binaries are updated once each year. But once a binary is updated, the package manager (associated to a previous binary) will no longer allow package updates.</p> <p>The effect is that a new texlive installation is required each year. There are some update scripts, but these are unsupported and still essentially require downloading as much material as a full install.</p> <p>I haven't heard a compelling reason why this behavior is tolerated (let alone desirable). Further, following instructions typically leads with several side-by-side installations of tex (although each installation is HUGE and this is also unacceptable).</p> <p>The only benefit of this is that keeping older versions allows snapshot recompilation of older documents, or snapshot recompilation using packages with backwards incompatible updates (such as moderncv, which breaks <em>all the time</em>). But I don't like having that bloat, so I end up completely removing old versions and installing a fresh texlive each year.</p> <p>I sometimes want bleeding-edge latex things and don't use my linux distribution's package manager for this. Instead, I do it myself through the texlive package manager <code>tlmgr</code>. These are my notes on updating texlive from year to year.</p> <p>(In particular, these are the steps that I went through just now so that I can compile what I really wanted to compile).</p> <h2>Remove the previous installation</h2> <p>I keep the texlive source in <code>&dollar;HOME/src/texlive</code>.<sup>1</sup> <span class="aside"><sup>1</sup>You can probably guess where I keep source files for other things that I build and manage myself).</span> Looking now, I see that I have 598832 bytes of <em>stuff</em> there, meaning that the complete size of my texlive distribution for all latex that I've compiled in the last year is approximately 585MB. This is about 1/10th the size of the standard <code>TeXLive Full</code> installation on Ubuntu, which is one of the reasons why I prefer to manage the installation myself.<sup>2</sup> <span class="aside"><sup>2</sup>I began to use tlmgr to manage texlive when I was using a chromebook as my main driver, and I needed to be able to fit texlive on my tiny harddrive. I learned a lot about resource constraints then.</span></p> <p>I note for interest that 261MB of my texlive is dedicated to documentation for installed packages. Another 96MB is for fonts.</p> <p>Regardless, I remove the entirety of my <code>&dollar;HOME/src/texlive</code> at once.</p> <h2>Acquire and run the new installer</h2> <p>Go to <a href="https://tug.org/texlive/acquire.html">tug.org</a> and download the <a href="https://tug.org/texlive/acquire-netinstall.html">texlive internet installer</a>. This year, this is a 5.5MB file <code>install-tl-unx.tar.gz</code> .</p> <p>Move it to a freshly created <code>&dollar;HOME/src/texlive</code> and unpack it.</p> <p><code>cd</code> into the new directory and run the installer (which is a little perl script).</p> <blockquote> <p>I now customize <em>many</em> of the options. For people who read this that aren't me, I emphasize that my usecase might not be the same as your usecase. Now is an obvious time to deviate from my procedure.</p> </blockquote> <ol> <li>Verify that it detects the correct platform, <code>GNU/Linux on x86_64</code> for me.</li> <li>Change the <code>installation scheme</code> from <code>scheme-full</code> (which takes 8.253GB this year) to <code>custom</code> .</li> <li>Go into the <code>Collections</code> submenu. I default to having too little and then install things later with tlmgr as necessary later. Thus I first <code>deselect all</code>, and then I install exactly three collections: <strong>Essential programs and files</strong>, <strong>LaTeX fundamental packages</strong>, and <strong>XeTeX and packages</strong>.</li> <li>Set the installation directories. I use <code>&dollar;HOME/src/texlive</code> and <em>I do not separate by year.</em> I also set <code>TEXMFHOME</code> to <code>~/.texmf</code> (i.e. I change it to be a hidden file instead of polluting my home directory visibly).</li> <li>I set tex to <strong>use letter size instead of A4 by default</strong>, because I live in the US. I note that I <strong>keep the "install font/macro doc tree" option</strong>, which downloads documentation and which ultimately doubles the size of my installation. I actually read the documentation sometimes. I think this is unusual.</li> <li>Set the installation to proceed.</li> </ol> <p>This year, this apparently uses 557MB of disk space.</p> <p>This led to texlive installing 181 packages (and their commented source and documentation) and took less than 10 minutes.</p> <p>Afterwards, the installer will display a <strong>very important message</strong> about setting MANPATH, INFOPATH, and PATH. In principle I would alter these in my <code>.bashrc</code>, but in practice my previous <code>.bashrc</code> points to these new spots since I'm overwriting where my texlive installation directory.</p> <h2>Remove texlive installer</h2> <p>TeXLive is now installed, so I can remove <code>&dollar;HOME/src/texlive/<texliveinstaller></code>. The exact name is different, depending on the date.</p> <h2>Install utility packages</h2> <p>I use various utilities frequently. I install these with</p> <div class="codehilite"><pre><span></span><code>which tlmgr <span class="c1"># to make sure that new tlmgr is detected</span> tlmgr install latexmk lacheck chktex latexdiff pdfcrop <span class="se">\</span> pdfjam texdiff texdoc </code></pre></div> <p>These are utility packages that are less common. I use <code>lacheck</code> and <code>chktex</code> for latex linting. I use <code>texdoc</code> to see documentation for packages. I use <code>latexmk</code> to handle recompilation. I use the others for various scripts I've written. All of these are tiny.</p> <p>Installation took 31 seconds.</p> <h2>Install specific packages I use</h2> <p>I have four fundamental types of papers that I often compile.</p> <ul> <li>A generic research paper that I might post to the arxiv.</li> <li>Personal notes</li> <li>Public notes</li> <li>Beamer presentations</li> </ul> <p>I have different templates and packages that I use for each of these. I know that I'll make all four again this year and I know exactly which packages they need. I install those now.</p> <div class="codehilite"><pre><span></span><code>tlmgr install setspace mathtools booktabs wrapfig changebar <span class="se">\</span> xcolor lipsum tocloft fancyvrb enumitem threeparttable <span class="se">\</span> beamer beamertheme-metropolis adjustbox pgfopts <span class="se">\</span> xkeyval collectbox <span class="nb">times</span> minted ragged2e multirow </code></pre></div> <p>I made this list a couple of years ago by checking what was necessary to compile a couple specific documents.</p> <p>I install any other package as necessary throughout the year. Right now, my installation uses 706MB.<sup>3</sup> <span class="aside"><sup>3</sup>Wow, that's 150 MB more than my entire distribution last year, including various packages installed throughout the year for ad hoc reasons! I wonder what changed so much. I see that 334MB, which is 73MB more than before.</span></p>https://davidlowryduda.com/another-year-another-texliveMon, 15 Apr 2024 03:14:15 +0000FLT3 at LftCM2024https://davidlowryduda.com/flt3-at-lftcm2024David Lowry-DudaThis post is larger than 10000 bytes, which is above the limit for this RSS feed. Perhaps it is long or has embedded images or code. Please view it directly at the url.https://davidlowryduda.com/flt3-at-lftcm2024Sat, 30 Mar 2024 03:14:15 +0000Quanta on Murmurationshttps://davidlowryduda.com/quanta-on-murmurationsDavid Lowry-Duda<p>Quanta wrote an article <strong>Elliptic Curve 'Murmurations' Found With AI Take Flight</strong> (<a href="https://www.quantamagazine.org/elliptic-curve-murmurations-found-with-ai-take-flight-20240305/">link to article</a>).</p> <p>The article describes some of the story behind the recent <em>murmurations in number theory</em> phenomena that I've been giving talks about. I think it's a pretty well-written article that gives a reasonable overview. Check it out!</p> <p>It touches on <a href="/paper-modular-murmurations/">my recent work</a> with Bober, Booker, and Lee.<span class="aside">If they'd waited a couple of weeks, then they might have been able to include forthcoming work with Booker, Lee, Seymour-Howell, and Zubrilina! But we're a couple of weeks away for that, I think.</span></p> <p>And as far as I see, Quanta is the only outlet (in English) that covers recent research developments in math for a non-specialist audience (<em>pop-math</em>). It's certainly the case that mathematicians aren't doing a particularly job covering our own work in an accessible way.</p>https://davidlowryduda.com/quanta-on-murmurationsTue, 05 Mar 2024 03:14:15 +0000Not quite 3 and a half yearshttps://davidlowryduda.com/three-years-countingDavid Lowry-Duda<h1>Publishing Record</h1> <p>I submitted a paper on 2 September 2020. It was accepted this week, on 17 February 2024.</p> <p><span class="aside">I'm continuing to include more of the tiny evaluations I do <em>all the time</em> with my computing environments. These may be easy manual calculations &mdash; but I've been known to make simple mistakes.</span></p> <div class="codehilite"><pre><span></span><code><span class="kn">from</span> <span class="nn">datetime</span> <span class="kn">import</span> <span class="n">date</span> <span class="kn">from</span> <span class="nn">dateutil.relativedelta</span> <span class="kn">import</span> <span class="n">relativedelta</span> <span class="n">submitted</span> <span class="o">=</span> <span class="n">date</span><span class="p">(</span><span class="mi">2020</span><span class="p">,</span> <span class="mi">9</span><span class="p">,</span> <span class="mi">2</span><span class="p">)</span> <span class="n">accepted</span> <span class="o">=</span> <span class="n">date</span><span class="p">(</span><span class="mi">2024</span><span class="p">,</span> <span class="mi">2</span><span class="p">,</span> <span class="mi">17</span><span class="p">)</span> <span class="nb">print</span><span class="p">(</span><span class="n">accepted</span> <span class="o">-</span> <span class="n">submitted</span><span class="p">)</span> <span class="c1"># &gt;&gt; datetime.timedelta(days=1263)</span> <span class="nb">print</span><span class="p">(</span><span class="n">relativedelta</span><span class="p">(</span><span class="n">accepted</span><span class="p">,</span> <span class="n">submitted</span><span class="p">))</span> <span class="c1"># &gt;&gt; relativedelta(years=+3, months=+5, days=+15)</span> </code></pre></div> <p>That was 1263 days, or 3 years, 5 months, and 15 days. It wasn't quite long enough to include a leapday &mdash; it missed by two weeks.</p> <p>This beats my previous record (of 2 years and 3 months). I too am guilty: during the same time, I took a year to review a paper.</p> <p>This is an annoying aspect of academia and publishing.<sup>1</sup> <span class="aside"><sup>1</sup>At least this isn't one of those stoires where years pass and then the paper is <strong>rejected</strong>. I haven't had that happen, and I haven't done this as a reviewer. But it <em>does</em> happen too.</span></p> <p>I don't think I kept enough records to track my average time from submission to publication. Perhaps I should keep better track and report this on my <a href="/research/">Research</a> page too.</p>https://davidlowryduda.com/three-years-countingWed, 21 Feb 2024 03:14:15 +0000