The lua manual also states that one should NOT rely on the implicit conversion of a string to its numerical value, and suggests the systematic use of tonumber(). Alan On Thu, 9 Aug 2018 21:20:54 +0200 Pablo Rodriguez wrote:

On 08/09/2018 08:12 PM, Wolfgang Schuster wrote:

...

Use tonumber.

Many thanks for your reply, Wolfgang.

The issue is in Lua itself:

print(5+"5")

In versions prior to 5.3, result is "10".

From version 5.3, result is "10.0",

I would say this might be a bug. According to the “Lua 5.3 Reference Manual" (https://www.lua.org/manual/5.3/manual.html#3.1):

A numeric constant with a radix point or an exponent denotes a float; otherwise, if its value fits in an integer, it denotes an integer.

Well, "10.0" contains the radix point, but with no arithmetical relevance.

My background is in humanities and I don’t understand the exponent for being a float ("10²" contains an exponent [https://www.m-w.com/dictionary/exponent], but I would say is an integer in all possible worlds [or all the worlds I know ]).

Could anyone explain me what am I missing here or confirm whether this is a bug?

Many thanks for your help,

Pablo

On Thu, 9 Aug 2018 22:00:48 +0200 Pablo Rodriguez wrote:

I guess that backwards compatibility should be important here, but I hope there are stronger reasons for breaking it.

tonumber() provides backwards compatibility. And the recommendation to use it was in the third edition (of the lua book), if not before, referring to 5.2. Alan

On Sat, 11 Aug 2018 11:29:41 +0200 Pablo Rodriguez wrote:

On 08/09/2018 10:16 PM, Alan Braslau wrote:

...

On Thu, 9 Aug 2018 22:00:48 +0200 Pablo Rodriguez wrote:

...

I guess that backwards compatibility should be important here, but I hope there are stronger reasons for breaking it.

tonumber() provides backwards compatibility. And the recommendation to use it was in the third edition (of the lua book), if not before, referring to 5.2.

I realize that the fault is mine, but with backwards compatibility I meant that the same operation (10 + "10") gives different results with different Lua versions.

Pablo

"Bad" coding can be expected to give unpredictable results. The creators of lua thought that automatic string conversion would be useful (and I believe that they got this feature from "awk", which itself may have gotten this from some previous scripting language). But they learned that automatic string conversion often creates more problems than it solves, so they recommend using explicit conversion through tonumber(). Lua is a very beautiful and powerful language, and it gives me surprises all of the time. Much of what Hans does I like to call "lua magic" meaning that I sort-of understand it but am impressed each time. Does this make lua a poor (problematic) scripting language? I think like all powerful tools, one must take care in their use. Alan

On 8/9/2018 10:00 PM, Pablo Rodriguez wrote:

On 08/09/2018 09:34 PM, Alan Braslau wrote:

...

The lua manual also states that one should NOT rely on the implicit conversion of a string to its numerical value, and suggests the systematic use of tonumber().

Many thanks for your reply, Alan.

I guess that backwards compatibility should be important here, but I hope there are stronger reasons for breaking it.

Many thanks for your help, In addition to what others already explained, you should not depend on features that are implementation dependent or might disappear. That said ...

\startTEXpage[offset=1em] \ctxlua{context([[\lastpage]])}. \stopTEXpage Why do you convert \lastpage to a string using [[\lastpage]] which will use the string to number conversion. In fact this automatic cast from string to number in an addition might disappear from the language in the future so don't rely on that. You can just do: \startTEXpage[offset=1em] \ctxlua{context(\lastpage + 1)}. \stopTEXpage Or when in dount about what \lastpage is \startTEXpage[offset=1em] \ctxlua{context(\number\lastpage + 1)}. \stopTEXpage or if you really want to [[ ]] \startTEXpage[offset=1em] \the\numexpr\ctxlua{context([[lastpage]] + 1)}\relax . \stopTEXpage endless possibities here. Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

On 9 Aug 2018, at 21:20, Pablo Rodriguez wrote:

A numeric constant with a radix point or an exponent denotes a float; otherwise, if its value fits in an integer, it denotes an integer.

Well, "10.0" contains the radix point, but with no arithmetical relevance.

My background is in humanities and I don’t understand the exponent for being a float ("10²" contains an exponent [https://www.m-w.com/dictionary/exponent], but I would say is an integer in all possible worlds [or all the worlds I know ]).

Could anyone explain me what am I missing here or confirm whether this is a bug?

It may refer to a floating point number syntax as in C++ [1], where the three cases top there say that there must be a point '.' preceded or followed by at least one digit, or at least one digit followed by an exponent starting with 'e' or 'E'. There are also some examples on that page. Also note that there are no negative numbers, which is because a leading + or - are treated as operators that apply not only to numbers. 1. https://en.cppreference.com/w/cpp/language/floating_literal

On 11 Aug 2018, at 11:33, Pablo Rodriguez wrote:

On 08/09/2018 10:20 PM, Hans Åberg wrote:

...

...

On 9 Aug 2018, at 21:20, Pablo Rodriguez wrote: [...] My background is in humanities and I don’t understand the exponent for being a float ("10²" contains an exponent [https://www.m-w.com/dictionary/exponent], but I would say is an integer in all possible worlds [or all the worlds I know ]).

It may refer to a floating point number syntax as in C++ [1], where the three cases top there say that there must be a point '.' preceded or followed by at least one digit, or at least one digit followed by an exponent starting with 'e' or 'E'.

Many thanks for your explanation, Hans.

You are welcome.

I thought there should be some kind of restriction when referring to the exponent, but this is why technical explanations aren’t always very clear. I mean, they have too many restrictions attached to them.

The C++ description allows for fast reading with just one lookahead character at a time, which is was important in C when it appeared in 1972 on the not so powerful computers of the day. Then roundoff may make floating point numbers look like integers even they are not. For example, 1.0 could be 0.99999999 or 1.0000001. So don't check floating numbers for equality, instead use say abs(x - y) < a for some small number a. When adding exact integers and inexact floating point numbers, it is easiest to always make that inexact numbers, as exactness cannot always be guaranteed.