[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Floats and %d
- From: William Ahern <william@...>
- Date: Tue, 21 Jul 2015 13:14:17 -0700
On Mon, Jul 20, 2015 at 02:14:36PM -0700, Parke wrote:
> On Sat, Jul 18, 2015 at 11:29 AM, Rena <firstname.lastname@example.org> wrote:
> > In any case, I'm still wishing Lua would truncate for %d. I keep ending up
> > with seemingly harmless UI code crashing with a "number has no integer
> > representation" error, and ugly floor() littered everywhere. It reminds me
> > of having to use tostring() with %s in earlier versions (a similar case
> > which annoyed me as well). But perhaps I'm alone here...
> You are not alone. After reflection, truncation for %d makes sense to me.
> In Lua 5.2, %d would truncate. In Python also.
> Is anyone willing to suggest that the error in Lua 5.3 has value?
Many people might argue that automagic coercion like this hides more bugs
than it fixes. I'm not once of those people, but it's a reasonable argument.
Also, the internal implementation rightly takes care to fail when losing
information in a coercion. luaL_checkinteger calls lua_integerx and errors
when lua_integerx says the value wasn't an integer. Your suggested fix in
this one case would make the implementation's treatment of coercions less
consistent. For example, the bit operators use luaL_checkinteger. Are you
also suggesting that the following should work?
print(2.7 >> 1)
Is it worth the inconsistency in both the language semantics as well as the
> > string.format("%d", 2.7)
> In this case, string.format does not have to convert 2.7 to an integer
> (although it could). string.format in this case is converting a float
> to a string, and the request for truncation is not hidden, it is
> explicit in %d.
It's not explicit. Explicit would be
I don't do much floating point math, but AFAIU truncation is not always the
_obvious_ choice. It appears a natural choice to me, but I don't do much
There's significant tension in Lua regarding strict typing versus automatic
coercions. IIRC, over the years there have been suggestions to make code
like this fail:
Be careful what you ask for. You may end up getting the complete opposite.
The Lua authors might eventually believe the creeping complexity of coercion
rules detracts from the simplicity of the language and it's implementation.
IMO, permitting 2.0 to coerce to 2, but not 2.7, seems like a very sensible
approach. And sticking to this rule also seems very sensible because it's
principled--it emphasizes value preservation, without the burdens of
worrying about context or strict typing. If you start having to worry about
context (whether it should coerced or truncated in one construct but not
another), strict typing might seem like the simpler approach overall.