<?xml version="1.0" encoding="UTF-8"?>
<OAI-PMH xmlns="http://www.openarchives.org/OAI/2.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd">
  <responseDate>2026-08-21T18:34:51Z</responseDate>
  <request identifier="27438" metadataPrefix="oai_dc" verb="GetRecord">https://drops.dagstuhl.de/oai</request>
  <GetRecord>
    <record>
      <header>
        <identifier>oai:drops-oai.dagstuhl.de:27438</identifier>
        <datestamp>2026-08-21T14:42:40Z</datestamp>
        <setSpec>ddc:004</setSpec>
        <setSpec>open_access</setSpec>
      </header>
      <metadata>
        <oai_dc:dc xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/oai_dc/ http://www.openarchives.org/OAI/2.0/oai_dc.xsd">
          <dc:title>Maximum Matchings and Short Voting Paths</dc:title>
          <dc:creator>Kavitha, Telikepalli</dc:creator>
          <dc:subject>Bipartite graphs</dc:subject>
          <dc:subject>Fractional matchings</dc:subject>
          <dc:subject>Polytopes</dc:subject>
          <dc:subject>LP duality</dc:subject>
          <dc:description>Our input is a marriage instance G = (A ∪ B, E), i.e., it is a bipartite graph where every vertex has strict preferences over its neighbors. The preferences that a vertex has on its neighbors extend naturally to preferences over matchings. A maximum matching M that does not lose an election against any maximum matching (where vertices cast votes) is a popular maximum-matching. These matchings are useful in practice - they always exist and can be efficiently computed [Kavitha, SICOMP 2014]. Suppose preferences change; then the problem is to update the current matching M_0 via a short voting path to a popular maximum-matching, where a length-𝓁 voting path from M_0 to M_𝓁 is a sequence of maximum matchings ⟨M_0,M_1,…,M_𝓁⟩ such that each matching is more popular than its predecessor. There are maximum matchings from which there is no voting path (of any length) to a popular maximum-matching [Bhattacharya et al., ICALP 2015]. &#13;
We show a polynomial-time algorithm to decide if there exists a short voting path, i.e. one of length ≤ 2, from a given maximum matching to a popular maximum-matching and find one, if so. Voting paths motivate natural relaxations of popularity: pseudo-popular maximum-matchings and mostly-popular maximum-matchings; these yield more egalitarian or optimal solutions than popular maximum-matchings. We show polynomial-time algorithms to compute such optimal solutions that go beyond popularity. In particular, we give a combinatorial characterization of pseudo-popular maximum-matchings in terms of forced vertices and forbidden edges. We also show a polynomial-time algorithm to compute at most |E| = m popular maximum-matchings such that any maximum matching that loses to some popular maximum-matching loses to at least one of these m matchings.</dc:description>
          <dc:publisher>Schloss Dagstuhl – Leibniz-Zentrum für Informatik</dc:publisher>
          <dc:contributor>Telikepalli Kavitha</dc:contributor>
          <dc:date>2026</dc:date>
          <dc:relation>Is Part Of LIPIcs, Volume 386, 51st International Symposium on Mathematical Foundations of Computer Science (MFCS 2026)</dc:relation>
          <dc:type>InProceedings</dc:type>
          <dc:type>Text</dc:type>
          <dc:type>doc-type:ResearchArticle</dc:type>
          <dc:type>publishedVersion</dc:type>
          <dc:format>application/pdf</dc:format>
          <dc:identifier>doi:10.4230/LIPIcs.MFCS.2026.56</dc:identifier>
          <dc:identifier>urn:nbn:de:0030-drops-274380</dc:identifier>
          <dc:identifier>https://drops.dagstuhl.de/entities/document/10.4230/LIPIcs.MFCS.2026.56</dc:identifier>
          <dc:language>eng</dc:language>
          <dc:rights>https://creativecommons.org/licenses/by/4.0/legalcode</dc:rights>
        </oai_dc:dc>
      </metadata>
    </record>
  </GetRecord>
</OAI-PMH>
