Redesign to support other scoring methods #2525
Labels
Comments
|
Some comments/questions for this:
|
|
Some thoughts here:
|
|
Hi! |
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 2, 2025
First step of DOMjudge#2525.
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 2, 2025
First step of DOMjudge#2525.
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 2, 2025
First step of DOMjudge#2525.
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 2, 2025
First step of DOMjudge#2525.
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 2, 2025
First step of DOMjudge#2525.
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 9, 2025
Progress towards DOMjudge#2525. The basic idea is to replace a lot of scattered scoring logic (which might become more complex) with encoding enough information in the rank cache. The information is encoded in a sort key that can be sorted descendingly. The sort key is a tuple (serialized as string into the database) of fixed precision decimals. Each tuple is using 9 decimals and left padded with `0`s, so it's sortable via normal DB query operations. If sorted ascending (e.g. penalty time), then we subtract from a very large number. For example, with ICPC scoring, the top 2 teams from NWERC 2024 gets these sort keys: ``` 00000000000000000000013.000000000,999999999999999999998725.000000000,999999999999999999999711.000000000 00000000000000000000011.000000000,999999999999999999998918.000000000,999999999999999999999701.000000000 ``` With this mechanism, we should be able to implement other planned scoring methods (in particular partial scoring, optimization problems) without too much complication on the business logic side. We do use `bcmath` with fixed precision to not run into numerical precision issues with sequencing floating point operations. This is not important today, but will become important once we deall with non-integers (e.g. for optimization problems). It also caches some computation and makes scoreboard computation more efficient today.
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 14, 2025
Progress towards DOMjudge#2525. The basic idea is to replace a lot of scattered scoring logic (which might become more complex) with encoding enough information in the rank cache. The information is encoded in a sort key that can be sorted descendingly. The sort key is a tuple (serialized as string into the database) of fixed precision decimals. Each tuple is using 9 decimals and left padded with `0`s, so it's sortable via normal DB query operations. If sorted ascending (e.g. penalty time), then we subtract from a very large number. For example, with ICPC scoring, the top 2 teams from NWERC 2024 gets these sort keys: ``` 00000000000000000000013.000000000,999999999999999999998725.000000000,999999999999999999999711.000000000 00000000000000000000011.000000000,999999999999999999998918.000000000,999999999999999999999701.000000000 ``` With this mechanism, we should be able to implement other planned scoring methods (in particular partial scoring, optimization problems) without too much complication on the business logic side. We do use `bcmath` with fixed precision to not run into numerical precision issues with sequencing floating point operations. This is not important today, but will become important once we deall with non-integers (e.g. for optimization problems). It also caches some computation and makes scoreboard computation more efficient today.
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 14, 2025
Progress towards DOMjudge#2525. The basic idea is to replace a lot of scattered scoring logic (which might become more complex) with encoding enough information in the rank cache. The information is encoded in a sort key that can be sorted descendingly. The sort key is a tuple (serialized as string into the database) of fixed precision decimals. Each tuple is using 9 decimals and left padded with `0`s, so it's sortable via normal DB query operations. If sorted ascending (e.g. penalty time), then we subtract from a very large number. For example, with ICPC scoring, the top 2 teams from NWERC 2024 gets these sort keys: ``` 00000000000000000000013.000000000,999999999999999999998725.000000000,999999999999999999999711.000000000 00000000000000000000011.000000000,999999999999999999998918.000000000,999999999999999999999701.000000000 ``` With this mechanism, we should be able to implement other planned scoring methods (in particular partial scoring, optimization problems) without too much complication on the business logic side. We do use `bcmath` with fixed precision to not run into numerical precision issues with sequencing floating point operations. This is not important today, but will become important once we deall with non-integers (e.g. for optimization problems). It also caches some computation and makes scoreboard computation more efficient today.
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 14, 2025
Progress towards DOMjudge#2525. The basic idea is to replace a lot of scattered scoring logic (which might become more complex) with encoding enough information in the rank cache. The information is encoded in a sort key that can be sorted descendingly. The sort key is a tuple (serialized as string into the database) of fixed precision decimals. Each tuple is using 9 decimals and left padded with `0`s, so it's sortable via normal DB query operations. If sorted ascending (e.g. penalty time), then we subtract from a very large number. For example, with ICPC scoring, the top 2 teams from NWERC 2024 gets these sort keys: ``` 00000000000000000000013.000000000,999999999999999999998725.000000000,999999999999999999999711.000000000 00000000000000000000011.000000000,999999999999999999998918.000000000,999999999999999999999701.000000000 ``` With this mechanism, we should be able to implement other planned scoring methods (in particular partial scoring, optimization problems) without too much complication on the business logic side. We do use `bcmath` with fixed precision to not run into numerical precision issues with sequencing floating point operations. This is not important today, but will become important once we deall with non-integers (e.g. for optimization problems). It also caches some computation and makes scoreboard computation more efficient today.
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 14, 2025
Progress towards DOMjudge#2525. The basic idea is to replace a lot of scattered scoring logic (which might become more complex) with encoding enough information in the rank cache. The information is encoded in a sort key that can be sorted descendingly. The sort key is a tuple (serialized as string into the database) of fixed precision decimals. Each tuple is using 9 decimals and left padded with `0`s, so it's sortable via normal DB query operations. If sorted ascending (e.g. penalty time), then we subtract from a very large number. For example, with ICPC scoring, the top 2 teams from NWERC 2024 gets these sort keys: ``` 00000000000000000000013.000000000,999999999999999999998725.000000000,999999999999999999999711.000000000 00000000000000000000011.000000000,999999999999999999998918.000000000,999999999999999999999701.000000000 ``` With this mechanism, we should be able to implement other planned scoring methods (in particular partial scoring, optimization problems) without too much complication on the business logic side. We do use `bcmath` with fixed precision to not run into numerical precision issues with sequencing floating point operations. This is not important today, but will become important once we deall with non-integers (e.g. for optimization problems). It also caches some computation and makes scoreboard computation more efficient today.
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 14, 2025
Progress towards DOMjudge#2525. The basic idea is to replace a lot of scattered scoring logic (which might become more complex) with encoding enough information in the rank cache. The information is encoded in a sort key that can be sorted descendingly. The sort key is a tuple (serialized as string into the database) of fixed precision decimals. Each tuple is using 9 decimals and left padded with `0`s, so it's sortable via normal DB query operations. If sorted ascending (e.g. penalty time), then we subtract from a very large number. For example, with ICPC scoring, the top 2 teams from NWERC 2024 gets these sort keys: ``` 00000000000000000000013.000000000,999999999999999999998725.000000000,999999999999999999999711.000000000 00000000000000000000011.000000000,999999999999999999998918.000000000,999999999999999999999701.000000000 ``` With this mechanism, we should be able to implement other planned scoring methods (in particular partial scoring, optimization problems) without too much complication on the business logic side. We do use `bcmath` with fixed precision to not run into numerical precision issues with sequencing floating point operations. This is not important today, but will become important once we deall with non-integers (e.g. for optimization problems). It also caches some computation and makes scoreboard computation more efficient today.
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 14, 2025
Progress towards DOMjudge#2525. The basic idea is to replace a lot of scattered scoring logic (which might become more complex) with encoding enough information in the rank cache. The information is encoded in a sort key that can be sorted descendingly. The sort key is a tuple (serialized as string into the database) of fixed precision decimals. Each tuple is using 9 decimals and left padded with `0`s, so it's sortable via normal DB query operations. If sorted ascending (e.g. penalty time), then we subtract from a very large number. For example, with ICPC scoring, the top 2 teams from NWERC 2024 gets these sort keys: ``` 00000000000000000000013.000000000,999999999999999999998725.000000000,999999999999999999999711.000000000 00000000000000000000011.000000000,999999999999999999998918.000000000,999999999999999999999701.000000000 ``` With this mechanism, we should be able to implement other planned scoring methods (in particular partial scoring, optimization problems) without too much complication on the business logic side. We do use `bcmath` with fixed precision to not run into numerical precision issues with sequencing floating point operations. This is not important today, but will become important once we deall with non-integers (e.g. for optimization problems). It also caches some computation and makes scoreboard computation more efficient today.
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 14, 2025
Progress towards DOMjudge#2525. The basic idea is to replace a lot of scattered scoring logic (which might become more complex) with encoding enough information in the rank cache. The information is encoded in a sort key that can be sorted descendingly. The sort key is a tuple (serialized as string into the database) of fixed precision decimals. Each tuple is using 9 decimals and left padded with `0`s, so it's sortable via normal DB query operations. If sorted ascending (e.g. penalty time), then we subtract from a very large number. For example, with ICPC scoring, the top 2 teams from NWERC 2024 gets these sort keys: ``` 00000000000000000000013.000000000,999999999999999999998725.000000000,999999999999999999999711.000000000 00000000000000000000011.000000000,999999999999999999998918.000000000,999999999999999999999701.000000000 ``` With this mechanism, we should be able to implement other planned scoring methods (in particular partial scoring, optimization problems) without too much complication on the business logic side. We do use `bcmath` with fixed precision to not run into numerical precision issues with sequencing floating point operations. This is not important today, but will become important once we deall with non-integers (e.g. for optimization problems). It also caches some computation and makes scoreboard computation more efficient today.
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 15, 2025
Progress towards DOMjudge#2525. The basic idea is to replace a lot of scattered scoring logic (which might become more complex) with encoding enough information in the rank cache. The information is encoded in a sort key that can be sorted descendingly. The sort key is a tuple (serialized as string into the database) of fixed precision decimals. Each tuple is using 9 decimals and left padded with `0`s, so it's sortable via normal DB query operations. If sorted ascending (e.g. penalty time), then we subtract from a very large number. For example, with ICPC scoring, the top 2 teams from NWERC 2024 gets these sort keys: ``` 00000000000000000000013.000000000,999999999999999999998725.000000000,999999999999999999999711.000000000 00000000000000000000011.000000000,999999999999999999998918.000000000,999999999999999999999701.000000000 ``` With this mechanism, we should be able to implement other planned scoring methods (in particular partial scoring, optimization problems) without too much complication on the business logic side. We do use `bcmath` with fixed precision to not run into numerical precision issues with sequencing floating point operations. This is not important today, but will become important once we deall with non-integers (e.g. for optimization problems). It also caches some computation and makes scoreboard computation more efficient today.
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 15, 2025
Progress towards DOMjudge#2525. The basic idea is to replace a lot of scattered scoring logic (which might become more complex) with encoding enough information in the rank cache. The information is encoded in a sort key that can be sorted descendingly. The sort key is a tuple (serialized as string into the database) of fixed precision decimals. Each tuple is using 9 decimals and left padded with `0`s, so it's sortable via normal DB query operations. If sorted ascending (e.g. penalty time), then we subtract from a very large number. For example, with ICPC scoring, the top 2 teams from NWERC 2024 gets these sort keys: ``` 00000000000000000000013.000000000,999999999999999999998725.000000000,999999999999999999999711.000000000 00000000000000000000011.000000000,999999999999999999998918.000000000,999999999999999999999701.000000000 ``` With this mechanism, we should be able to implement other planned scoring methods (in particular partial scoring, optimization problems) without too much complication on the business logic side. We do use `bcmath` with fixed precision to not run into numerical precision issues with sequencing floating point operations. This is not important today, but will become important once we deall with non-integers (e.g. for optimization problems). It also caches some computation and makes scoreboard computation more efficient today.
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 15, 2025
Progress towards DOMjudge#2525. The basic idea is to replace a lot of scattered scoring logic (which might become more complex) with encoding enough information in the rank cache. The information is encoded in a sort key that can be sorted descendingly. The sort key is a tuple (serialized as string into the database) of fixed precision decimals. Each tuple is using 9 decimals and left padded with `0`s, so it's sortable via normal DB query operations. If sorted ascending (e.g. penalty time), then we subtract from a very large number. For example, with ICPC scoring, the top 2 teams from NWERC 2024 gets these sort keys: ``` 00000000000000000000013.000000000,999999999999999999998725.000000000,999999999999999999999711.000000000 00000000000000000000011.000000000,999999999999999999998918.000000000,999999999999999999999701.000000000 ``` With this mechanism, we should be able to implement other planned scoring methods (in particular partial scoring, optimization problems) without too much complication on the business logic side. We do use `bcmath` with fixed precision to not run into numerical precision issues with sequencing floating point operations. This is not important today, but will become important once we deall with non-integers (e.g. for optimization problems). It also caches some computation and makes scoreboard computation more efficient today.
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 15, 2025
Progress towards DOMjudge#2525. The basic idea is to replace a lot of scattered scoring logic (which might become more complex) with encoding enough information in the rank cache. The information is encoded in a sort key that can be sorted descendingly. The sort key is a tuple (serialized as string into the database) of fixed precision decimals. Each tuple is using 9 decimals and left padded with `0`s, so it's sortable via normal DB query operations. If sorted ascending (e.g. penalty time), then we subtract from a very large number. For example, with ICPC scoring, the top 2 teams from NWERC 2024 gets these sort keys: ``` 00000000000000000000013.000000000,999999999999999999998725.000000000,999999999999999999999711.000000000 00000000000000000000011.000000000,999999999999999999998918.000000000,999999999999999999999701.000000000 ``` With this mechanism, we should be able to implement other planned scoring methods (in particular partial scoring, optimization problems) without too much complication on the business logic side. We do use `bcmath` with fixed precision to not run into numerical precision issues with sequencing floating point operations. This is not important today, but will become important once we deall with non-integers (e.g. for optimization problems). It also caches some computation and makes scoreboard computation more efficient today.
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 15, 2025
Progress towards DOMjudge#2525. The basic idea is to replace a lot of scattered scoring logic (which might become more complex) with encoding enough information in the rank cache. The information is encoded in a sort key that can be sorted descendingly. The sort key is a tuple (serialized as string into the database) of fixed precision decimals. Each tuple is using 9 decimals and left padded with `0`s, so it's sortable via normal DB query operations. If sorted ascending (e.g. penalty time), then we subtract from a very large number. For example, with ICPC scoring, the top 2 teams from NWERC 2024 gets these sort keys: ``` 00000000000000000000013.000000000,999999999999999999998725.000000000,999999999999999999999711.000000000 00000000000000000000011.000000000,999999999999999999998918.000000000,999999999999999999999701.000000000 ``` With this mechanism, we should be able to implement other planned scoring methods (in particular partial scoring, optimization problems) without too much complication on the business logic side. We do use `bcmath` with fixed precision to not run into numerical precision issues with sequencing floating point operations. This is not important today, but will become important once we deall with non-integers (e.g. for optimization problems). It also caches some computation and makes scoreboard computation more efficient today.
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 15, 2025
Progress towards DOMjudge#2525. The basic idea is to replace a lot of scattered scoring logic (which might become more complex) with encoding enough information in the rank cache. The information is encoded in a sort key that can be sorted descendingly. The sort key is a tuple (serialized as string into the database) of fixed precision decimals. Each tuple is using 9 decimals and left padded with `0`s, so it's sortable via normal DB query operations. If sorted ascending (e.g. penalty time), then we subtract from a very large number. For example, with ICPC scoring, the top 2 teams from NWERC 2024 gets these sort keys: ``` 00000000000000000000013.000000000,999999999999999999998725.000000000,999999999999999999999711.000000000 00000000000000000000011.000000000,999999999999999999998918.000000000,999999999999999999999701.000000000 ``` With this mechanism, we should be able to implement other planned scoring methods (in particular partial scoring, optimization problems) without too much complication on the business logic side. We do use `bcmath` with fixed precision to not run into numerical precision issues with sequencing floating point operations. This is not important today, but will become important once we deall with non-integers (e.g. for optimization problems). It also caches some computation and makes scoreboard computation more efficient today.
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 15, 2025
Progress towards DOMjudge#2525. The basic idea is to replace a lot of scattered scoring logic (which might become more complex) with encoding enough information in the rank cache. The information is encoded in a sort key that can be sorted descendingly. The sort key is a tuple (serialized as string into the database) of fixed precision decimals. Each tuple is using 9 decimals and left padded with `0`s, so it's sortable via normal DB query operations. If sorted ascending (e.g. penalty time), then we subtract from a very large number. For example, with ICPC scoring, the top 2 teams from NWERC 2024 gets these sort keys: ``` 00000000000000000000013.000000000,999999999999999999998725.000000000,999999999999999999999711.000000000 00000000000000000000011.000000000,999999999999999999998918.000000000,999999999999999999999701.000000000 ``` With this mechanism, we should be able to implement other planned scoring methods (in particular partial scoring, optimization problems) without too much complication on the business logic side. We do use `bcmath` with fixed precision to not run into numerical precision issues with sequencing floating point operations. This is not important today, but will become important once we deall with non-integers (e.g. for optimization problems). It also caches some computation and makes scoreboard computation more efficient today.
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 15, 2025
Progress towards DOMjudge#2525. The basic idea is to replace a lot of scattered scoring logic (which might become more complex) with encoding enough information in the rank cache. The information is encoded in a sort key that can be sorted descendingly. The sort key is a tuple (serialized as string into the database) of fixed precision decimals. Each tuple is using 9 decimals and left padded with `0`s, so it's sortable via normal DB query operations. If sorted ascending (e.g. penalty time), then we subtract from a very large number. For example, with ICPC scoring, the top 2 teams from NWERC 2024 gets these sort keys: ``` 00000000000000000000013.000000000,999999999999999999998725.000000000,999999999999999999999711.000000000 00000000000000000000011.000000000,999999999999999999998918.000000000,999999999999999999999701.000000000 ``` With this mechanism, we should be able to implement other planned scoring methods (in particular partial scoring, optimization problems) without too much complication on the business logic side. We do use `bcmath` with fixed precision to not run into numerical precision issues with sequencing floating point operations. This is not important today, but will become important once we deall with non-integers (e.g. for optimization problems). It also caches some computation and makes scoreboard computation more efficient today.
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 15, 2025
Progress towards DOMjudge#2525. The basic idea is to replace a lot of scattered scoring logic (which might become more complex) with encoding enough information in the rank cache. The information is encoded in a sort key that can be sorted descendingly. The sort key is a tuple (serialized as string into the database) of fixed precision decimals. Each tuple is using 9 decimals and left padded with `0`s, so it's sortable via normal DB query operations. If sorted ascending (e.g. penalty time), then we subtract from a very large number. For example, with ICPC scoring, the top 2 teams from NWERC 2024 gets these sort keys: ``` 00000000000000000000013.000000000,999999999999999999998725.000000000,999999999999999999999711.000000000 00000000000000000000011.000000000,999999999999999999998918.000000000,999999999999999999999701.000000000 ``` With this mechanism, we should be able to implement other planned scoring methods (in particular partial scoring, optimization problems) without too much complication on the business logic side. We do use `bcmath` with fixed precision to not run into numerical precision issues with sequencing floating point operations. This is not important today, but will become important once we deall with non-integers (e.g. for optimization problems). It also caches some computation and makes scoreboard computation more efficient today.
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 16, 2025
Progress towards DOMjudge#2525. The basic idea is to replace a lot of scattered scoring logic (which might become more complex) with encoding enough information in the rank cache. The information is encoded in a sort key that can be sorted descendingly. The sort key is a tuple (serialized as string into the database) of fixed precision decimals. Each tuple is using 9 decimals and left padded with `0`s, so it's sortable via normal DB query operations. If sorted ascending (e.g. penalty time), then we subtract from a very large number. For example, with ICPC scoring, the top 2 teams from NWERC 2024 gets these sort keys: ``` 00000000000000000000013.000000000,999999999999999999998725.000000000,999999999999999999999711.000000000 00000000000000000000011.000000000,999999999999999999998918.000000000,999999999999999999999701.000000000 ``` With this mechanism, we should be able to implement other planned scoring methods (in particular partial scoring, optimization problems) without too much complication on the business logic side. We do use `bcmath` with fixed precision to not run into numerical precision issues with sequencing floating point operations. This is not important today, but will become important once we deall with non-integers (e.g. for optimization problems). It also caches some computation and makes scoreboard computation more efficient today.
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 16, 2025
Progress towards DOMjudge#2525. The basic idea is to replace a lot of scattered scoring logic (which might become more complex) with encoding enough information in the rank cache. The information is encoded in a sort key that can be sorted descendingly. The sort key is a tuple (serialized as string into the database) of fixed precision decimals. Each tuple is using 9 decimals and left padded with `0`s, so it's sortable via normal DB query operations. If sorted ascending (e.g. penalty time), then we subtract from a very large number. For example, with ICPC scoring, the top 2 teams from NWERC 2024 gets these sort keys: ``` 00000000000000000000013.000000000,999999999999999999998725.000000000,999999999999999999999711.000000000 00000000000000000000011.000000000,999999999999999999998918.000000000,999999999999999999999701.000000000 ``` With this mechanism, we should be able to implement other planned scoring methods (in particular partial scoring, optimization problems) without too much complication on the business logic side. We do use `bcmath` with fixed precision to not run into numerical precision issues with sequencing floating point operations. This is not important today, but will become important once we deall with non-integers (e.g. for optimization problems). It also caches some computation and makes scoreboard computation more efficient today.
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 16, 2025
Progress towards DOMjudge#2525. The basic idea is to replace a lot of scattered scoring logic (which might become more complex when we introduce more scoring options such as optimization problems) by encoding sufficient information within the existing rank cache. The information is encoded into a sort key that is designed to be sorted descendingly. The sort key is a tuple (serialized as string into the database) of fixed precision decimals. Each tuple uses 9 decimals and is left padded with `0`s, enabling sorting via standard database query operations. For ascendingly sorted tuple entries (e.g. penalty time), values are subtracted from a very large constant - this ensures that that the key can be sorted as a whole. For example, with ICPC scoring, the top 3 teams from NWERC 2024 receive these sort keys: ``` 00000000000000000000013.000000000,99999999999999999998725.000000000,99999999999999999999711.000000000 00000000000000000000011.000000000,99999999999999999998918.000000000,99999999999999999999701.000000000 00000000000000000000011.000000000,99999999999999999998916.000000000,99999999999999999999706.000000000 ``` This mechanism should facilitate the implementation of other planned scoring methods, particularly partial scoring and optimization problems, with reasonable complexity in the business logic. We do use `bcmath` with fixed precision to avoid numerical precision issues caused by the order of floating point operations. While not critical currently, this will be essential when handling non-integers, such as those in optimization problems. The new mechanism also caches some computations and thus improves scoreboard computation efficiency.
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 16, 2025
Progress towards DOMjudge#2525. The basic idea is to replace a lot of scattered scoring logic (which might become more complex when we introduce more scoring options such as optimization problems) by encoding sufficient information within the existing rank cache. The information is encoded into a sort key that is designed to be sorted descendingly. The sort key is a tuple (serialized as string into the database) of fixed precision decimals. Each tuple uses 9 decimals and is left padded with `0`s, enabling sorting via standard database query operations. For ascendingly sorted tuple entries (e.g. penalty time), values are subtracted from a very large constant - this ensures that that the key can be sorted as a whole. For example, with ICPC scoring, the top 3 teams from NWERC 2024 receive these sort keys: ``` 00000000000000000000013.000000000,99999999999999999998725.000000000,99999999999999999999711.000000000 00000000000000000000011.000000000,99999999999999999998918.000000000,99999999999999999999701.000000000 00000000000000000000011.000000000,99999999999999999998916.000000000,99999999999999999999706.000000000 ``` This mechanism should facilitate the implementation of other planned scoring methods, particularly partial scoring and optimization problems, with reasonable complexity in the business logic. We do use `bcmath` with fixed precision to avoid numerical precision issues caused by the order of floating point operations. While not critical currently, this will be essential when handling non-integers, such as those in optimization problems. The new mechanism also caches some computations and thus improves scoreboard computation efficiency.
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 22, 2025
Progress towards DOMjudge#2525. The basic idea is to replace a lot of scattered scoring logic (which might become more complex when we introduce more scoring options such as optimization problems) by encoding sufficient information within the existing rank cache. The information is encoded into a sort key that is designed to be sorted descendingly. The sort key is a tuple (serialized as string into the database) of fixed precision decimals. Each tuple uses 9 decimals and is left padded with `0`s, enabling sorting via standard database query operations. For ascendingly sorted tuple entries (e.g. penalty time), values are subtracted from a very large constant - this ensures that that the key can be sorted as a whole. For example, with ICPC scoring, the top 3 teams from NWERC 2024 receive these sort keys: ``` 00000000000000000000013.000000000,99999999999999999998725.000000000,99999999999999999999711.000000000 00000000000000000000011.000000000,99999999999999999998918.000000000,99999999999999999999701.000000000 00000000000000000000011.000000000,99999999999999999998916.000000000,99999999999999999999706.000000000 ``` This mechanism should facilitate the implementation of other planned scoring methods, particularly partial scoring and optimization problems, with reasonable complexity in the business logic. We do use `bcmath` with fixed precision to avoid numerical precision issues caused by the order of floating point operations. While not critical currently, this will be essential when handling non-integers, such as those in optimization problems. The new mechanism also caches some computations and thus improves scoreboard computation efficiency.
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 22, 2025
Progress towards DOMjudge#2525. The basic idea is to replace a lot of scattered scoring logic (which might become more complex when we introduce more scoring options such as optimization problems) by encoding sufficient information within the existing rank cache. The information is encoded into a sort key that is designed to be sorted descendingly. The sort key is a tuple (serialized as string into the database) of fixed precision decimals. Each tuple uses 9 decimals and is left padded with `0`s, enabling sorting via standard database query operations. For ascendingly sorted tuple entries (e.g. penalty time), values are subtracted from a very large constant - this ensures that that the key can be sorted as a whole. For example, with ICPC scoring, the top 3 teams from NWERC 2024 receive these sort keys: ``` 00000000000000000000013.000000000,99999999999999999998725.000000000,99999999999999999999711.000000000 00000000000000000000011.000000000,99999999999999999998918.000000000,99999999999999999999701.000000000 00000000000000000000011.000000000,99999999999999999998916.000000000,99999999999999999999706.000000000 ``` This mechanism should facilitate the implementation of other planned scoring methods, particularly partial scoring and optimization problems, with reasonable complexity in the business logic. We do use `bcmath` with fixed precision to avoid numerical precision issues caused by the order of floating point operations. While not critical currently, this will be essential when handling non-integers, such as those in optimization problems. The new mechanism also caches some computations and thus improves scoreboard computation efficiency.
github-merge-queue bot
pushed a commit
that referenced
this issue
Mar 23, 2025
Progress towards #2525. The basic idea is to replace a lot of scattered scoring logic (which might become more complex when we introduce more scoring options such as optimization problems) by encoding sufficient information within the existing rank cache. The information is encoded into a sort key that is designed to be sorted descendingly. The sort key is a tuple (serialized as string into the database) of fixed precision decimals. Each tuple uses 9 decimals and is left padded with `0`s, enabling sorting via standard database query operations. For ascendingly sorted tuple entries (e.g. penalty time), values are subtracted from a very large constant - this ensures that that the key can be sorted as a whole. For example, with ICPC scoring, the top 3 teams from NWERC 2024 receive these sort keys: ``` 00000000000000000000013.000000000,99999999999999999998725.000000000,99999999999999999999711.000000000 00000000000000000000011.000000000,99999999999999999998918.000000000,99999999999999999999701.000000000 00000000000000000000011.000000000,99999999999999999998916.000000000,99999999999999999999706.000000000 ``` This mechanism should facilitate the implementation of other planned scoring methods, particularly partial scoring and optimization problems, with reasonable complexity in the business logic. We do use `bcmath` with fixed precision to avoid numerical precision issues caused by the order of floating point operations. While not critical currently, this will be essential when handling non-integers, such as those in optimization problems. The new mechanism also caches some computations and thus improves scoreboard computation efficiency.
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 29, 2025
While you can select the new types, they won't function yet. Part of DOMjudge#2525 Problem types are defined here: https://icpc.io/problem-package-format/spec/2023-07-draft.html#type
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 29, 2025
While you can select the new types, they won't function yet. Part of DOMjudge#2525 Problem types are defined here: https://icpc.io/problem-package-format/spec/2023-07-draft.html#type
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 29, 2025
While you can select the new types, they won't function yet. Part of DOMjudge#2525 Problem types are defined here: https://icpc.io/problem-package-format/spec/2023-07-draft.html#type
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 29, 2025
While you can select the new types, they won't function yet. Part of DOMjudge#2525 Problem types are defined here: https://icpc.io/problem-package-format/spec/2023-07-draft.html#type
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 29, 2025
While you can select the new types, they won't function yet. Part of DOMjudge#2525 Problem types are defined here: https://icpc.io/problem-package-format/spec/2023-07-draft.html#type
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 30, 2025
While you can select the new types, they won't function yet. Part of DOMjudge#2525 Problem types are defined here: https://icpc.io/problem-package-format/spec/2023-07-draft.html#type
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 30, 2025
While you can select the new types, they won't function yet. Part of DOMjudge#2525 Problem types are defined here: https://icpc.io/problem-package-format/spec/2023-07-draft.html#type
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 30, 2025
While you can select the new types, they won't function yet. Part of DOMjudge#2525 Problem types are defined here: https://icpc.io/problem-package-format/spec/2023-07-draft.html#type
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Mar 30, 2025
While you can select the new types, they won't function yet. Part of DOMjudge#2525 Problem types are defined here: https://icpc.io/problem-package-format/spec/2023-07-draft.html#type
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Apr 5, 2025
While you can select the new types, they won't function yet. Part of DOMjudge#2525 Problem types are defined here: https://icpc.io/problem-package-format/spec/2023-07-draft.html#type
meisterT
added a commit
to meisterT/domjudge
that referenced
this issue
Apr 6, 2025
While you can select the new types, they won't function yet. Part of DOMjudge#2525 Problem types are defined here: https://icpc.io/problem-package-format/spec/2023-07-draft.html#type
github-merge-queue bot
pushed a commit
that referenced
this issue
Apr 6, 2025
While you can select the new types, they won't function yet. Part of #2525 Problem types are defined here: https://icpc.io/problem-package-format/spec/2023-07-draft.html#type
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In the past there have been various requests to support other scoring methods than pass/fail with penalty time, some have been listed in scoring
Before we try to support any of these, we should consider what a common (internal) interface/data structures would look like to generically support these. This would include making a trade-off where the more weird scoring methods we'd support, the broader and less well-defined this interface would become. This ticket is to discuss that interface.
We should then also refactor our code so that all scoring related code is hidden behind implementations of this interface. Currently there is plenty of code scattered around the code base.
The text was updated successfully, but these errors were encountered: