软件公司 JunkCode 的管理层最近惊讶且失望地发现，自从实施了增强版的编码规范以来，生产力反而下降了。原本的想法是，所有开发人员在向软件仓库的主分支推送代码变更时，都必须严格遵守编码规范。毕竟，其中一位开发人员 Perikles 在这些规定生效前很久就已经这样做了，所以这能有多难呢？

与其花大量时间去研究生产力下降的原因，部门经理建议放宽要求：只要开发人员不时对代码进行清理，确保仓库整洁，他们就可以推送轻微违反规范的代码。

她建议采用一种衡量标准，即开发人员代码的“脏度”（dirtiness），其定义为该开发人员所做的违反规范的推送（即所谓的“脏推送”）的总和，每一项推送的权重为自推送之日起经过的天数。自脏推送之日起经过的天数是一个阶梯函数，在推送后的每个午夜增加 1。因此，如果开发人员在第 1、2 和 5 天进行了脏推送，那么在第 6 天的脏度就是 $5 + 4 + 1 = 10$。她建议，必须在脏度达到 20 之前完成一次清理阶段，彻底修复所有违反编码规范的行为。开发人员之一 Petra 意识到，遵守这一规则不仅是因为公司政策。违反规则还会导致与许多忧心忡忡的经理进行尴尬的会议，他们都想知道为什么她不能像 Perikles 一样？尽管如此，她还是希望尽可能少地进行清理阶段，并且总是将其推迟到绝对必要时才进行。清理阶段总是在当天结束时运行，并修复截至当天（含当天）所做的所有脏推送。由于每年年初所有开发人员都会被分配到新项目，因此在除夕午夜之后不应留下任何脏度。

输入格式

输入的第一行包含一个整数 $n$ ($1 \le n \le 365$)，表示 Petra 在一年中进行的脏推送次数。第二行包含 $n$ 个整数 $d_1, d_2, \dots, d_n$ ($1 \le d_i \le 365$，对于每个 $1 \le i \le n$)，表示 Petra 进行脏推送的日期。你可以假设对于 $i < j$，有 $d_i < d_j$。

输出格式

输出 Petra 为保持脏度始终严格小于 20 所需进行的清理阶段总次数。

图片由 Thom Holwerda 提供，来自 OSnews

样例

输入 1

5
1 45 65 84 346

输出 1

4

输入 2

3
310 330 350

输出 2

3