Используйте “больше, чем, или равняется” или просто “больше, чем”
Ваш учитель неверен, пожалуйста, обратитесь к разделу 5.6.2 Спецификации языка Java , в котором говорится:
blockquote>
Расширение примитивного преобразования ( §5.1.2) применяется для преобразования одного или обоих операндов, как указано в следующих правилах:
Если один из операндов имеет тип double, другой преобразуется в двойной.
В противном случае, если один из операндов имеет тип float, другой преобразуется в float.
В противном случае, если один из операндов имеет тип long, другой преобразуется в long.
В противном случае оба операнда преобразуются в тип int.
Как вы можете видеть, числа с плавающей запятой преобразуются в удвоенные только в том случае, если другой операнд является двойным , но не во всех случаях, поскольку в вашей программе неправильно указано .
То есть сумма двух чисел с плавающей запятой - это число с плавающей запятой, но сумма чисел с плавающей запятой и двойного числа равна двойной.
PS: И нет, Java никогда не конвертирует double в число с плавающей точкой, если вы явно не попросите об этом, как в:
float f = (float) Math.PI;
7 ответов
Нет, нет никаких проблем производительности, связанных с операторами сравнения. И любой хороший компилятор оптимизировал бы что-то это тривиальное так или иначе.
Я не уверен, где Вы заставили предложение использовать "i>-1", а не "i> = 0". На x86 архитектуре это не имеет никакого значения, которое Вы используете: любой случай берет точно две инструкции... один для сравнения и один для перехода:
;; if (i > -1) {
cmp eax, -1
jle else
then:
...
else:
;; if (i >= 0) {
cmp eax, 0
jl else
then:
...
else:
На большей части архитектуры RISC, которую я знаю, "i> = 0" может на самом деле быть быстрее с тех пор, обычно существует специализированный нулевой регистр, и "i>-1" может потребовать загрузки константы. Например, MIPS только имеет <инструкция (не <=). Вот то, как две конструкции были бы (наивно!) выраженный в ассемблере MIPS:
// if (i >= 0) { (assuming i is in register %t0)
stl $t1, $0, $t0 // in C: t1 = (0 < t0)
beq $t1, $0, else // jump if t1 == 0, that is if t0 >= 0
nop
then:
...
else:
// if (i > -1) { (assuming i is in register %t0)
addi $t2, $0, -1 // in C: t2 = -1
stl $t1, $t2, $t0 // in C: t1 = (t2 < t0) = (-1 < t0)
bne $t1, $0, else // jump if t1 != 0, that is if t0 > -1
nop
then:
...
else:
Таким образом в наивном, общем случае, это на самом деле будет одна инструкция быстрее, чтобы сделать "i> = 0" на MIPS. Конечно, код RISC так в большой степени optimizable, что компилятор, вероятно, изменил бы любую из этих последовательностей инструкции почти до неузнаваемости :-)
Таким образом... короткий ответ нет нет не, никакое различие.
Существует очень похожий вопрос (никакая подразумеваемая критика - как Вы говорите, искание символов хитро), здесь: "Должен одно использование < или <= в для цикла"
(Да, я, оказывается, могу найти его легко, поскольку у меня есть много upvotes на моем ответе...)
В основном, сделайте то, что является самым читаемым. День кто-то правильно предполагает, что внесение изменения далеко от большей части удобочитаемой формы собирается решить проблему производительности (без справки профилировщика) является днем, я прекращаю говорить о производительности :)
Вполне кроме того, что любой достойный компилятор делает правильную вещь, и кроме того того, что в современной архитектуре нет никакого различия в скорости между > и >= сравнения, в большем изображении говорится, что это - "микрооптимизация", которая не влияет на производительность во время выполнения в подавляющем большинстве случаев.
В случае сравнений это обычно не влияет на удобочитаемость, какой бы ни способ, которым Вы пишете это, но существует случаи, когда отбирание одной границы другой является более четким: например,
if (length >= str.size())
по сравнению с
if (length > str.size() - 1)
я не знаю о Вас, но я выбрал бы опцию 1 любой день.:-) В случаях, которые не заметно влияют на производительность, такую как это, должна победить более читаемая опция.
Нет Вы не должны больше делать этого. Да компиляторы стали намного более умными, и эти два выражения не имеют никаких различий в производительности.
я помню со дней C, что мы были поощрены использовать.... из-за производительности.
Вы уверенный об этом? Я работал с компьютерами, возвращающимися к ранним '70-м (да, в колене моего родительского элемента...), и я никогда не видел ЦП, который не мог обработать> = настолько же быстро как>. (BH "Ответвление Высоко" по сравнению с BNL "Ответвление Не Низко" в разговоре о IBM360).
Это, возможно, было верно для некоторых теневых языков сценариев, которые ломают a> = в 2 сравнения, но кто бы ни поощрил Вас использовать это для C..., хорошо... необходимо, вероятно, очень стараться забыть все, что они когда-либо говорили Вам.
Это напоминает мне о рекомендации использовать ++ я вместо меня ++ (преинкремент по сравнению с постинкрементом), потому что это было , предположительно одна инструкция быстрее. (Я забываю, где я первоначально читал об этом, но это был, вероятно, Журнал Пользователей C/C++ или Журнал доктора Dobb, но я, может казаться, не нахожу веб-ссылку.)
я серьезно сомневаюсь, что> или> = быстрее или медленнее; вместо этого напишите свой код для ясности.
Как примечание стороны, я разработал предпочтение преинкремента (++ i) оператор, даже если причина теперь потенциально устарела.