<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="/output/default.xsl"?>
<fr:tree xmlns:fr="http://www.forester-notes.org" xmlns:html="http://www.w3.org/1999/xhtml" xmlns:xml="http://www.w3.org/XML/1998/namespace" root="true" base-url="/output/">
  <fr:frontmatter>
    <fr:authors>
      <fr:contributor>
        <fr:link href="/output/atifdegirmendzic/" title="Atif Degirmendzic" uri="https://d-atif.github.io/output/atifdegirmendzic/" display-uri="atifdegirmendzic" type="local">Atif Degirmendzic</fr:link>
      </fr:contributor>
    </fr:authors>
    <fr:uri>https://d-atif.github.io/output/index/</fr:uri>
    <fr:display-uri>index</fr:display-uri>
    <fr:route>/output/index/</fr:route>
    <fr:title text="Subtreehouse">Subtreehouse</fr:title>
  </fr:frontmatter>
  <fr:mainmatter><html:p>Yoo</html:p><html:p>Welcome to da forest.</html:p><html:p>Who: <fr:link href="/output/atifdegirmendzic/" title="Atif Degirmendzic" uri="https://d-atif.github.io/output/atifdegirmendzic/" display-uri="atifdegirmendzic" type="local">Atif Degirmendzic</fr:link></html:p><html:p><fr:link href="/output/0001/" title="All the Stuff" uri="https://d-atif.github.io/output/0001/" display-uri="0001" type="local">All the stuff</fr:link></html:p>
    

    <fr:tree show-metadata="false" toc="false" numbered="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/output/atifdegirmendzic/" title="Atif Degirmendzic" uri="https://d-atif.github.io/output/atifdegirmendzic/" display-uri="atifdegirmendzic" type="local">Atif Degirmendzic</fr:link></fr:author></fr:authors><fr:date><fr:year>2026</fr:year><fr:month>6</fr:month><fr:day>15</fr:day></fr:date><fr:uri>https://d-atif.github.io/output/0002/</fr:uri><fr:display-uri>0002</fr:display-uri><fr:route>/output/0002/</fr:route><fr:title text="List of Stuff">List of Stuff</fr:title></fr:frontmatter><fr:mainmatter><html:ul><html:li><fr:tree show-metadata="false" expanded="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/output/atifdegirmendzic/" title="Atif Degirmendzic" uri="https://d-atif.github.io/output/atifdegirmendzic/" display-uri="atifdegirmendzic" type="local">Atif Degirmendzic</fr:link></fr:author></fr:authors><fr:date><fr:year>2026</fr:year><fr:month>7</fr:month><fr:day>3</fr:day></fr:date><fr:uri>https://d-atif.github.io/output/0006/</fr:uri><fr:display-uri>0006</fr:display-uri><fr:route>/output/0006/</fr:route><fr:title text="Intro to Galois theory, part 1: Algebraic (Field) Extensions">Intro to Galois theory, part 1: Algebraic (Field) Extensions</fr:title><fr:taxon>Note</fr:taxon></fr:frontmatter><fr:mainmatter><html:p>
    let me try and summarize the section Algebraic Extensions from Malik's fundamentals of abstract algebra. ill first outline the big picutre: what role this section has in galois theory, then ill focus on the small picture: how do we build (algebraic) extensions of fields.
</html:p><html:p>
    so we are still at the low stages of the theory building that will culminate in galois theory.
