Integers vs. integer-valued floats

[geraintluff]

@fge said in #25:

Also, consider validating:

1.0

against:

{ "type": "integer" }

Do you really expect that to succeed? I don't ;)

I disagree, because for me, 1.0 is an integer. I would absolutely expect that to validate.

I believe that {"type: "integer"} is completely equivalent to {"type": "number", "divisibleBy": 1}. It was at one point removed because it was redundant, and re-introduced because it was concise and intuitive.

Thoughts from anyone else?

[fge]

For me it isn't. 1.0 is a float. It is a float in the vast majority of programming languages. Even Python:

fge@alustriel:~/src/work/stratus$ python
Python 2.7.3 (default, Aug  1 2012, 05:14:39) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> isinstance(1.0, int)
False

And again, type does lexical analysis, not mathematical analysis. Which is why I explicitly changed "equality" to "lexical equivalence".

It is unlike keywords which operate on numeric instances: these do validate mathematically. But type doesn't.

[geraintluff]

@fge

1.0 is a float

I don't think "float" should even be one of the options here. "Float" is nothing to do with the number's value - it is to do with the way that value is encoded for a computer to use. Unless we're going to start caring about 32-bit vs. 64-bit floats, then I don't think we should care about "float"s versus "int"s.

I think that 1.0 is a "real number", and also an "integer".

Your Python example is also concerned with the computer's internal representation, not the value. My example would be:

>>> 1.0 == 1
True

[fge]

Some more technical ground: the basis for this differentiation is RFC 4627, section 2.4. A JSON number is:

• an optional minus sign,
• followed by a series of digits (the integer part) with no leading zeroes,
• followed by either a fractional part (which is also a series of digits), or an exponent part.

And an integer as defined by the spec is a number without a fractional or exponent part. 1.0 has a fractional part, as such it is not an integer.

[fge]

This is because Python does type coercion, therefore this is legal. Now, look at:

>>> import json
>>> a = json.loads("1.0")
>>> b = json.loads("1")
>>> a == b
True
>>> isinstance(a, int)
False
>>> isinstance(b, int)
True

Java:

public class Foo
{
    public static void main(final String... args) throws IOException
    {
        final ObjectMapper mapper = new ObjectMapper();
        final JsonNode n1 = mapper.readTree("1.0");
        final JsonNode n2 = mapper.readTree("1");

        System.out.println(n1.equals(n2));


    }
}

This prints false.

And there is "worse": if I tell (as I do in my implementation) Jackson to use BigDecimal for floats, it will go the full way on and even find that 1.0 and 1.00 are not the same.

By default it doesn't use BigDecimal however, because of... JavaScript compatibility. But JSON Schema is language independent, and this is also why I can accurately validate that 1.000000000000000000000000000000000000000000000000000000000000001 fails { "maxiimum": "1" }.

In any event, this is not that important, since the JSON RFC also tells that parsers may limit the range of available numbers etc, and numeric instances are very likely to be coerced by the vast majority of parsers. However, JSON Schema doesn't, and shouldn't, care. If it did, this would essentially cripple its usefulness.

[geraintluff]

Errr... if you're taking your definition of integer as the "integer component" (int) part of that definition, then you're not even allowed negative numbers.

int = zero / ( digit1-9 *DIGIT )

So I don't think that's a good guide.

[geraintluff]

I'm aware that the == result is due to type coercion. But I think a relevant question is: why is it doing type coercion?

It's doing type coercion because when you're comparing two numbers it makes no sense to compare their representations - what really matters is their values. The class structure you're checking using isinstance is an artefact of the programming language, and my point is I don't think that sort of thing is relevant to whether a number is an integer or not.

If I saw this Python code:

def isinteger(val):
    return isinstance(val, int)

I would be a bit confused. What I would expect is something like this:

def isinteger(val):
    return (val % 1) == 0

because that tests the mathematical properties of the value, not the internal representation.

[ghhenry]

Lets do some examples. Should the instance 1.0 validate against the schemata

{ "type": "integer" }

I think both approaches have pros and cons. For tools it is much easier to recognize integers on syntactical properties than on mathematical value. For example, would the mathematical value 1+1^-30 be an integer? Most tools would say yes.

{ "enum": [10e-1] }

I would expect that to validate. According to the current text it does not.

{ "enum": [1.00] }

same with this.

{ "maximum": 1, "minimum": 1 }

valid.

{ "multipleOf": 1 }

valid.

Another construct where equality plays a role is the unique constraint. I think it should use the same equality definition as enum.

EDIT: missing array inserted

[fge]

Errr... if you're taking your definition of integer as the "integer component" (int) part of that definition, then you're not even allowed negative numbers.

Yes, I am. RFC 4627, section 2.4: "A number contains an integer component that may be prefixed with an optional minus sign, which may be followed by a fraction part and/or an exponent part." And the definition of an integer reflects that in the current writing:

   integer  A JSON number without a fraction or exponent part (see RFC 4627, section 2.4) [RFC4627].

[fge]

Again:

• enum and type do lexical validation;
• maximum and others do mathematical validation.

Those are NOT the same thing at all!

[geraintluff]

enum does lexical validation

That is, more or less, what I'm objecting to. You have decided that enum should perform lexical validation, and that enum and type operate under a different set of principles to maximum, minimum and divisibleBy. I am saying that they shouldn't - when it comes to numbers, all constraints should be on their mathematical values, not on their textual or binary representations.

[fge]

I don't see at all where format enter the picture here, except that its support is optional.

And I fail to see a problem at all, however. Well yes, there will be one: this means that each time you encounter a numeric node within an enum, you will have to evaluate mathematically instead of lexically? Sorry, but that is incoherent.

This is why, in the other thread, I mentioned that maybe there should be a dedicated keyword with a discrete set of numbers. I certainly don't want to cripple enum (or type, for that matter) the way you say, and I am quite sure the vast majority of people will agree with me.

[geraintluff]

My apologies: I meant type, not format

[ghhenry]

For strings and numbers we have the situation that the same abstract value can be represented by different literals. In my opinion equality should work with the abstract values not with the text representing them. For strings we already agreed, that "O" and "\u004f" are the same value. (However, this is not so clear from the current text.) Why would it be different for the numbers 1.0 and 1.00?

This still leaves the possibility open, that integers and "floats" (i.e. numbers represented with a fractional part or an exponential part) are different types with no values in common although this seems to be in contradiction to RFC 4627.

[geraintluff]

@fge "Sorry, but that is incoherent."

Are you saying you don't understand what I'm describing?

I believe that numbers are a mathematical construct. When validating, their constraints should also be mathematical.

The JSON standard does not list integers as a separate type from numbers, and I don't think we should either. I think {"type": "integer"} is simply a convenient shorthand for {"type": "number", "divisibleBy": 1}.

@fge "I am quite sure the vast majority of people will agree with me"

Confidence is good. :) I am also confident in my viewpoint.

@ghhenry - I agree.