Designing a collaborative cross-campus airport (or other transit) simulation project: panel discussion
Pourquoi ce travail est dans la base
Une base qui oublie comment elle a trouvé un travail ne peut pas être vérifiée. Voici les voies qui ont admis celui-ci.
Notice bibliographique
Résumé
In this workshop participants will design a cross-campus collaborative project built around an airport (or other transit) simulation. Computer scientists and software engineers create simulations both to understand how processes work, and to avoid catastrophes in the actual implementations of those processes. At the last CCSC-NW, an airport simulation was proposed as a promising collaborative project because it is a large, real-world problem whose implementation potentially encompasses many disciplines. It makes use of multiple data structures, the potential for a nice graphical interface, and large data flows to process. The idea is an expansion of an assignment called the Airport Problem, which has been used as an intense culminating project in a Data Structures course both at the University of California, Santa Barbara, and at Clark College in Vancouver, WA. The premise of the Airport Problem is to complete a single project with multiple data structures so that students gain an understanding of the reasoning behind using different data structures. The Airport Problem uses three data structures: an incoming queue for airplanes arriving at the airport (a DEAP or Min-Max Heap), an outgoing queue for airplanes which have landed and are ready to take off (a Red-Black Tree), and a lobby for passengers who arrive and whose airplanes have not yet landed (a 2-3 tree or a linked list). The project proposed in this workshop would expand the Airport Problem to include additional components such as graphics and networking. Depending on participants' interests as well as availability of data, the transit mode could also be changed from Airport to either Shipping or Trucking.
Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.
Prédiction distillée sur la base complète
Imitation des enseignantsNi prévalence calibrée, ni vérité terrain. Validation humaine à venir. Apprise à partir de 10 348 étiquettes directes de Codex et de 10 348 étiquettes directes de Gemma. Le mode candidate est l'union des têtes enseignantes seuillées; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont ni des étiquettes humaines ni des étiquettes directes de modèles de pointe.
Scores Codex et Gemma par catégorie
| Catégorie | Codex | Gemma |
|---|---|---|
| Métarecherche | 0,001 | 0,000 |
| Méta-épidémiologie (sens strict) | 0,000 | 0,000 |
| Méta-épidémiologie (sens large) | 0,000 | 0,000 |
| Bibliométrie | 0,000 | 0,001 |
| Études des sciences et des technologies | 0,000 | 0,000 |
| Communication savante | 0,000 | 0,000 |
| Science ouverte | 0,000 | 0,000 |
| Intégrité de la recherche | 0,000 | 0,000 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,000 | 0,000 |
Scores machine (provisoires)
Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.
Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.
score_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découle