回答編集履歴
1
例題について追加
test
CHANGED
@@ -39,3 +39,83 @@
|
|
39
39
|
|
40
40
|
|
41
41
|
競プロでは入力に対して、処理の方が大変大きいです。その場合、入力をまとめて始めにやった方がわかりやすいですし、速度が不利になると言うことはありません。大量のログ解析やWebアクセスなどデータが大量にあり、入力に待ちが発生しやすい場合は、マルチスレッドにして各行を並列に読み込んで処理して、いらなくなったデータをどんどん捨てていく方が有利になりますが、入力が小さいときは無視できるような違いしかありません(かといって、別の所では必要になるテクニックではありますが)。
|
42
|
+
|
43
|
+
|
44
|
+
|
45
|
+
---
|
46
|
+
|
47
|
+
|
48
|
+
|
49
|
+
例題の場合はこうなります。
|
50
|
+
|
51
|
+
※ 2.4.0で追加された`Array#sum`を使っているので、2.4.0以降でないと動きません。
|
52
|
+
|
53
|
+
|
54
|
+
|
55
|
+
```Ruby
|
56
|
+
|
57
|
+
# frozen_string_literal: true
|
58
|
+
|
59
|
+
# 入力処理
|
60
|
+
|
61
|
+
n = gets.to_i
|
62
|
+
|
63
|
+
students = Array.new(n) { gets.split }
|
64
|
+
|
65
|
+
.map { |field, *scores| [-field, scores.map(&:to_i)] }
|
66
|
+
|
67
|
+
# 結果作成
|
68
|
+
|
69
|
+
results = students.map do |field, scores|
|
70
|
+
|
71
|
+
next false if scores.sum < 350
|
72
|
+
|
73
|
+
case field
|
74
|
+
|
75
|
+
when 'so'
|
76
|
+
|
77
|
+
scores[0] + scores[4] >= 150
|
78
|
+
|
79
|
+
when 'sc'
|
80
|
+
|
81
|
+
scores[1] + scores[3] >= 150
|
82
|
+
|
83
|
+
end
|
84
|
+
|
85
|
+
end
|
86
|
+
|
87
|
+
# 出力処理
|
88
|
+
|
89
|
+
students.zip(results).each do |student, result|
|
90
|
+
|
91
|
+
if result
|
92
|
+
|
93
|
+
case student.first
|
94
|
+
|
95
|
+
when 'so'
|
96
|
+
|
97
|
+
puts '文系クラス合格'
|
98
|
+
|
99
|
+
when 'sc'
|
100
|
+
|
101
|
+
puts '理系クラス合格'
|
102
|
+
|
103
|
+
end
|
104
|
+
|
105
|
+
else
|
106
|
+
|
107
|
+
puts '残念でした'
|
108
|
+
|
109
|
+
end
|
110
|
+
|
111
|
+
end
|
112
|
+
|
113
|
+
```
|
114
|
+
|
115
|
+
|
116
|
+
|
117
|
+
入力の時点で文系か理系かのところと各スコアを分離します。各スコアは数値に変換しておきます。文系か理系かはシンボルにしても良いかもしれません(でも、freezeしているから速度は違わないかな)。結果を求める処理では合格判定だけを結果として得ます。何を出力するかはその後です。最後に結果に基づき出力します。
|
118
|
+
|
119
|
+
|
120
|
+
|
121
|
+
競プロからは離れてしまいますが、本格的にやるにはクラスを作った方がRubyらしくなります。競プロはアルゴリズムしか重要視されませんが、本当に可読性を高めようと思うなら、細かくクラスやメソッドにわけることが重要になります。もうひとつ重要な考えとしてオブジェクトをmutableとimmutableのどちらで扱うかです。上記コードはimmutableで書いていますが、オブジェクトの生成にはコストがのしかかってくるため、処理時間がシビアな問題ではきつくなる場合があります。
|