Замечание для пользователей: плагин следует применять только осознавая, что и как он делает, поскольку из-за копирования <input> возникают побочные эффекты, о которых лучше знать заранее.
1. $('input[type=number]') возвращает и пользовательские, и сгенерированные элементы, следовательно
2. $('input[type=number]').show(); покажет скрытые пользовательские тэги;
3. $('#myInputID') выдаст интересный результат, если у инпута был ID;
4. Обработчики событий для исходного инпута скорее всего не будут вызваны, а изменение его атрибутов не изменит атрибуты отображаемого.
При просмотре ленты/главной обычно смотрю не только на заголовки, но и на кусок текста до ката прежде, чем открыть. Из-за этого расширение становится не очень ценным.
А уведомления — это полезно. Хорошо, если ещё и умеют пищать (опционально).
Безумная идея: собирать плюсы/минусы, которые пользователь ставит посту (можно свои — чтобы (а) работало у ридонли (б) не минусить хорошие, но не интересные пользователю топики) и на основе хаба, названия, текста статьи, автора(?) автоматически открывать новые интересные статьи в новой вкладке.
Вроде как около 160 секунд на билет тратится, если верить трансляции. Т.е. около 3.7К билетов в неделю.
График
Нет, это не автораспознавание видео, точки были отмечены вручную между делом. Автоматизировано было лишь добавление текущего времени по нажатию на кнопку.
Или сообщить ID участника тем, кто не запомнил. А посчитать примерное время — это уже дело техники.
Кстати, никто из пользователей к трансляции не прикрутил автоматическую распознавалку этого ID с текущего напечатанного билета ради получения времени печати билета № X и построения красивых графиков?
P.S. Из 14 раздела правил «Конкурс не является лотереей.» А на билетах написано «хабра-лотерея».
Надо было немножко подождать :) В 1993 году появился магнитофон Вега РМ-252С с вышеупомянутой «умной» перемоткой до сл. песни.
Работает, если зажать воспроизведение + перемотку. Я поначалу думал, что это баг, а не фича, когда магнитофон самопроизвольно отключал быстрое воспроизведение, но потом вычитал в инструкции и удивился.
Заказывать столы и изготовление деталей не доводилось, поэтому мне интересны некоторые, может быть глупые вопросы. Поэтому заранее прошу прощения.
Расскажите, пожалуйста (может быть, в следующей статье), что сделали с чертежом на стороне изготовителя (экспортировали/перерисовали вручную на бумагу как у ZoomEx /доработали/другое), много ли пришлось им потрудиться, чтобы привести его в удобный для них вид. На картинках я не заметил отверстий для соединения частей стола. Кто их потом проставил, на каком этапе, как соединяли части стола?
Достаточно ли было Вашей модели? Надо ли было проработать ещё что-нибудь, или можно было принести листок бумаги с рисунком уровня первого класса и попросить сделать всё хорошо?
По поводу стола: интуитивно хочется сделать его симметричным, с ещё одной полочкой снизу для ИБП. Но, вероятно, он станет при этом слишком длинным.
Добавил const для случая с сортировкой — результат сохраняется как и у 0serg. Скорее всего компилятор и так понял нас правильно.
Для интереса решил дело усложнить, добавив в operator() счётчик его вызовов. Количество вызовов конструктора осталось прежним. Количество вызовов operator() — O(NlnN), ничего противоестественного не произошло.
Графики
ctr_rate — вызовы конструктора на один элемент, cmp_rate — вызовы operator() на один элемент.
Интересно… Можно отличать по этому признаку компиляторы (до их первого обновления).
На данный момент в gcc 4.8.1 такие результаты (с флагом -std=c++11 не меняются):
размер | rate | массив M
-------+------------+------------------------
1 | 4 | любой
>> 1 | 1.25 | M[i] == M[j]
>> 1 | 1.33 | M[i] < M[i+1]
>> 1 | 5 | M[i] > M[i+1]
>> 1 | около 1.39 | M[i] == i % 2 ? 10 : 11
>> 1 | около 1.34 | M[i] == i % 3 ? 10 : 11
(«около» — значит нельзя уверенно сказать, что значение к чему-то стремится)
Попробуйте для интереса тоже забить константу/возрастающую/убывающую последовательность.
rate зависит от степени отсортированности массива, это видно, если наполнять массив разными данными.
Я, честно говоря, ожидал увидеть логарифмическую зависимость, но пока её наблюдать не приходится.
get(0), get(1), get(2) — отличная демонстрация того, как списки не надо использовать. Обязательно отметьте это в статье, тогда она действительно поможет новичкам не обходить списки за квадратичное время.
Ведь get работает за линейное время
public E More ...get(int index) {
return entry(index).element;
}
private Entry<E> More ...entry(int index) {
if (index < 0 || index >= size)
throw new IndexOutOfBoundsException("Index: "+index+
", Size: "+size);
Entry<E> e = header;
if (index < (size >> 1)) { // из-за этого условия работать с концом списка в режиме произвольного доступа можно так же быстро, как и с началом.
for (int i = 0; i <= index; i++)
e = e.next;
} else {
for (int i = size; i > index; i--)
e = e.previous;
}
return e;
}
Крайне полезно было бы извлечь из комментариев Sap_ru, Oblitus и culvert пользу и добавить в статью:
1. Перебор с get (который Вы упомянули в комментарии, на который я отвечаю)
2. Перебор с итераторами
3. Для каждого случая с серединой списка получить итератор, указывающий на середину списка и провести k операций, используя итератор.
Разделители и прочий мусор можно самому не вводить, а получить в наследство от копируемого текста. В таком случае в поле могут оказаться в лучшем случае пробелы, а в худшем — куски фраз («0го года. 12 395 единиц было произ») или криво распознанный текст («б4.О»). Если копировать из pdf-ки, с некоторой долей везения можно вставить текст задом наперёд.
Медленно JS просовывает из песочницы свои маленькие ручки, и это немного тревожит.
Скажем, открыл сайт, а через некоторое время (не без помощи Web Alarms API) вылезет «Сейчас 09:00! Срочно заказать ШОК один продукт для увеличения покера!»
Здесь почти всё логично. Неделимый предмет, разделённый на части, утрачивает свой смысл. С яблоком не так очевидно, яблоко ещё можно съесть или вынуть косточки и посадить. Более яркий пример — микропроцессор. Купили себе один помощнее, а с другом поделиться хочется. Отпиливаете ровно половину, отдаёте ему…
С песком, пока мы не дошли до долей грамма, всё наоборот. Делим его, а не ломается.
«Но всё равно — делят на части, а не на число.» — спорное утверждение в общем смысле, но в рамках дробления физических объектов вполне уместное.
Подобные методы математически верны, а вот физический смысл меняется. «Дали четыре яблока минус одному человеку» физического смысла не имело, «один человек вернул четыре яблока» — смысл появился.
И это — не говоря уже о неполиткорректной дискриминации фасоли по цветовому признаку.
С помощью ловкости рук и небольшого мошенничества с eval можно реализовать что-то подобное на JS и писать код вида:
Это оказалось побочным эффектом идеи, с которой я пришёл на хабр.
P.S. maxatwork, спасибо большое за перевод интересной статьи!
1.
$('input[type=number]')возвращает и пользовательские, и сгенерированные элементы, следовательно2.
$('input[type=number]').show();покажет скрытые пользовательские тэги;3.
$('#myInputID')выдаст интересный результат, если у инпута был ID;4. Обработчики событий для исходного инпута скорее всего не будут вызваны, а изменение его атрибутов не изменит атрибуты отображаемого.
А уведомления — это полезно. Хорошо, если ещё и умеют пищать (опционально).
Безумная идея: собирать плюсы/минусы, которые пользователь ставит посту (можно свои — чтобы (а) работало у ридонли (б) не минусить хорошие, но не интересные пользователю топики) и на основе хаба, названия, текста статьи, автора(?) автоматически открывать новые интересные статьи в новой вкладке.
Нет, это не автораспознавание видео, точки были отмечены вручную между делом. Автоматизировано было лишь добавление текущего времени по нажатию на кнопку.
Кстати, никто из пользователей к трансляции не прикрутил автоматическую распознавалку этого ID с текущего напечатанного билета ради получения времени печати билета № X и построения красивых графиков?
P.S. Из 14 раздела правил «Конкурс не является лотереей.» А на билетах написано «хабра-лотерея».
Работает, если зажать воспроизведение + перемотку. Я поначалу думал, что это баг, а не фича, когда магнитофон самопроизвольно отключал быстрое воспроизведение, но потом вычитал в инструкции и удивился.
Расскажите, пожалуйста (может быть, в следующей статье), что сделали с чертежом на стороне изготовителя (экспортировали/перерисовали вручную на бумагу как у ZoomEx /доработали/другое), много ли пришлось им потрудиться, чтобы привести его в удобный для них вид. На картинках я не заметил отверстий для соединения частей стола. Кто их потом проставил, на каком этапе, как соединяли части стола?
Достаточно ли было Вашей модели? Надо ли было проработать ещё что-нибудь, или можно было принести листок бумаги с рисунком уровня первого класса и попросить сделать всё хорошо?
По поводу стола: интуитивно хочется сделать его симметричным, с ещё одной полочкой снизу для ИБП. Но, вероятно, он станет при этом слишком длинным.
Для интереса решил дело усложнить, добавив в operator() счётчик его вызовов. Количество вызовов конструктора осталось прежним. Количество вызовов operator() — O(NlnN), ничего противоестественного не произошло.
Сортировка убывающей последовательности:
Сортировка массива из нулей:
Сортировка случайного массива:
На данный момент в gcc 4.8.1 такие результаты (с флагом -std=c++11 не меняются):
(«около» — значит нельзя уверенно сказать, что значение к чему-то стремится)
Попробуйте для интереса тоже забить константу/возрастающую/убывающую последовательность.
Я, честно говоря, ожидал увидеть логарифмическую зависимость, но пока её наблюдать не приходится.
UPD: Заполнил массив как
for( int k = 0; k < size; k++ ) mas[k] = 1e7 - k;— получил число, стремящееся к 5.Крайне полезно было бы извлечь из комментариев Sap_ru, Oblitus и culvert пользу и добавить в статью:
1. Перебор с get (который Вы упомянули в комментарии, на который я отвечаю)
2. Перебор с итераторами
3. Для каждого случая с серединой списка получить итератор, указывающий на середину списка и провести k операций, используя итератор.
Скажем, открыл сайт, а через некоторое время (не без помощи Web Alarms API) вылезет «Сейчас 09:00! Срочно заказать ШОК один продукт для увеличения покера!»
С песком, пока мы не дошли до долей грамма, всё наоборот. Делим его, а не ломается.
«Но всё равно — делят на части, а не на число.» — спорное утверждение в общем смысле, но в рамках дробления физических объектов вполне уместное.
И это — не говоря уже о неполиткорректной дискриминации фасоли по цветовому признаку.