Почему PHP считает int числа после математических операций как float?

Question

[rinaz22]

Всем привет! Сегодня случайно заметил странный аномалий. По крайней мере мне показалось это именно аномалией.
Обычная форму расчета по проценту:

$sum = 400;
$all = $sum * (55 / 100);
var_dump($all); // На выходе float(220)

На выходе получаю просто 220, без запятых и прочего. Даже не 220.000000000001, а просто 220. Но если вывести через var_dump, то показывает как float, а не int.
Из-за этого у меня сломалось одно условие проверки больше-меньше.
Пробовал переменную $all перевести в string "{$all}", так условие заработало правильно, но так неправильно, поэтому решил поставить всю мат. операцию внутрь round.
После round все заработало как надо, но вот этот момент меня все же заинтересовал. Почему так произошло? С другими числами вроде такого не замечал, но именно с такими вводными выходит такая странность.

Answer 1

[ThunderCat]

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

Answer 2

[dim5x]

Поскольку 55 / 100 возвращает float, результат тоже будет float.

Если нужно целое число, можно использовать intval()

Comments

[Дмитрий]

Просто каст к int

[Vitsliputsli]

Дмитрий, очевидно имелось ввиду intdiv

[Дмитрий]

Vitsliputsli, самое простое и дёшевое это каст

[Vitsliputsli]

Дмитрий, извиняюсь, неправильно прочитал, почемуто подумал, что там деление 2х int-ов. А для float - да, проще каст.

Answer 3

[Vamp]

Все потому, что в операции деления у вас получается float, так как операнды не поделились друг на друга без остатка. Умножение int на float в дальнейшем тоже приводится к умножению float на float.

Answer 4

[Vitsliputsli]

Почему PHP считает int числа после математических операций как float?

Потому что именно такое поведение описано в документации. Вообще, чтение документации отвечает на большинство вопросов. Очень рекомендую всегда начинать с нее.

Answer 5

[Виктор Кожухарь]

Все коллеги, ответившие выше, правы. float заразен. Всё, чего он касается в математических выражениях, превращается во float.

Я лишь хотел посоветовать эдакий костыльный подход, который позволит вам не так сильно напрягаться, вспоминая, как же эти динамические языки приводят одно к другому.

Чем больше программисту надо держать в голове подобных правил динамических языков, тем больше в программе багов. Поэтому строгая типизация - это большое добро, ведь она минусует целый класс багов.

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

Попробуем использовать хотя бы то, что нам дали. Для этого будем придерживаться простого правила:

все вычисления всегда выносить в отдельные функции, а эти функции всегда типизировать по-максимуму.

Видим деление, умножение и т.д. - выносим это выражение в функцию. Это, конечно, не идеальное решение, но оно избавит нас хотя бы от какого-то количества проблем. Если в вашем случае вынести код в функцию, то результат не только будет целым числом, но PHP ещё и сообщение DEPRECATED нам выдаст.

<?php

$sum = 400;

// Было
$all = $sum * (55 / 100);
var_dump($all); // На выходе float(220.00000000000003)

// Стало
$all2 = calculateAll($sum);
var_dump($all2); // На выходе int(220)

function calculateAll(int $sum): int
{
    return $sum * (55 / 100);
}

Вывод

float(220.00000000000003)
PHP Deprecated:  Implicit conversion from float 220.00000000000003 to int loses precision in /Users/vitiok78/Downloads/float.php on line 12

Deprecated: Implicit conversion from float 220.00000000000003 to int loses precision in /Users/vitiok78/Downloads/float.php on line 12
int(220)

 

Comments

[Vitsliputsli]

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

Чем больше программисту надо держать в голове подобных правил динамических языков, тем больше в программе багов. Поэтому строгая типизация - это большое добро, ведь она минусует целый класс багов.

Неявные преобразования в языке, хоть с динамической, хоть со статической типизацией, это часть движка. А вот "строгая типизация", вернее явное указание типов переменных это опциональный инструмент в php. Поэтому первое нужно знать обязательно, к том же это прекрасный инструмент. А расчет что "строгая типизация" спасет - очень опасный путь.
Изучая типы используемые в языке, всегда изучаешь неявные преобразования, иначе невозможно. Например, мы знаем что int в php - это обычно int64, очевидно что возможно переполнение и нужно проверить как компилятор будет на него реагировать. В php реагировать он будет всегда одинаково - преобразует в float. И только потом, при записи в переменную может проверить ее тип.
Причем не обязательно знать все и вся, абсолютно неважно в какое конкретное значение string преобразовывается array (если такую хрень не использовать), но важно помнить, что получится строка, и без всяких ошибок.
Не говоря уже о том, что ошибки компиляции и runtime это совсем разные вещи в плане отладки.

