title: Confusion over REST Assured floating-point comparisons
body: <p>The REST Assured <a href="https://github.com/rest-assured/rest-assured/wiki/Usage" rel="noreferrer">usage documentation</a> has examples like this:</p>
  
  <pre><code>get("/lotto").then().body("lotto.lottoId", equalTo(5));
  </code></pre>
  
  <p>OK, so they are using a Hamcrest matcher to compare to the int value <code>5</code>.</p>
  
  <p>But they have a section saying that the REST Assured JSON parser by default uses <code>float</code> and not <code>double</code>, so instead of comparing to <code>12.12</code> I should compare to <code>12.12f</code>:</p>
  
  <pre><code>get("/price").then().body("price", is(12.12f));
  </code></pre>
  
  <p>Wait, so how did <code>5</code> work above, which is an <code>int</code> and not a <code>double</code>? Does the JSON parser use different primitives for integer and non-integer values?</p>
  
  <p>But it gets more confusing. Well-versed programmers know that you shouldn't be comparing floating point values directly anyway (because of the intricacies of how floating-point values are stored, etc.). Instead you should use <a href="http://hamcrest.org/JavaHamcrest/javadoc/1.3/org/hamcrest/Matchers.html#closeTo%28double%2C%20double%29" rel="noreferrer"><code>Matchers.closeTo(double operand, double error)</code></a> which provides a margin of error. This is the correct way to do it. But wait --- even if I pass in <code>12.12f</code> to Matchers.closeTo(double operand, double error), isn't it still going to convert it to a <code>double</code>? Will this work with REST Assured?</p>