Java и типы

Потому что есть ещё и double?

Это старый, косящий под C++ язык, в них так принято.

Ну, наверно, есть подобная разница:

float x = 3.0f / 2.0f; //результат 1.5
float x = 3 / 2; //результат 1 (целочсленное деление)

Но это неточно.

Так нельзя было сделать при разработке?

float x = 1.5; //воспринимать литерал как float
double y = 1.5; //воспринимать литерал как double

В общем случае нет.

В жаву уже var ввели бзв?

var x = 1.5 // double или float?

Если следовать такой логике, то да обозначение 1.5F нужно. В C# есть var.

Перегрузка?

float sum(float x, float y);
double sum(double x, double y);

sum(0.5, 2.0); // ???

Затем что инициализатор это value, а у value есть конкретный тип, и для fp литералов он сообщается суффиксом.

Так нельзя было сделать при разработке?

Если подумать, сколько еще частных случаев можно было «сделать», и сколько из этого вытечет неочевидных следствий, то окажется, что так делать не надо. Потому что четкие безконтекстные правила как минимум гораздо предсказуемее, чем куча частных случаев. Но здесь ты можешь писать без f, т.к. литералы приводятся еще во время компиляции, а читаются наверняка изначально в дабл, и только потом кастятся в флот, если парсер увидел f. Даже если это не так, то если тебе не важна разница в погрешности представлений всяких 0.1, то ты ее и не почувствуешь.

Потому что разработчики жабы не знали про алгоритмы автоматического вывода типов.

Жаба и так не шустро собирается, а ты ещё и типы выводить собрался?

Почему нет? HM — довольно быстрый в ограниченном варианте.

Для этого есть Scala с выводом типов

На самом деле не очень понятно, нафейхоа нужен float в 2020 году. Это тянется еще из сишки с ее float/double. Типа экономия на спичках. Хорошо хоть unsigned не взяли.

Возможно, в скором времени опомнятся (да куда там, привет обратная совместимость) и уберут этот недотип из языка.

Так у Вас же может быть выражение. И при приведении типов будет не очевидно какую точность надо иметь. 1.5 + 1.5 это float или double? Суффиксы это и уточняют, потому что если один из них double, то и все выражение будет double.

Возможно, в скором времени опомнятся (да куда там, привет обратная совместимость) и уберут этот недотип из языка.

Все видокарты эффективно работают только с f32, вычисления с f64 на всех современных игровых картах выполняются в 16 раз медленнее и в пять раз медленнее на специализированных вычислителях. Так что если выкинешь f32 из языка то точно использовать такой язык для гетерогенных вычислений будет неудобно.

Жаба и так не шустро собирается, а ты ещё и типы выводить собрался?

Жаба очень шустро собирается, в энетрпрайзе юнит тесты против всяких баз данных занимают по часу, с сборка занимает секунды, и упирается наверное только в I/O диска.

У вас там в 2020 уже завезли бесконечную память и процессоры, делающие вычисления с double не медленнее float?

Вы приводите удобные примеры для оправдания своей позиции, это странный подход. Вот пример когда числа одни, а результат false:

0.1 + 0.2 == 0.1f + 0.2f

Кстати, во втором случае будет очевидная ошибка, ибо 1.5 воспринимается как double, а конвертировать во float без потери точности нельзя и запрещено компилятором.

Все видокарты эффективно работают только с f32

Ни разу, сейчас везде есть fp16, которые быстрее.

Ни разу, сейчас везде есть fp16,

fp16 в паскалях работает еще медленнее чем fp64. Так что он есть, только не везде его можно использовать. Только в новых GPU выпущенных за последний год fp16 работает с удвоенной скоростью.

Автовывод типов доступен начиная с java 10
var x = 1.5f;
Если выражение сложное, не всегда очевидно какой получится тип.

Вот ты херню сейчас написал.

Когда появится задача оптимизировать и нужно будет биться за каждый байт, тогда и отпадут такие тупые нападки.

2020 или 2010, а все равно есть куча встраиваемой дребедени, которая это требует, и да, на Java тоже. Не говоря уже о том, что Java может сама непосредственно на железке не работать, а вот кучу данных собирать и работать уже с ними, которые будут в этих всяких float.

Более того, к 2020 добавились еще куча нейросеток, где квантификация нормально так используется, если надо что-то оптимизировать. Например, засунуть нейросетку в мобильник, чтобы ты, анон, пользовался благами цивилизации быстро и удобно, а выходит, что ты просто хаишь то, о чем представления не имеешь.

В следующий раз когда буду на java под GPU писать, обязательно вспомню этот юзкейс. А потом проснусь и поржу.

о чем представления не имеешь.

нет ты

ну если учесть, что сейчас сетки пихают везде, то может и будет писать

учить навряд ли, но запускать можно

Там либы на C/C++ и обвязки поверх.

На самом деле не очень понятно, нафейхоа нужен float в 2020 году.

Я вот на это отвечал, нормальная производительность в числодробилках с флоатом сейчас только для f32, а так жабу конечно используют в основном в энетрпайзе и прочий бекенд, там 99% операциями целочисленная математика. Для Money отдельные сущности в которых fraction тоже целое числ.

А вообще я не вижу причины почему суфикс f при объявлении float обязательный кроме кейса с перегрузкой методов.

Можно представить что разработчикам компилятора было намного комфортнее наблюдать прозрачность трансляции java в байткод: задекларировал float и в байткоде операции с float. А short и byte в байткоде нету, так что они не пример.

нормальная производительность в числодробилках с флоатом сейчас только для f32

Даже если представить, что кто-то взял яву для числодробилки и теперь трясется над производительностью (клиника), вы точно уверены, что флоат будет быстрее на 64 битных процессорах? Я вот склоняюсь к тому, что все флоаты все равно будут переведены в дабл еще до операций. Ну это раз, а два — точности флоата точно хватит для числодробилки?

По всем трем пунктам садимся в лужу. Вывод: яве не нужен тип флоат. Он там только по причине совместимости с легаси и стронними библиотеками

Почему нет? HM — довольно быстрый в ограниченном варианте

Это не Hindley-Milner. Он так и называется «ограниченный вывод типов».

Патамушта (с) Если ты везде привыкнешь писать 1.5f то у тебя не будет проблем в неочевидных случаях, когда у тебя не 1.5f а 1f, или, как выше писали, когда у тебя две перегрузки под флоат и дабл

У явы в целом вербузность это одна из основных концепций языка, увы, в новых версиях от неё пытаются зачем-то уйти (ну типа лень многопечатать, зато не лень потом много отлаживаться), хотя именно яве бы стоило наоборот, накинуть вербузности относительно потенциальных null, но это лирика

По поводу флоатов, даблов и производительности - мне чот казалось (могу ошибаться) что под капотом это всё, по большей части, условности, и в итоге все выполняется в «наиболее эффективных на конкретной платформе типах» - для амд64 это вроде как даблы были

Однако (с) именно флоаты иногда нужны - не всё что написано, написано во времена «большой памяти» - есть кучка разных программ/библиотек/алгоритмов, которые оперируют именно флоатами (не обязательно на яве) и иногда надо что-бы результаты работы твоей и чужой программы совпадали. Аналогично, многие приборы общаются именно флоатами ибо это в ваших интернетах скорость измеряется мегабитами в секунду, у многих промышленных протоколов это в лучшем случае килобиты, а приборов на них навешивается дофига. С одной стороны никто не мешает обрабатывать пришедшие даблами, но опять-же, иногда нужно что-бы программа считала конечный результат так-же, как и аппаратная коробка на каком-нить МК, где и флоат то уже дорого, а зачем делать лишнюю работу по округлению даблов до флоатов руками?

Ну и дополнительный бонус - если тебе надо передать дофига дробных по сети или записать их в файлик, то логично что флоаты потребуют в два раза меньше трафика/места на диске - это важно, когда их реально много.

Вообщем дробные разные нужны, дробные разные важны.