</html:p><html:p>
    i find it hard to even start talking about the point of this section without spoiling the point of galois theory, thus mild spoiler alert: 
    
    galois theory gives us something useful about certain posets that we care about. (actually it's not posets but lattices, but close enough). what i will do here is talk about these "posets", the "something useful" part i wont be going into here.
</html:p><html:p>
    we'll be working with fields. instead of saying that "<fr:tex display="inline"><![CDATA[K]]></fr:tex> is a subfield of <fr:tex display="inline"><![CDATA[F]]></fr:tex>", we'll be saying that "<fr:tex display="inline"><![CDATA[F/K]]></fr:tex> is field extension of <fr:tex display="inline"><![CDATA[K]]></fr:tex>". (writing just <fr:tex display="inline"><![CDATA[F/K]]></fr:tex> saves us a lot of time, but there are other benefits). we also read <fr:tex display="inline"><![CDATA[F/K]]></fr:tex> as "<fr:tex display="inline"><![CDATA[F]]></fr:tex> over <fr:tex display="inline"><![CDATA[K]]></fr:tex>". example of usage: "let <fr:tex display="inline"><![CDATA[K]]></fr:tex> be a field and <fr:tex display="inline"><![CDATA[F/K]]></fr:tex> it's extension" = "let <fr:tex display="inline"><![CDATA[K]]></fr:tex> be a field and <fr:tex display="inline"><![CDATA[F]]></fr:tex> a field s.t. <fr:tex display="inline"><![CDATA[K]]></fr:tex> is a subfield of <fr:tex display="inline"><![CDATA[F]]></fr:tex>". the reason this notation makes this reversal is because we will indeed be starting with <fr:tex display="inline"><![CDATA[K]]></fr:tex> and constructing the field <fr:tex display="inline"><![CDATA[F]]></fr:tex> from <fr:tex display="inline"><![CDATA[K]]></fr:tex>; so we ascend from <fr:tex display="inline"><![CDATA[K]]></fr:tex> to <fr:tex display="inline"><![CDATA[F]]></fr:tex>.(spoiler: <fr:tex display="inline"><![CDATA[F]]></fr:tex> will usually be a certain field that we denote with <fr:tex display="inline"><![CDATA[K(c)]]></fr:tex>, which does a better job at hinting that the extension <fr:tex display="inline"><![CDATA[K(c)/K]]></fr:tex> is something that we actually built on top of <fr:tex display="inline"><![CDATA[K]]></fr:tex>)
</html:p><html:p>
    id say the main result of this section was the following: it turns out this "over" relation between <fr:tex display="inline"><![CDATA[F]]></fr:tex> and <fr:tex display="inline"><![CDATA[K]]></fr:tex> is a partial order, even though at this point we don't explicitly frame it that way. same with different words: the "extension" relation induces a poset on <fr:tex display="inline"><![CDATA[\mathcal  P(F)]]></fr:tex>. this is the poset that galois theory works its magic on. (i think this is roughly correct, im writing this for myself mostly so sorry not sorry for misleading stuff.)
</html:p><html:p>
    so what's the deal with this poset? well we care about a specific kind of extension, namely a so called algebraic extension. ok we know <fr:tex display="inline"><![CDATA[F/K]]></fr:tex> means <fr:tex display="inline"><![CDATA[F]]></fr:tex> is an extension of <fr:tex display="inline"><![CDATA[K]]></fr:tex>. we say that <fr:tex display="inline"><![CDATA[F/K]]></fr:tex> is an *algebraic* extension of K if every element in <fr:tex display="inline"><![CDATA[F]]></fr:tex> is algebraic in <fr:tex display="inline"><![CDATA[K]]></fr:tex>. say <fr:tex display="inline"><![CDATA[a \in  F]]></fr:tex> is algebraic in <fr:tex display="inline"><![CDATA[K]]></fr:tex>, that means the following: there's a polynomial <fr:tex display="inline"><![CDATA[p(x) \in  K[x]]]></fr:tex> s.t. <fr:tex display="inline"><![CDATA[p(a) = 0]]></fr:tex>. that's it. a is algebraic iff it's a zero of a polynomial with coefficients in <fr:tex display="inline"><![CDATA[K]]></fr:tex>. so i might've lied earlier (unsure!), it's actually the relation "algebraic extension" that induces our poset, not merely the "over"/"extension" relation.
</html:p><html:p>
    one of the very last theorems we prove is basically transitivity for this relation: Theorem: <fr:tex display="inline"><![CDATA[F/K]]></fr:tex> is  algebraic iff <fr:tex display="inline"><![CDATA[F/L]]></fr:tex> and <fr:tex display="inline"><![CDATA[L/K]]></fr:tex> are algebraic. (i omit the assumption that <fr:tex display="inline"><![CDATA[F/K]]></fr:tex> and <fr:tex display="inline"><![CDATA[L/K]]></fr:tex> are extensions of <fr:tex display="inline"><![CDATA[K]]></fr:tex>, and <fr:tex display="inline"><![CDATA[F/L]]></fr:tex> is an extension of <fr:tex display="inline"><![CDATA[L]]></fr:tex>, thus i say just "algebraic".)
</html:p><html:p>
    what we said so far was contextualization for the big picture. so let me recenter this summary at this point and focus on the small picture of this section. this section is about algebraic elements and about algebraic extensions of fields. say i give you the field <fr:tex display="inline"><![CDATA[\mathbb {Q}]]></fr:tex>, and say you stumble upon the innocent looking polynomial <fr:tex display="inline"><![CDATA[2-x^2=p(x) \in  \mathbb {Q}[x]]]></fr:tex>. you notice that <fr:tex display="inline"><![CDATA[p(\sqrt  2) = 0]]></fr:tex>, but <fr:tex display="inline"><![CDATA[\sqrt  2 \notin  \mathbb {Q}]]></fr:tex>. weird huh. may i suggest extending the field <fr:tex display="inline"><![CDATA[\mathbb {Q}]]></fr:tex> via <fr:tex display="inline"><![CDATA[\sqrt  2]]></fr:tex>, that we just saw is an algebraic element? but how do we do that?
    </html:p><html:p>
     so this section is about how we construct extensions of fields and algebraic extensions in particular. even more particular: it's about *extending* a given field <fr:tex display="inline"><![CDATA[K]]></fr:tex> via an algebraic element <fr:tex display="inline"><![CDATA[c]]></fr:tex>, so we want a field that contains <fr:tex display="inline"><![CDATA[K \uplus  \{c\}]]></fr:tex>.(remember that <fr:tex display="inline"><![CDATA[c]]></fr:tex> is not in <fr:tex display="inline"><![CDATA[K]]></fr:tex>, <fr:tex display="inline"><![CDATA[\sqrt  2]]></fr:tex> was not in <fr:tex display="inline"><![CDATA[\mathbb {Q}]]></fr:tex>; all elements of <fr:tex display="inline"><![CDATA[K]]></fr:tex> are algebraic in <fr:tex display="inline"><![CDATA[K]]></fr:tex> (why? of what polynomials in <fr:tex display="inline"><![CDATA[K]]></fr:tex> are they solutions of?)). this is now the usual situation where <fr:tex display="inline"><![CDATA[\cup ]]></fr:tex> doesn't preserve the algebraic structure, ie <fr:tex display="inline"><![CDATA[K \uplus  \{c\}]]></fr:tex> isn't a field (trust). but using the familiar trick/notation <fr:tex display="inline"><![CDATA[\langle \cdot \rangle ]]></fr:tex> for "generated by", <fr:tex display="inline"><![CDATA[\langle  K \uplus  \{c\}\rangle ]]></fr:tex> is a field that that contains <fr:tex display="inline"><![CDATA[K \uplus  \{c\}]]></fr:tex>. so let's unpack what <fr:tex display="inline"><![CDATA[\langle  K \uplus  \{c\}\rangle ]]></fr:tex> actually is. it's the following thing: <fr:tex display="inline"><![CDATA[\langle  K \uplus  \{c\}\rangle  = \{f(c) : f(x) \in  K[X]\}]]></fr:tex>. and as one might remember, <fr:tex display="inline"><![CDATA[\langle  A\rangle ]]></fr:tex> is the same as the intersection of all fields (or any algebraic structure) that contain the field <fr:tex display="inline"><![CDATA[A]]></fr:tex>, formally: <fr:tex display="inline"><![CDATA[\langle  A\rangle  = \bigcap _{B\supseteq  A} B]]></fr:tex>. connecting this with what we just said we have the following  <fr:tex display="inline"><![CDATA[\bigcap _{F\supseteq  K} F = \langle  K \uplus  \{c\}\rangle  = \{f(c) : f(x) \in  K[X]\}]]></fr:tex>. the meaning of this is that <fr:tex display="inline"><![CDATA[\langle  K \uplus  \{c\}\rangle  = \{f(c) : f(x) \in  K[X]\}]]></fr:tex> is the *smallest* algebraic extension of <fr:tex display="inline"><![CDATA[K]]></fr:tex> via <fr:tex display="inline"><![CDATA[c]]></fr:tex>. and we are glad that it's smallest because any surplus would be expensive, we want to pay only for what we have to pay for; we want to be efficient (see: adjoints wiki, adjoint.tree (coming soon)). this also sheds a very bright ray of light on the purpose of polynomial rings, which i shall say more about later.
    </html:p></fr:mainmatter></fr:tree></html:li>
  <html:li><fr:tree show-metadata="false" expanded="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/output/atifdegirmendzic/" title="Atif Degirmendzic" uri="https://d-atif.github.io/output/atifdegirmendzic/" display-uri="atifdegirmendzic" type="local">Atif Degirmendzic</fr:link></fr:author></fr:authors><fr:date><fr:year>2026</fr:year><fr:month>6</fr:month><fr:day>26</fr:day></fr:date><fr:uri>https://d-atif.github.io/output/0005/</fr:uri><fr:display-uri>0005</fr:display-uri><fr:route>/output/0005/</fr:route><fr:title text="Point free group theory?">Point free group theory?</fr:title><fr:taxon>Thought</fr:taxon></fr:frontmatter><fr:mainmatter><html:p>are there approaches to group theory that are a bit more global in the following sense: in the category set objects are sets. there are no constraints on what a subset (ill call it the substructure) of a set can be, as long as it satisfies the basic definition (contains only some (or all) elements of the parent set). in the category grp, the objects are groups, and we know that the order of the subgroup (subgroups are now the relevant substructure) has to divide the order of the group; however we know this is not sufficient, since no real analogue of lagrange theorem exists. so im wondering if group theory can be built by putting a constraint on what its substructure (subgroup) can be ? are there approaches to group theory like this that are similar in spirit?</html:p><html:p>what kind of category would we get if we just said: cardinality (order) of substructure has to divide the cardinality (order) of parent structure? i assume the category of finite groups would be a "subcategory" of this? has anyone done this? (see: <fr:link href="https://mathoverflow.net/questions/6180/why-are-fusion-categories-interesting" type="external">fusion categories</fr:link>)</html:p><html:p>i really dont know much about it, but this is reminiscent to me of point free topology. is there point free group theory ?</html:p><html:p>(ofc the natural question onward would be: is there point free [insert structure here] theory?)</html:p><html:p>note: this came to mind after a brief convo w Asija, i was trying to explain why being able to see a group G as a subgroup of group of permutations is useful (subgroups divide order etc.)</html:p></fr:mainmatter></fr:tree></html:li>
  <html:li><fr:tree show-metadata="false" expanded="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/output/atifdegirmendzic/" title="Atif Degirmendzic" uri="https://d-atif.github.io/output/atifdegirmendzic/" display-uri="atifdegirmendzic" type="local">Atif Degirmendzic</fr:link></fr:author></fr:authors><fr:date><fr:year>2026</fr:year><fr:month>5</fr:month><fr:day>24</fr:day></fr:date><fr:uri>https://d-atif.github.io/output/0004/</fr:uri><fr:display-uri>0004</fr:display-uri><fr:route>/output/0004/</fr:route><fr:title text="Bethe lattice and tesselations/fundamental polygons">Bethe lattice and tesselations/fundamental polygons</fr:title><fr:taxon>Thought</fr:taxon></fr:frontmatter><fr:mainmatter><html:ul><html:li>is there a manifold that corresponds to a eg <fr:tex display="inline"><![CDATA[2+1]]></fr:tex> regular tree tesellation of the hyperbolic plane? if theres no direct correspondence, is there a way to construct a manifold thats in some way related to the tesselation? (myb take the complement, rotate, glue, remove/add sides in a meaningful way, and so on)</html:li>

<html:li>are there discrete manifolds?</html:li>

<html:li>is there perhaps a correspondence between discrete manifolds and the manifolds that we can (in some sensible way) associate with a <fr:tex display="inline"><![CDATA[q+1]]></fr:tex> tree that tesselates the hyperbolic plane</html:li>

<html:li>can we tesselate hyperbolic plane with <fr:tex display="inline"><![CDATA[\mathbb {Z}]]></fr:tex> ?
    <html:ul><html:li>probably not a tesselation, but. a spiral? 🌀 (tangential stuff below)</html:li>
    <html:li>do we get anything if we try to define a curve as a graph with uncountably many points? or thats how we start, then we impose additional structure on it, that we need ie top and geo structure. question: would the graph aspect perhaps eliminate some pathologies? would it eliminate interesting curves?</html:li></html:ul>

<html:li>can we solve wave equations on those (discrete) manifolds? would it have any connections with the solution of the graph? there is probably patternally similar stuff out there, ie, do something for the object that tesselates (here: our tree; elsewhere: a square, or octagon), you get ~info about the manifold (here:?, elsewhere: torus, 2-torus); euler characteristic is one such thing i think.</html:li>

<html:li>can we solve wave equations on a torus or 2-torus?</html:li>

<html:li>are the wave and heat equations part of some well known class of equations?</html:li>

<html:li>bethe lattices (“occur”) can be viewed as discrete subgroups of fuchsian groups (theyre also lattices in the sense of a lattice in a Lie group). modular group is a fuchsian group. when the modular group acts on <fr:tex display="inline"><![CDATA[\mathbb {H}]]></fr:tex>, it tesselates <fr:tex display="inline"><![CDATA[\mathbb {H}]]></fr:tex>, the orbifold that corresponds to that tesselation was drawn by Lejla… two cusps, infinite neck thing. lets pretend that some bethe lattice corresponds to the modular (fuschsian) group (in worst case scenario, i hope we can find for a specific q a group that yields orbifolds as the modular group does). now, perhaps the corresponding bethe lattice subgroup of the modular group induces a coarser tesselation of the tesselation by the whole modular group. what’s the corresponding orbifold/manifold of that tesselation? let’s solve wave equation on that! and investigate if theres a connection with the kernels of the wave eq on the <fr:tex display="inline"><![CDATA[q+1]]></fr:tex> regular tree <fr:tex display="inline"><![CDATA[T_{q+1}]]></fr:tex></html:li></html:li></html:ul><html:p>problem s ovom pricom je sto (valjda?) obicno korsitimo fundamnetalni poligon da dobijemo info o manifoldu, jer je poligon jednostavniji objekat. ili ipak ide u oba pravca?</html:p></fr:mainmatter></fr:tree></html:li>
  <html:li><fr:tree show-metadata="false" expanded="false"><fr:frontmatter><fr:authors><fr:author><fr:link href="/output/atifdegirmendzic/" title="Atif Degirmendzic" uri="https://d-atif.github.io/output/atifdegirmendzic/" display-uri="atifdegirmendzic" type="local">Atif Degirmendzic</fr:link></fr:author></fr:authors><fr:date><fr:year>2023</fr:year><fr:month>2</fr:month><fr:day>11</fr:day></fr:date><fr:uri>https://d-atif.github.io/output/0003/</fr:uri><fr:display-uri>0003</fr:display-uri><fr:route>/output/0003/</fr:route><fr:title text="Where do ODEs come from?">Where do ODEs come from?</fr:title><fr:taxon>Link</fr:taxon></fr:frontmatter><fr:mainmatter><html:p>See this: <fr:link href="https://youtu.be/B0E0q6ICK3c?si=Q-l8l-j4ORr9qRN9&amp;t=957" type="external">https://youtu.be/B0E0q6ICK3c?si=Q-l8l-j4ORr9qRN9&amp;t=957</fr:link></html:p></fr:mainmatter></fr:tree></html:li></html:ul></fr:mainmatter></fr:tree>
</fr:mainmatter>
  <fr:backmatter>
    <fr:tree show-metadata="false" hidden-when-empty="true">
      <fr:frontmatter>
        <fr:authors />
        <fr:title text="References">References</fr:title>
      </fr:frontmatter>
      <fr:mainmatter />
    </fr:tree>
    <fr:tree show-metadata="false" hidden-when-empty="true">
      <fr:frontmatter>
        <fr:authors />
        <fr:title text="Context">Context</fr:title>
      </fr:frontmatter>
      <fr:mainmatter />
    </fr:tree>
    <fr:tree show-metadata="false" hidden-when-empty="true">
      <fr:frontmatter>
        <fr:authors />
        <fr:title text="Backlinks">Backlinks</fr:title>
      </fr:frontmatter>
      <fr:mainmatter />
    </fr:tree>
    <fr:tree show-metadata="false" hidden-when-empty="true">
      <fr:frontmatter>
        <fr:authors />
        <fr:title text="Related">Related</fr:title>
      </fr:frontmatter>
      <fr:mainmatter>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors>
              <fr:author>
                <fr:link href="/output/atifdegirmendzic/" title="Atif Degirmendzic" uri="https://d-atif.github.io/output/atifdegirmendzic/" display-uri="atifdegirmendzic" type="local">Atif Degirmendzic</fr:link>
              </fr:author>
            </fr:authors>
            <fr:date>
              <fr:year>2026</fr:year>
              <fr:month>6</fr:month>
              <fr:day>15</fr:day>
            </fr:date>
            <fr:uri>https://d-atif.github.io/output/0001/</fr:uri>
            <fr:display-uri>0001</fr:display-uri>
            <fr:route>/output/0001/</fr:route>
            <fr:title text="All the Stuff">All the Stuff</fr:title>
          </fr:frontmatter>
          <fr:mainmatter>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/output/atifdegirmendzic/" title="Atif Degirmendzic" uri="https://d-atif.github.io/output/atifdegirmendzic/" display-uri="atifdegirmendzic" type="local">Atif Degirmendzic</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2026</fr:year>
                  <fr:month>7</fr:month>
                  <fr:day>3</fr:day>
                </fr:date>
                <fr:uri>https://d-atif.github.io/output/0006/</fr:uri>
                <fr:display-uri>0006</fr:display-uri>
                <fr:route>/output/0006/</fr:route>
                <fr:title text="Intro to Galois theory, part 1: Algebraic (Field) Extensions">Intro to Galois theory, part 1: Algebraic (Field) Extensions</fr:title>
                <fr:taxon>Note</fr:taxon>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>
    let me try and summarize the section Algebraic Extensions from Malik's fundamentals of abstract algebra. ill first outline the big picutre: what role this section has in galois theory, then ill focus on the small picture: how do we build (algebraic) extensions of fields.
</html:p>
                <html:p>
    so we are still at the low stages of the theory building that will culminate in galois theory.
</html:p>
                <html:p>
    i find it hard to even start talking about the point of this section without spoiling the point of galois theory, thus mild spoiler alert: 
    
    galois theory gives us something useful about certain posets that we care about. (actually it's not posets but lattices, but close enough). what i will do here is talk about these "posets", the "something useful" part i wont be going into here.
</html:p>
                <html:p>
    we'll be working with fields. instead of saying that "<fr:tex display="inline"><![CDATA[K]]></fr:tex> is a subfield of <fr:tex display="inline"><![CDATA[F]]></fr:tex>", we'll be saying that "<fr:tex display="inline"><![CDATA[F/K]]></fr:tex> is field extension of <fr:tex display="inline"><![CDATA[K]]></fr:tex>". (writing just <fr:tex display="inline"><![CDATA[F/K]]></fr:tex> saves us a lot of time, but there are other benefits). we also read <fr:tex display="inline"><![CDATA[F/K]]></fr:tex> as "<fr:tex display="inline"><![CDATA[F]]></fr:tex> over <fr:tex display="inline"><![CDATA[K]]></fr:tex>". example of usage: "let <fr:tex display="inline"><![CDATA[K]]></fr:tex> be a field and <fr:tex display="inline"><![CDATA[F/K]]></fr:tex> it's extension" = "let <fr:tex display="inline"><![CDATA[K]]></fr:tex> be a field and <fr:tex display="inline"><![CDATA[F]]></fr:tex> a field s.t. <fr:tex display="inline"><![CDATA[K]]></fr:tex> is a subfield of <fr:tex display="inline"><![CDATA[F]]></fr:tex>". the reason this notation makes this reversal is because we will indeed be starting with <fr:tex display="inline"><![CDATA[K]]></fr:tex> and constructing the field <fr:tex display="inline"><![CDATA[F]]></fr:tex> from <fr:tex display="inline"><![CDATA[K]]></fr:tex>; so we ascend from <fr:tex display="inline"><![CDATA[K]]></fr:tex> to <fr:tex display="inline"><![CDATA[F]]></fr:tex>.(spoiler: <fr:tex display="inline"><![CDATA[F]]></fr:tex> will usually be a certain field that we denote with <fr:tex display="inline"><![CDATA[K(c)]]></fr:tex>, which does a better job at hinting that the extension <fr:tex display="inline"><![CDATA[K(c)/K]]></fr:tex> is something that we actually built on top of <fr:tex display="inline"><![CDATA[K]]></fr:tex>)
</html:p>
                <html:p>
    id say the main result of this section was the following: it turns out this "over" relation between <fr:tex display="inline"><![CDATA[F]]></fr:tex> and <fr:tex display="inline"><![CDATA[K]]></fr:tex> is a partial order, even though at this point we don't explicitly frame it that way. same with different words: the "extension" relation induces a poset on <fr:tex display="inline"><![CDATA[\mathcal  P(F)]]></fr:tex>. this is the poset that galois theory works its magic on. (i think this is roughly correct, im writing this for myself mostly so sorry not sorry for misleading stuff.)
</html:p>
                <html:p>
    so what's the deal with this poset? well we care about a specific kind of extension, namely a so called algebraic extension. ok we know <fr:tex display="inline"><![CDATA[F/K]]></fr:tex> means <fr:tex display="inline"><![CDATA[F]]></fr:tex> is an extension of <fr:tex display="inline"><![CDATA[K]]></fr:tex>. we say that <fr:tex display="inline"><![CDATA[F/K]]></fr:tex> is an *algebraic* extension of K if every element in <fr:tex display="inline"><![CDATA[F]]></fr:tex> is algebraic in <fr:tex display="inline"><![CDATA[K]]></fr:tex>. say <fr:tex display="inline"><![CDATA[a \in  F]]></fr:tex> is algebraic in <fr:tex display="inline"><![CDATA[K]]></fr:tex>, that means the following: there's a polynomial <fr:tex display="inline"><![CDATA[p(x) \in  K[x]]]></fr:tex> s.t. <fr:tex display="inline"><![CDATA[p(a) = 0]]></fr:tex>. that's it. a is algebraic iff it's a zero of a polynomial with coefficients in <fr:tex display="inline"><![CDATA[K]]></fr:tex>. so i might've lied earlier (unsure!), it's actually the relation "algebraic extension" that induces our poset, not merely the "over"/"extension" relation.
</html:p>
                <html:p>
    one of the very last theorems we prove is basically transitivity for this relation: Theorem: <fr:tex display="inline"><![CDATA[F/K]]></fr:tex> is  algebraic iff <fr:tex display="inline"><![CDATA[F/L]]></fr:tex> and <fr:tex display="inline"><![CDATA[L/K]]></fr:tex> are algebraic. (i omit the assumption that <fr:tex display="inline"><![CDATA[F/K]]></fr:tex> and <fr:tex display="inline"><![CDATA[L/K]]></fr:tex> are extensions of <fr:tex display="inline"><![CDATA[K]]></fr:tex>, and <fr:tex display="inline"><![CDATA[F/L]]></fr:tex> is an extension of <fr:tex display="inline"><![CDATA[L]]></fr:tex>, thus i say just "algebraic".)
</html:p>
                <html:p>
    what we said so far was contextualization for the big picture. so let me recenter this summary at this point and focus on the small picture of this section. this section is about algebraic elements and about algebraic extensions of fields. say i give you the field <fr:tex display="inline"><![CDATA[\mathbb {Q}]]></fr:tex>, and say you stumble upon the innocent looking polynomial <fr:tex display="inline"><![CDATA[2-x^2=p(x) \in  \mathbb {Q}[x]]]></fr:tex>. you notice that <fr:tex display="inline"><![CDATA[p(\sqrt  2) = 0]]></fr:tex>, but <fr:tex display="inline"><![CDATA[\sqrt  2 \notin  \mathbb {Q}]]></fr:tex>. weird huh. may i suggest extending the field <fr:tex display="inline"><![CDATA[\mathbb {Q}]]></fr:tex> via <fr:tex display="inline"><![CDATA[\sqrt  2]]></fr:tex>, that we just saw is an algebraic element? but how do we do that?
    </html:p>
                <html:p>
     so this section is about how we construct extensions of fields and algebraic extensions in particular. even more particular: it's about *extending* a given field <fr:tex display="inline"><![CDATA[K]]></fr:tex> via an algebraic element <fr:tex display="inline"><![CDATA[c]]></fr:tex>, so we want a field that contains <fr:tex display="inline"><![CDATA[K \uplus  \{c\}]]></fr:tex>.(remember that <fr:tex display="inline"><![CDATA[c]]></fr:tex> is not in <fr:tex display="inline"><![CDATA[K]]></fr:tex>, <fr:tex display="inline"><![CDATA[\sqrt  2]]></fr:tex> was not in <fr:tex display="inline"><![CDATA[\mathbb {Q}]]></fr:tex>; all elements of <fr:tex display="inline"><![CDATA[K]]></fr:tex> are algebraic in <fr:tex display="inline"><![CDATA[K]]></fr:tex> (why? of what polynomials in <fr:tex display="inline"><![CDATA[K]]></fr:tex> are they solutions of?)). this is now the usual situation where <fr:tex display="inline"><![CDATA[\cup ]]></fr:tex> doesn't preserve the algebraic structure, ie <fr:tex display="inline"><![CDATA[K \uplus  \{c\}]]></fr:tex> isn't a field (trust). but using the familiar trick/notation <fr:tex display="inline"><![CDATA[\langle \cdot \rangle ]]></fr:tex> for "generated by", <fr:tex display="inline"><![CDATA[\langle  K \uplus  \{c\}\rangle ]]></fr:tex> is a field that that contains <fr:tex display="inline"><![CDATA[K \uplus  \{c\}]]></fr:tex>. so let's unpack what <fr:tex display="inline"><![CDATA[\langle  K \uplus  \{c\}\rangle ]]></fr:tex> actually is. it's the following thing: <fr:tex display="inline"><![CDATA[\langle  K \uplus  \{c\}\rangle  = \{f(c) : f(x) \in  K[X]\}]]></fr:tex>. and as one might remember, <fr:tex display="inline"><![CDATA[\langle  A\rangle ]]></fr:tex> is the same as the intersection of all fields (or any algebraic structure) that contain the field <fr:tex display="inline"><![CDATA[A]]></fr:tex>, formally: <fr:tex display="inline"><![CDATA[\langle  A\rangle  = \bigcap _{B\supseteq  A} B]]></fr:tex>. connecting this with what we just said we have the following  <fr:tex display="inline"><![CDATA[\bigcap _{F\supseteq  K} F = \langle  K \uplus  \{c\}\rangle  = \{f(c) : f(x) \in  K[X]\}]]></fr:tex>. the meaning of this is that <fr:tex display="inline"><![CDATA[\langle  K \uplus  \{c\}\rangle  = \{f(c) : f(x) \in  K[X]\}]]></fr:tex> is the *smallest* algebraic extension of <fr:tex display="inline"><![CDATA[K]]></fr:tex> via <fr:tex display="inline"><![CDATA[c]]></fr:tex>. and we are glad that it's smallest because any surplus would be expensive, we want to pay only for what we have to pay for; we want to be efficient (see: adjoints wiki, adjoint.tree (coming soon)). this also sheds a very bright ray of light on the purpose of polynomial rings, which i shall say more about later.
    </html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/output/atifdegirmendzic/" title="Atif Degirmendzic" uri="https://d-atif.github.io/output/atifdegirmendzic/" display-uri="atifdegirmendzic" type="local">Atif Degirmendzic</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2026</fr:year>
                  <fr:month>6</fr:month>
                  <fr:day>26</fr:day>
                </fr:date>
                <fr:uri>https://d-atif.github.io/output/0005/</fr:uri>
                <fr:display-uri>0005</fr:display-uri>
                <fr:route>/output/0005/</fr:route>
                <fr:title text="Point free group theory?">Point free group theory?</fr:title>
                <fr:taxon>Thought</fr:taxon>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>are there approaches to group theory that are a bit more global in the following sense: in the category set objects are sets. there are no constraints on what a subset (ill call it the substructure) of a set can be, as long as it satisfies the basic definition (contains only some (or all) elements of the parent set). in the category grp, the objects are groups, and we know that the order of the subgroup (subgroups are now the relevant substructure) has to divide the order of the group; however we know this is not sufficient, since no real analogue of lagrange theorem exists. so im wondering if group theory can be built by putting a constraint on what its substructure (subgroup) can be ? are there approaches to group theory like this that are similar in spirit?</html:p>
                <html:p>what kind of category would we get if we just said: cardinality (order) of substructure has to divide the cardinality (order) of parent structure? i assume the category of finite groups would be a "subcategory" of this? has anyone done this? (see: <fr:link href="https://mathoverflow.net/questions/6180/why-are-fusion-categories-interesting" type="external">fusion categories</fr:link>)</html:p>
                <html:p>i really dont know much about it, but this is reminiscent to me of point free topology. is there point free group theory ?</html:p>
                <html:p>(ofc the natural question onward would be: is there point free [insert structure here] theory?)</html:p>
                <html:p>note: this came to mind after a brief convo w Asija, i was trying to explain why being able to see a group G as a subgroup of group of permutations is useful (subgroups divide order etc.)</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/output/atifdegirmendzic/" title="Atif Degirmendzic" uri="https://d-atif.github.io/output/atifdegirmendzic/" display-uri="atifdegirmendzic" type="local">Atif Degirmendzic</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2026</fr:year>
                  <fr:month>5</fr:month>
                  <fr:day>24</fr:day>
                </fr:date>
                <fr:uri>https://d-atif.github.io/output/0004/</fr:uri>
                <fr:display-uri>0004</fr:display-uri>
                <fr:route>/output/0004/</fr:route>
                <fr:title text="Bethe lattice and tesselations/fundamental polygons">Bethe lattice and tesselations/fundamental polygons</fr:title>
                <fr:taxon>Thought</fr:taxon>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:ul><html:li>is there a manifold that corresponds to a eg <fr:tex display="inline"><![CDATA[2+1]]></fr:tex> regular tree tesellation of the hyperbolic plane? if theres no direct correspondence, is there a way to construct a manifold thats in some way related to the tesselation? (myb take the complement, rotate, glue, remove/add sides in a meaningful way, and so on)</html:li>

<html:li>are there discrete manifolds?</html:li>

<html:li>is there perhaps a correspondence between discrete manifolds and the manifolds that we can (in some sensible way) associate with a <fr:tex display="inline"><![CDATA[q+1]]></fr:tex> tree that tesselates the hyperbolic plane</html:li>

<html:li>can we tesselate hyperbolic plane with <fr:tex display="inline"><![CDATA[\mathbb {Z}]]></fr:tex> ?
    <html:ul><html:li>probably not a tesselation, but. a spiral? 🌀 (tangential stuff below)</html:li>
    <html:li>do we get anything if we try to define a curve as a graph with uncountably many points? or thats how we start, then we impose additional structure on it, that we need ie top and geo structure. question: would the graph aspect perhaps eliminate some pathologies? would it eliminate interesting curves?</html:li></html:ul>

<html:li>can we solve wave equations on those (discrete) manifolds? would it have any connections with the solution of the graph? there is probably patternally similar stuff out there, ie, do something for the object that tesselates (here: our tree; elsewhere: a square, or octagon), you get ~info about the manifold (here:?, elsewhere: torus, 2-torus); euler characteristic is one such thing i think.</html:li>

<html:li>can we solve wave equations on a torus or 2-torus?</html:li>

<html:li>are the wave and heat equations part of some well known class of equations?</html:li>

<html:li>bethe lattices (“occur”) can be viewed as discrete subgroups of fuchsian groups (theyre also lattices in the sense of a lattice in a Lie group). modular group is a fuchsian group. when the modular group acts on <fr:tex display="inline"><![CDATA[\mathbb {H}]]></fr:tex>, it tesselates <fr:tex display="inline"><![CDATA[\mathbb {H}]]></fr:tex>, the orbifold that corresponds to that tesselation was drawn by Lejla… two cusps, infinite neck thing. lets pretend that some bethe lattice corresponds to the modular (fuschsian) group (in worst case scenario, i hope we can find for a specific q a group that yields orbifolds as the modular group does). now, perhaps the corresponding bethe lattice subgroup of the modular group induces a coarser tesselation of the tesselation by the whole modular group. what’s the corresponding orbifold/manifold of that tesselation? let’s solve wave equation on that! and investigate if theres a connection with the kernels of the wave eq on the <fr:tex display="inline"><![CDATA[q+1]]></fr:tex> regular tree <fr:tex display="inline"><![CDATA[T_{q+1}]]></fr:tex></html:li></html:li></html:ul>
                <html:p>problem s ovom pricom je sto (valjda?) obicno korsitimo fundamnetalni poligon da dobijemo info o manifoldu, jer je poligon jednostavniji objekat. ili ipak ide u oba pravca?</html:p>
              </fr:mainmatter>
            </fr:tree>
            <fr:tree show-metadata="false">
              <fr:frontmatter>
                <fr:authors>
                  <fr:author>
                    <fr:link href="/output/atifdegirmendzic/" title="Atif Degirmendzic" uri="https://d-atif.github.io/output/atifdegirmendzic/" display-uri="atifdegirmendzic" type="local">Atif Degirmendzic</fr:link>
                  </fr:author>
                </fr:authors>
                <fr:date>
                  <fr:year>2023</fr:year>
                  <fr:month>2</fr:month>
                  <fr:day>11</fr:day>
                </fr:date>
                <fr:uri>https://d-atif.github.io/output/0003/</fr:uri>
                <fr:display-uri>0003</fr:display-uri>
                <fr:route>/output/0003/</fr:route>
                <fr:title text="Where do ODEs come from?">Where do ODEs come from?</fr:title>
                <fr:taxon>Link</fr:taxon>
              </fr:frontmatter>
              <fr:mainmatter>
                <html:p>See this: <fr:link href="https://youtu.be/B0E0q6ICK3c?si=Q-l8l-j4ORr9qRN9&amp;t=957" type="external">https://youtu.be/B0E0q6ICK3c?si=Q-l8l-j4ORr9qRN9&amp;t=957</fr:link></html:p>
              </fr:mainmatter>
            </fr:tree>
          </fr:mainmatter>
        </fr:tree>
        <fr:tree show-metadata="true" expanded="false" toc="false" numbered="false">
          <fr:frontmatter>
            <fr:authors />
            <fr:uri>https://d-atif.github.io/output/atifdegirmendzic/</fr:uri>
            <fr:display-uri>atifdegirmendzic</fr:display-uri>
            <fr:route>/output/atifdegirmendzic/</fr:route>
            <fr:title text="Atif Degirmendzic">Atif Degirmendzic</fr:title>
            <fr:taxon>Person</fr:taxon>
            <fr:meta name="external">https://d-atif.github.io</fr:meta>
            <fr:meta name="institution">PMF</fr:meta>
            <fr:meta name="position">Student</fr:meta>
          </fr:frontmatter>
          <fr:mainmatter />
        </fr:tree>
      </fr:mainmatter>
    </fr:tree>
    <fr:tree show-metadata="false" hidden-when-empty="true">
      <fr:frontmatter>
        <fr:authors />
        <fr:title text="Contributions">Contributions</fr:title>
      </fr:frontmatter>
      <fr:mainmatter />
    </fr:tree>
  </fr:backmatter>
</fr:tree>
