if (toIndex > length) {
throw new ArrayIndexOutOfBoundsException(toIndex);
}
а почему строгое «больше»? если индексация начинается с нуля (скорее всего так, ибо выше следует проверка на < 0), то максимальный корректный индекс должен быть меньше длинны строго.
т.е.
посмотрел EXIF, крайне удивлен. f/4.5, ISO-1600, 1/15sec — с такими параметрами я бы на свою мыло-NEX3 снимал бы ночью в неосвещенном переулке. Или использовался какой-то хитрый (непрозрачный почти полностью) объектив?
К сожалению, почти во всех ВУЗах баланс ресурсов не в пользу специальности, а в пользу тех дисциплин, которые ВУЗ может обеспечить и на соответствующем уровне.
Я сам не работодатель, не имею права давать указания, как надо выбирать персонал, но рекомендация будет как мне кажется довольно логичная — если нужен программист для задач в области математики (общая алгоритмизация, обработка изображений-звука-видео, написание 3д визуализаторов, да много еще чего), то предпочтительно конечно брать человека с высшим техническим образованием, он, скорее всего, будет знать что такое O(n), не будет лепить один и тот же код во все места (по принципу «я так и раньше делал»), не будет днями писать какие-то хитрые костыли, когда задача сводится к простому выч.методу.
Ежели нужен программист кнопочки лепить, типичную бизнес-логику писать, страницы ваять, так лучше брать человека без В.О., есть шанс что он не будет избегать рутины, жертвуя качеством процесса (а то «не хочу я такую банальщину делать, напишу-ка я крутой шаблонизатор, заодно вспомню как там NFA к DFA приводятся»).
Да, хорошо, я ее действительно породил.
Посмотрел код, в общем классно, что такие вещи можно на джаваскрипте делать.
У нас подобная система, только ядро на C++, а алгоритмы тяжелые; символы распознаем по дескрипторам Фурье, попробую поэкспериментировать с подобным подходом (посчитать какие-либо топологические признаки). В общем спасибо за пример того, что этот подход может реально работать :)
Все-таки, ваша бинаризация — это функция вида f(image, threshold(image), mean_intensity(image)),
mean_intensity(x) — зависит от исходной картинки,
threshold(x) = 0.75 — нет, она не адаптивна, и она является параметром метода, а не «служебной константой». Я понимаю, что такой фокус можно применить к любой константе, но в теории обработки изображений это справедливо, т.к. какими бы константы «хорошими» не были, они всегда срезают диапазон успешно распознаваемых изображений.
Бинаризацию значительно лучше делать не по фиксированному пороговому значению в 75%, а адаптивно:
Прогнать каким-нибудь префильтром, увеличивающим локальную контрастность. — поможет для «шумных» или «темных» изображений (где недостаточна контрастность для разделения);
Считать для каждой точки разность интенсивности до соседей, затем применить пороговое значение к разностям. — поможет для картинок с неравномерной освещенностью;
Из полученнных пикселей составить области «слабой связности», в одну область попадают точки, которые расположены недалеко друг от друга. Каждая область слабой связности состоит из нескольких компонент связности.
Далее, пытаемся распознать каждую компоненту, если она не соответствует никакой цифре, то пытаемся распознать всю область слабой связности, включающую компоненту. — поможет, если пороговый фильтр по какой-то причине выкинул кусок одной цифры, и она разбилась на компоненты.
Если все равно не удалось распознать, то вероятно пороговым значением было включено слишком много пикселей, и порог нужно немного увеличить (локально, для уже выделенного прямоугольника цифры).
Ну и плюс учитывать начальный поворот изображения (здесь это легко, т.к. при downsampling'е до 32x32 например, должны образоваться линии (из пикселей букв и цифр), поворачиваем картинку так, чтобы они стали горизонтальными).
А так, неплохо, количество переходов — это один из самых простых и надежных топологических признаков изображения.
с ВК ровно такая же проблема, даже пришлось временно поставить оперу (давненько ей не пользовался). Еще интересно, в хроме версия-через-версию то показываются «плюсики» на кнопке добавить вкладку, то нет.
в делфи uses Windows нужен, это функция операционной системы.
В турбо паскале, ее, очевидно нет, и там чтобы задержки делать нужно использовать прерывания по таймеру (иначе задержки будут зависеть от мощности процессора, чем и грешили поделия того времени)
Первое, что пришло в голову после постановки задачи — использование ассоциативных контейнеров (хеш то бишь), так что не разделяю некоторого пафоса подачи.
А в общем случае, давно уже привык к «народной истине» о том, что у программистов не бывает задач, меньше чем на час. То есть не надо спешить и обязательно реализовывать самый простой алгоритм или самый частный случай; если делаешь хоть что-то, что может пригодиться еще раз, то стоит оставить некоторый задел для масштабируемости или расширяемости (это несомненно включает и понятие алгоритмической сложности). У всех проектов, конечно этот критерий допустимой сложности решения различный, но если что-то можно сделать за 5 минут «плохо», а за час «хорошо» — всегда стоит выбирать второй вариант.
все-таки не для всех букв нельзя создать 3д модели, буквы I J L M T U V Y — выглядят как просто с усеченными краями, а C N S Z — нельзя нарисовать в «2.5д» (две плоские половины, раздвинутые на «высоту»), но легко изображаются в полноценном 3д
какой-то бессмысленный список, глаголы все на -ться (2024), но ни прошедших форм, ни третьего лица вообще нет. такое ощущение что кто-то словарик нецензурщины прогнал и ".рф" приписал.
я не думаю, что сильно удивлю, что «никак», но на всякий случай перебор так и оставил на работе запущенным, пока лучшее решение — это матрица где 19 (из 252) клеток не удалось заполнить. матрицы 13x13 и 14x14 удалось раскрасить полностью, хотя это уже давно было сделано.
«Можно сделать быстрее»: для каждой строки / столбца храним список уже раскрашенных ячеек в каждый цвет. Соответственно при попытке поставить ячейку (x,y) в цвет c смотрим foreach (a coloredX(x,c)) foreach (b in coloredY(y,c)) { считаем четвертую точку прямоугольника с вершинами a, b, (x,y), пусть это будет (x0,y0) и делаем exclude( c ) из availableColors(x0,y0). То есть время такой проверки даже не 21*12, а в худшем случае примерно (21/4)*(12/4) операций на каждую точку.
а что на счет перебора с возвратом? на рекурсию много места не нужно (красим всего 21*12 клеток, по одной), при установке клетки с определенным цветом нужно проверить не образуются ли почти-прямоугольники (прямоугольник без одной вершины) этого же цвета (можно сделать быстрее, чем просмотром всех клеток; хотел написать «за линейное время», но здесь константы) и убрать из допустимого множества цветов для этой вершины текущий цвет. Здесь уже не 21^2*12^2*4^(21*12), а порядка 21*12*4^(21*12 / k). Затрудняюсь оценить точно.
Да, пожалуй еще рано оценивать нововведения, однако, это выглядит как шаг назад. Понимаю, что здесь больше под планшеты ориентированность, но мышью делать лишние скроллы и щелчки не так приятно. То есть пока количественная оценка usability ухудшилась.
кстати, не очень понятно, как решает вопрос с очень большим количеством приложений без start menu.
пока имеем абсолютно неудобоваримую схему, когда каждый exe-шник получает место на metro home screen:
чьи это Uninstall'ы? что будет, если я поставлю еще 100500 приложений, они так и растянутся в бескрайний край? Иерархии какой-то не хватает по-любому, а где ее вставить (desktop, home screen, superbar) — не понятно.
а почему строгое «больше»? если индексация начинается с нуля (скорее всего так, ибо выше следует проверка на < 0), то максимальный корректный индекс должен быть меньше длинны строго.
т.е.
только вот, похоже, эти ребята не знали о формуле Стирлинга
К сожалению, почти во всех ВУЗах баланс ресурсов не в пользу специальности, а в пользу тех дисциплин, которые ВУЗ может обеспечить и на соответствующем уровне.
Я сам не работодатель, не имею права давать указания, как надо выбирать персонал, но рекомендация будет как мне кажется довольно логичная — если нужен программист для задач в области математики (общая алгоритмизация, обработка изображений-звука-видео, написание 3д визуализаторов, да много еще чего), то предпочтительно конечно брать человека с высшим техническим образованием, он, скорее всего, будет знать что такое O(n), не будет лепить один и тот же код во все места (по принципу «я так и раньше делал»), не будет днями писать какие-то хитрые костыли, когда задача сводится к простому выч.методу.
Ежели нужен программист кнопочки лепить, типичную бизнес-логику писать, страницы ваять, так лучше брать человека без В.О., есть шанс что он не будет избегать рутины, жертвуя качеством процесса (а то «не хочу я такую банальщину делать, напишу-ка я крутой шаблонизатор, заодно вспомню как там NFA к DFA приводятся»).
Посмотрел код, в общем классно, что такие вещи можно на джаваскрипте делать.
У нас подобная система, только ядро на C++, а алгоритмы тяжелые; символы распознаем по дескрипторам Фурье, попробую поэкспериментировать с подобным подходом (посчитать какие-либо топологические признаки). В общем спасибо за пример того, что этот подход может реально работать :)
mean_intensity(x) — зависит от исходной картинки,
threshold(x) = 0.75 — нет, она не адаптивна, и она является параметром метода, а не «служебной константой». Я понимаю, что такой фокус можно применить к любой константе, но в теории обработки изображений это справедливо, т.к. какими бы константы «хорошими» не были, они всегда срезают диапазон успешно распознаваемых изображений.
Прогнать каким-нибудь префильтром, увеличивающим локальную контрастность. — поможет для «шумных» или «темных» изображений (где недостаточна контрастность для разделения);
Считать для каждой точки разность интенсивности до соседей, затем применить пороговое значение к разностям. — поможет для картинок с неравномерной освещенностью;
Из полученнных пикселей составить области «слабой связности», в одну область попадают точки, которые расположены недалеко друг от друга. Каждая область слабой связности состоит из нескольких компонент связности.
Далее, пытаемся распознать каждую компоненту, если она не соответствует никакой цифре, то пытаемся распознать всю область слабой связности, включающую компоненту. — поможет, если пороговый фильтр по какой-то причине выкинул кусок одной цифры, и она разбилась на компоненты.
Если все равно не удалось распознать, то вероятно пороговым значением было включено слишком много пикселей, и порог нужно немного увеличить (локально, для уже выделенного прямоугольника цифры).
Ну и плюс учитывать начальный поворот изображения (здесь это легко, т.к. при downsampling'е до 32x32 например, должны образоваться линии (из пикселей букв и цифр), поворачиваем картинку так, чтобы они стали горизонтальными).
А так, неплохо, количество переходов — это один из самых простых и надежных топологических признаков изображения.
В турбо паскале, ее, очевидно нет, и там чтобы задержки делать нужно использовать прерывания по таймеру (иначе задержки будут зависеть от мощности процессора, чем и грешили поделия того времени)
А в общем случае, давно уже привык к «народной истине» о том, что у программистов не бывает задач, меньше чем на час. То есть не надо спешить и обязательно реализовывать самый простой алгоритм или самый частный случай; если делаешь хоть что-то, что может пригодиться еще раз, то стоит оставить некоторый задел для масштабируемости или расширяемости (это несомненно включает и понятие алгоритмической сложности). У всех проектов, конечно этот критерий допустимой сложности решения различный, но если что-то можно сделать за 5 минут «плохо», а за час «хорошо» — всегда стоит выбирать второй вариант.
если интересно, вот сорец: dl.dropbox.com/u/243445/ColorMatrix.cpp
пока имеем абсолютно неудобоваримую схему, когда каждый exe-шник получает место на metro home screen:
чьи это Uninstall'ы? что будет, если я поставлю еще 100500 приложений, они так и растянутся в бескрайний край? Иерархии какой-то не хватает по-любому, а где ее вставить (desktop, home screen, superbar) — не понятно.