Re: [PHP] variable type - conversion/checking

Sorry if I'm missing something, there's a lot of replies after my first
post on this thread.

Is there something wrong with the "floor()" approach? I liked the regex
solution but isn't it more expensive and more verbose than just doing a
well commented "is_numeric" plus "floor/ceil" math?

Just trying to understand the motivations behind the preferences.

Thanks.


On Sun, Mar 17, 2013 at 7:17 PM, Matijn Woudt <[email protected]> wrote:

> On Sun, Mar 17, 2013 at 10:20 PM, Maciek Sokolewicz <
> [email protected]> wrote:
>
> > On 16-3-2013 19:20, Matijn Woudt wrote:
> >
> >> On Sat, Mar 16, 2013 at 6:52 PM, Maciek Sokolewicz <
> >> [email protected]> wrote:
> >>
> >>  Hi,
> >>>
> >>>>
> >>>> I have tried to find a way to check if a character string is possible
> to
> >>>> test whether it is convertible to an intger !
> >>>>
> >>>> any suggestion ?
> >>>>
> >>>> BR georg
> >>>>
> >>>>
> >>> All responses in this thread have been very nice; but you could also
> try
> >>> a
> >>> much simpler 2-step check:
> >>>
> >>> 1. is_numeric
> >>> 2. if true > check if there's a decimal character in the string:
> >>>
> >>> if(is_numeric($str) && false === strpos('.', $str)) {
> >>>     // it's an int for sure
> >>> } else {
> >>>     // might be a number, but it's definitly not an int
> >>>
> >>> }
> >>>
> >>>
> >> Wrong.  is_numeric will accept 1e1, which is a float, so you would need
> to
> >> check for e or E too.
> >>
> >> - Matijn
> >>
> >>  Although in theory I agree, indeed any e* number is treated as a
> > floating point number. However, considering the exponent and the base are
> > forced to be integer numbers (due to exclusion of decimal points), in the
> > real number system, you will *always* end up with a natural number, i.e.
> > integer. Regardless of your input.
> >
> > So as a result, the input could always be interpreted as an integer,
> > without any precision-loss using the method above.
> > - Tul
> >
>
> Except... that it might not fit in an 32 or 64 bit integer, which would
> lead to precision loss.
>
> - Matijn
>