If you're converting SQL values to their respective float and int values based on scale and precision like I am, there's a catch, here.
This is a slimmed-down version of the conversion logic I'm using :
<?php
$col = [
    'id' => $field_id,
    'name' => oci_field_name($statement, $field_id),
    'type' => oci_field_type($statement, $field_id),
    'scale' => oci_field_scale($statement, $field_id);
    'precision' => oci_field_precision($statement, $field_id);
]
$str_data = oci_result($statement, $field_id)
switch($col['type']) {
    case 'NUMBER':
        if ($col['precision'] !== 0 && $col['scale'] === -127) {
            $data = floatval($str_data);
        } else if($col['scale'] === 0) {
            $data = intval($str_data);
        } else {
            $data = floatval($str_data);
        }
        
        break;
    
    default:
        $data = $str_data;
        break;
}
echo("{$col['name']} : $str_data ({$col['type']} ({$col['precision']}, {$col['scale']})) -> $data\n");
?>
What the doc doesn't say is that any number column that was defined without a scale parameter counts as a plain NUMBER(), which always has a precision of 0 and a scale of -127, so they get interpreted as floats even when they should be integers.
What the doc also doesn't say is that __all analytics functions that return numbers return a plain NUMBER()__, so something like COUNT(*), RANK() or FIRST_VALUE(foo) is still going to net you a float.
Be careful with these if you have any type-sensitive code that relies on those values (I'm personally very fond of using type-hinting and strict_types = 1).