[Виктор Кожухарь]

Vitsliputsli, Баги в программах появляются только потому, что мы люди. А чем больше всего программисту нужно держать в голове при написании программы, тем выше шансы внесения бага. Мы как LLM, можем держать в голове только определенное количество контекста. И если этот контекст переполняется, мы начинаем галлюцинировать багами в программе.
Задайте себе вопрос: зачем придумали Rust? Главная цель создания этого языка была в том, чтобы сделать работу с памятью безопасной. А почему это так сильно нужно было? Потому что программистам оказалось очень тяжело держать в голове информацию о том, где и когда они выделяли память, и где и когда надо её освобождать. Это чуть ли не главная проблема современности. Rust заставляет это делать при помощи своих механизмов, у человека теперь просто нет возможности внести такой баг.
Точно такая же логика касается языков с динамической типизацией. Человеку надо столько всего учитывать, что он просто иногда не справляется. Строгая типизация полностью исключает такие баги. Не зря потрачено столько времени и денег на создание Typescript. Этот язык чуть ли не стал стандартом в мире JavaScript на бэкенде.
PHP не пошёл таким радикальным путём, как Typescript, и я считаю это большой ошибкой. Совершенно понятно, что такое половинчатое решение было сделано ради совместимости. Но компромиссы редко приводят к чему-то толковому.

[Vitsliputsli]

Виктор Кожухарь, Понятно, что все в голове не удержишь, но типы это базис языка, в том числе их неявные преобразования. И, явное указание типов здесь никак не поможет. К примеру, в коде всем числам указали тип int (как у автора вопроса, потому что ему нужно целое число, а про другое он не читал), и вроде все работает, до дня Х, когда случится переполнение и следовательно конвертация в float и все ляжет. А точно нужно было так? Возможно float тоже вполне себе подошел бы? Но даже если нет, тогда нам бы следовало сделать проверку и выбросить нормальный эксепшн о превышении лимита для какой-то сущности, а не фатал: "не пихается float в int". Т.е. помощи здесь от явного указания типов 0. А вред от неизучения типов и их преобразований огромный.
Конечно польза от явных типов примитивов есть, но в отличии от языков со статической типизацией, это не более чем тупая проверка диапазона в надежде, что ошибка из него выбивается. Т.е. по-сути бизнесовая проверка, а не работа с памятью. Например, есть у нас id, целочисленный, мы обложились типом int и как бы норм, только вот id - это у нас все положительные целые числа, а int - это знаковые целые числа, обычно в диапазоне 64-бит. Диапазоны не совпадают, нужны еще проверки, но даже после них ничего не помешает пройти какому-нибудь абсолютно левому числу. И тут, гораздо эффективнее подключать типы ООП.

зачем придумали Rust? Главная цель создания этого языка была в том, чтобы сделать работу с памятью безопасной. А почему это так сильно нужно было? Потому что программистам оказалось очень тяжело держать в голове информацию о том, где и когда они выделяли память, и где и когда надо её освобождать. Это чуть ли не главная проблема современности.

Ну вот причем здесь Rust? Или выделение/освобождение памяти? Когда вы последний раз сталкивались с этой "главной проблемой современности" в php? Или вообще выделяли или освобождали память в php? Правильно, никогда, потому как у программиста там нет таких инструментов, совсем, все делается за него. И, каким боком такой сложный вопрос как выделение/освобождение памяти связан с проверками типа в php, т.е. с тупо сравнением? Это там, где типы проверяются на этапе компиляции, хотя бы тупо чтобы не прочитать как число данные, записанные как строка, там сложная работа с типами, в php где все данные маркированы типом это не нужно.

Точно такая же логика касается языков с динамической типизацией. Человеку надо столько всего учитывать, что он просто иногда не справляется. Строгая типизация полностью исключает такие баги.

Как написал выше не такая логика, и вообще ничего общего. Поэтому вопрос, что за "такие баги"?

Не зря потрачено столько времени и денег на создание Typescript. Этот язык чуть ли не стал стандартом в мире JavaScript на бэкенде.

Я хрен знает что такое "мир JavaScript", я так понимаю это мир из 2х языков: js и ts? Ну тогда чему удивляться, любой адекватный язык всяк лучше js. И да, обязательное явное указание типов примитивов в ts наверное правильное решение, т.к. основная аудитория это те, кто писал на js. Даже на этом форуме кто приходит с php-шным global закидывают какашками, а времена register_global вспоминают с ужасом. Но в сторону js, с его областью видимости луковицы и прототипами никто плохого не скажет, просто у ребят альтернативный взгляд. Настолько альтернативный, что не смотря на монополию в браузерах пришлось костылями ваять ts, чтобы как то совсем не потонуть.