Покажет, что человек знает что такое массив :) Я бы такие задачи отнёс в разряд "отсеять совсем слабых". Углубляться в дополнительные условия - на мой взгляд действительно лишнее, особенно если в реальной работе такого делать не придётся
Так а в чëм проблема задач вроде "переворачивания матриц"? Я могу понять неприязнь к более сложным задачам, но эта же совсем элементарна и подвластна любому первокурснику! Кажется авторы таких статей совсем перегибают палку, надо как-то более явно границы обозначать.
Там на входе каждый раз уникальный поток чисел, скорее всего выбраный случайным образом. Фактически же могу заявить, что подход, описанный мной, даёт очень хорошую производительность.
Какой код самый быстрый - не знаю, он не опубликован. Тем не менее, я сейчас добрался до второго места и с полной уверенностью могу сказать - код на первом месте должен быть полон хаков и вылизан практически до идеала
Число нулей и сдвиги можно вычислить невекторизованно. А дальше тест Миллера-Рабина, к примеру, состоит из 2-х частей - возведения в степень и потом возведения в квадрат в цикле. Возводить в степень сразу 4 числа легко, просто каждый раз, когда произведение каких-то чисел вам не нужно, вычисляйте в этом месте произведение на единицу и число останется неизвенным. Что касается возведения в квадрат - алгоритм устроен таким образом, что если сделать больше итераций, чем нужно, то корректность проверки не изменится. Надеюсь эти намёки вам помогут.
Путешествие в эту тему и началось с Vector API в Java, но там у меня с перформансом совсем беда была. Может у самого руки кривые, потом ещё раз попробую
С удовольствием бы посмотрел на ваш код! Мне, как видите, воображения не хватило. Хотя тут, наверное, можно применить и другой подход - одновременно проверять 4/8 различных чисел из входного потока. Даже не представляю, чем пользовались люди из топа таблицы лидеров. EDIT: невекторизованная целочисленная версия - Your best score: 248,606, это 23-е место. Если поднажать, наверное смогу стать 22-м =) EDIT2: интересно, какая часть этого времени ушла на fread, невыгодно же по одной записи дёргать наверное. Это вы мне интересную задачу подкинули...
Спасибо за ссылку! Я видел информацию о подобных алгоритмах, и мне они не подходят, поскольку в данном случае делитель - не константный, а зависит от тестируемого числа n.
Извините, но это звучит это как оправдание "Ну да фигово я реализовал, НО в документации же в таком-то файле на такой-то строчке я об этом написал"
Кажется вы от класса, который заявляет A, ожидаете, что он будет делать B. CompletableFuture - это всего-лишь инструмент. Он написан в точности таким, каким он был задуман, никакого вопроса про "не успевали" тут быть не может. Если для вашей задачи он не подходит, то ничего страшного - возьмите другой. Если вы по какой-то причине считаете, что этот инструмент должен делать что-то иначе, т.е. концептуально быть другим инструментом, то может быть это вопрос именно ваших ожиданий.
Если кто-то объснит, то буду благодарен
Это из другого вашего сообщения. В статье есть ответ, в документации тоже. Не нужно ожидать, что CompletableFuture делает то же самое, что RxJava, даже не прочитав документацию, тут именно вы совершаете ошибку, а не разработчики Java.
Идеи есть, конечно. CompletableFuture полностью отвязана от потоков ради большей гибкости. Да и завершать задачи через флаг прерывания потока - как то грубовато это на мой взгляд, не всегда удобно, свой статус операции намного универсальнее
/**
* If not already completed, completes this CompletableFuture with
* a {@link CancellationException}. Dependent CompletableFutures
* that have not already completed will also complete
* exceptionally, with a {@link CompletionException} caused by
* this {@code CancellationException}.
*
* @param mayInterruptIfRunning this value has no effect in this
* implementation because interrupts are not used to control
* processing.
*
* @return {@code true} if this task is now cancelled
*/
public boolean cancel(boolean mayInterruptIfRunning) {
Справедливый вопрос. Я не описал, что именно имею ввиду под head. На первой итерации head - это первые 2 нуля, а у вас в обозначениях head - это то, что находится перед этими двумя нулями. Т.е. просто разница в нотации, код вы поняли совершенно верно.
И это бы прекрасно сработало в случае RxJava, но невозможно в случае стандартного CompletableFuture.
Да, тут проблема именно в использовании CompletableFuture - она работает не так, как RxJava, и cancel не приводит к интеррапту потока даже если передать флаг mayInterruptIfRunning=true. Эти нюансы хорошо задокументированы, и если разработчик полагался на предполагаемое поведение, которого не существует - это ошибка самого разработчика.
Опыт собеседований показывает, что и с 5-летним опытом бывают совсем слабые, тут как повезёт
Покажет, что человек знает что такое массив :)
Я бы такие задачи отнёс в разряд "отсеять совсем слабых". Углубляться в дополнительные условия - на мой взгляд действительно лишнее, особенно если в реальной работе такого делать не придётся
Так а в чëм проблема задач вроде "переворачивания матриц"? Я могу понять неприязнь к более сложным задачам, но эта же совсем элементарна и подвластна любому первокурснику! Кажется авторы таких статей совсем перегибают палку, надо как-то более явно границы обозначать.
Там на входе каждый раз уникальный поток чисел, скорее всего выбраный случайным образом. Фактически же могу заявить, что подход, описанный мной, даёт очень хорошую производительность.
Какой код самый быстрый - не знаю, он не опубликован. Тем не менее, я сейчас добрался до второго места и с полной уверенностью могу сказать - код на первом месте должен быть полон хаков и вылизан практически до идеала
Число нулей и сдвиги можно вычислить невекторизованно. А дальше тест Миллера-Рабина, к примеру, состоит из 2-х частей - возведения в степень и потом возведения в квадрат в цикле.
Возводить в степень сразу 4 числа легко, просто каждый раз, когда произведение каких-то чисел вам не нужно, вычисляйте в этом месте произведение на единицу и число останется неизвенным.
Что касается возведения в квадрат - алгоритм устроен таким образом, что если сделать больше итераций, чем нужно, то корректность проверки не изменится. Надеюсь эти намёки вам помогут.
Чем ближе к первому месту, тем сложнее. Желаю удачи!
Путешествие в эту тему и началось с Vector API в Java, но там у меня с перформансом совсем беда была. Может у самого руки кривые, потом ещё раз попробую
С удовольствием бы посмотрел на ваш код! Мне, как видите, воображения не хватило.
Хотя тут, наверное, можно применить и другой подход - одновременно проверять 4/8 различных чисел из входного потока. Даже не представляю, чем пользовались люди из топа таблицы лидеров.
EDIT: невекторизованная целочисленная версия -
Your best score: 248,606, это 23-е место. Если поднажать, наверное смогу стать 22-м =)EDIT2: интересно, какая часть этого времени ушла на fread, невыгодно же по одной записи дёргать наверное. Это вы мне интересную задачу подкинули...
Это здорово, нужно будет попробовать, главное сперва решить проблему 64-битного умножения. Спасибо!
Спасибо за ссылку! Я видел информацию о подобных алгоритмах, и мне они не подходят, поскольку в данном случае делитель - не константный, а зависит от тестируемого числа n.
Спасибо! Загляну, узнаю, что за репозиторий
С этом не могу не согласиться, это действительно сомнительное решение.
Конечно!
Кажется вы от класса, который заявляет
A, ожидаете, что он будет делатьB.CompletableFuture- это всего-лишь инструмент. Он написан в точности таким, каким он был задуман, никакого вопроса про "не успевали" тут быть не может. Если для вашей задачи он не подходит, то ничего страшного - возьмите другой. Если вы по какой-то причине считаете, что этот инструмент должен делать что-то иначе, т.е. концептуально быть другим инструментом, то может быть это вопрос именно ваших ожиданий.Это из другого вашего сообщения. В статье есть ответ, в документации тоже. Не нужно ожидать, что
CompletableFutureделает то же самое, чтоRxJava, даже не прочитав документацию, тут именно вы совершаете ошибку, а не разработчики Java.Нет, я отказываюсь повышать сложность :)
Хотя посмотрим, спасибо!
Идеи есть, конечно. CompletableFuture полностью отвязана от потоков ради большей гибкости.
Да и завершать задачи через флаг прерывания потока - как то грубовато это на мой взгляд, не всегда удобно, свой статус операции намного универсальнее
Это же и в документации сказано:
Справедливый вопрос. Я не описал, что именно имею ввиду под
head.На первой итерации
head- это первые 2 нуля, а у вас в обозначенияхhead- это то, что находится перед этими двумя нулями. Т.е. просто разница в нотации, код вы поняли совершенно верно.Да, тут проблема именно в использовании CompletableFuture - она работает не так, как RxJava, и cancel не приводит к интеррапту потока даже если передать флаг mayInterruptIfRunning=true.
Эти нюансы хорошо задокументированы, и если разработчик полагался на предполагаемое поведение, которого не существует - это ошибка самого разработчика.
Да, опечатка. Поправил, спасибо большое!