Дело в том, что CentOS5 вышел до Python 2.6.
И теперь представьте себе — Вы, огромная энтерпрайз-корпорация, держите у себя кучу редхетовских серверов, на которых работает питоновское приложение. Так как с самого начала у Вас был RHEL5, то оно и написано под него, и у него могут быть проблемы с переходом на 2.6. И вот, внезапно, RedHat заявляет: Python 2.6 вышел 19 сентября 2006 года! Все errata теперь будут тянуть по зависимостям его, если у вас что-то не работает, ваши проблемы. Весь смысл редхета как-то теряется.
Скоро будет RHEL6/CentOS6 — там будет новый Python.
Но в рамках текущей версии они не ломают совместимость. В этом же, кстати, причина php 5.1.
Поздравляю, это правильное решение, правда немного извращенное, от чего и появились «лишние» +3.
Основная идея верна — мы должны сравнить два элемента, и больший из них сравнивать с максимумом, а меньший — с минимумом. Тогда коэффициент при N получится 3/2 — на каждые два элемента мы тратим три сравнения.
Мое решение делало эту же идею, только «в лоб»:
min = max = 0;
for(i = 1; i < n; i += 2)
{
if(a[i] < a[i + 1])
{
if(a[i] < a[min]) min = i;
if(a[i + 1] > a[max]) max = i + 1;
}
else
{
if(a[i + 1] < a[min]) min = i + 1;
if(a[i] > a[max]) max = i;
}
}
i<n я не учитывал из практических соображений — сравнение интов происходит быстро, в то время как сравнение произвольных объектов может происходить очень долго. Но если i учитывать, то Ваше решение делает 3n/2 сравнений с i, а мое — n/2 :)
То есть? Видимо, я неверно сформулировал свою мысль:
Правильным ответом будет выкидывание -1.
Но алгоритм, который считает p как int32_t, выкинет 2.
Это уже не надуманное ограничение, а неправильный результат.
Других операций нет — в a у нас абстрактные элементы, для которых определены только < и >.
Хотя, о такой задаче для чисел с использованием других свойств я не думал.
Решение есть, и время его работы не выражается в виде 2 * n — C.
И теперь представьте себе — Вы, огромная энтерпрайз-корпорация, держите у себя кучу редхетовских серверов, на которых работает питоновское приложение. Так как с самого начала у Вас был RHEL5, то оно и написано под него, и у него могут быть проблемы с переходом на 2.6. И вот, внезапно, RedHat заявляет: Python 2.6 вышел 19 сентября 2006 года! Все errata теперь будут тянуть по зависимостям его, если у вас что-то не работает, ваши проблемы. Весь смысл редхета как-то теряется.
Скоро будет RHEL6/CentOS6 — там будет новый Python.
Но в рамках текущей версии они не ломают совместимость. В этом же, кстати, причина php 5.1.
Даже с йоты ipv6.google.com/ не открывается.
в min и max хранятся индексы, а не значения.
Но это пройдет для чисел, но не пройдет для непонятных объектов.
Основная идея верна — мы должны сравнить два элемента, и больший из них сравнивать с максимумом, а меньший — с минимумом. Тогда коэффициент при N получится 3/2 — на каждые два элемента мы тратим три сравнения.
Мое решение делало эту же идею, только «в лоб»:
min = max = 0; for(i = 1; i < n; i += 2) { if(a[i] < a[i + 1]) { if(a[i] < a[min]) min = i; if(a[i + 1] > a[max]) max = i + 1; } else { if(a[i + 1] < a[min]) min = i + 1; if(a[i] > a[max]) max = i; } }i<n я не учитывал из практических соображений — сравнение интов происходит быстро, в то время как сравнение произвольных объектов может происходить очень долго. Но если i учитывать, то Ваше решение делает 3n/2 сравнений с i, а мое — n/2 :)
Правильным ответом будет выкидывание -1.
Но алгоритм, который считает p как int32_t, выкинет 2.
Это уже не надуманное ограничение, а неправильный результат.
>С чего вы взяли что ответ неправильный, если при произведения порождает переполнение?
Хотя, о такой задаче для чисел с использованием других свойств я не думал.
Решение есть, и время его работы не выражается в виде 2 * n — C.
p = INT_MAX * 2 * -1 = 2
p / INT_MAX = 0
p / 2 = 1
p / -1 = -2
Тогда, по логике, выкидывать надо 2.
INT_MAX * -1 — ну точно не правильный ответ в этом случае :)