We're seeing an issue with Lucee 5.4.5.23 where it's changing the precision of numbers. When I run the following SQL using the MSSQL JDBC driver, I get

17.7999992

instead of

17.8

(which Lucee 5.4.3.2 returns):

select cast(17.8 as real)

Any idea what's going on? See this thread for more details: https://dev.lucee.org/t/sql-precision-issue-with-lucee-5-4-5-23/13697

I don't know the reason why but yes, I found this same issue last week. We're not planning on upgrading Lucee just yet so it was added to out list if things to check before we do - and it is a showstopper for us at this point.

Since I have not heard from anyone on the Lucee dev team on my report of this issue (in both the Lucee Dev Forums and in LDEV-4780), I've gone ahread and filed a new bug: https://luceeserver.atlassian.net/browse/LDEV-4827 I know the Lucee team works really hard (and @zackster was putting in a ton of time helping the dev community), but it feels like the whole team has been basically on radio silence for the last 6 months or so.

agreed. even down to the almost non existent release announcement for 6.

https://en.wikipedia.org/wiki/IEEE_754 It's pretty standard behavior for floating point numbers, actually. If you want greater precision, you should use decimal or another datatype besides float. Float is always an approximation

What you said about floats is correct. However, this breaks code that has worked for a long time (and changes the way that ACF works). I don't see a reason for the change, but I'm sure @micha had one. However, I think the issue is that since he's using

doubleValue()

on a float, it's cause the conversion. I would think changing the code from:

if (n instanceof Double || n instanceof Float) return toString(n.doubleValue());

to this:

if (n instanceof Double ) return toString(n.doubleValue());
if (n instanceof Float) return toString(n.floatValue());

would resolve the bug, since then it would correctly casting the float to a string.

Yeah, that seems at least like a better solution for sure, it's just that expecting floats to be 'exact' is inherently a problem.

I'm not expecting them to be exact, but if SQL Server returns

17.8

I am expecting Lucee to also report

17.8

(especially when that's always been the way it worked previously).