What would "-0" mean (as a number) ... I've seen it as value of display.screenOriginX

[sieler2]

Hi,

While exploring properties of display objects, I did:

   print (display.screenOriginX)

I see: -0

(yes, negative zero!)

   print (type (display.screenOriginX))

I see: number

(as expected)

I see this behaviour on the simulator and on an Android (current version Android).

I see it for both screenOriginX and screenOriginY, but not for safeScreenOriginX or safeScreenOriginY.

I know there’s no such thing as “negative 0” in Lua, so … ?

Oddly, I can do:

   n = display.screenOriginX

   print (n)          – I see:   -0

   print (n + 0)    – I see:   0

   print (n + n)    – I see:   -0

thanks,

Stan

[roaminggamer]

It’s just a side-effect of internal calculations and the fact that the number is represented with a signed type.

https://en.wikipedia.org/wiki/Signed_zero
 
These values should still be be treated as zero, but if you’re worried you can clean them.
 
I run into this issue in SSK when calculating certain global variables.  I fix these my rounding them to zero decimal places.
https://github.com/roaminggamer/SSK2/blob/master/ssk2/core/variables.lua
 
 
Stan: You didn’t say for what device you see these.  Obviously it can’t be all…  Also, since we (readers) don’t know what is in your config.lua we can’t be sure how to reproduce this.

(FYI - I do of course know that using letterbox, a fixed resolution, and a device of that resolution will do this…  I’m just saying, “Always provide details about your configuration and test device(s) for posts like this.”)

[roaminggamer]

Just for fun, in the same setup do this:

local n = display.screenOriginX print (n, (n) \< 0, n == 0) print (n + 0, (n+0) \< 0, (n+0) == 0) print (n + n, (n+n) \< 0, (n+n) == 0)

see how these are detected as zero?

[davebollinger]

>>I know there’s no such thing as “negative 0” in Lua, so … ?

but there is, as lua uses ieee754 double-precision floating point, which defines this value (as well as the sign of results deriving from it)

essentially -0 exists so that there is a “harmony” with -infinity, in the same way that 0/infinity go together – it simplifies the encoding of division overflow (when division is understood as multiplication of the reciprocal and the limit is taken, then you can kinda/sorta define division by zero, upholding the signed relationship 1/(1/x)=x).

the only real oddity about negative zero is that there now exists a negative number that is not less than zero!

(since -0 is defined to be equal to 0, thus -0 < 0 is false)

but for all practical purposes just ignore it

[sieler2]

Thanks, all.

@roaminggamer I hadn’t realized config might influence this, sorry.

My config:

local aspectRatio = display.pixelHeight / display.pixelWidth application = { content = { --graphicsCompatibility = 1, -- This turns on Graphics 1.0 Compatibility mode width = aspectRatio \> 1.5 and 640 or math.ceil( 960 / aspectRatio ), height = aspectRatio \< 1.5 and 960 or math.ceil( 640 \* aspectRatio ), scale = "letterbox", fps = 30, imageSuffix = { ["@2x"] = 1.5, ["@4x"] = 3.0, }, }, }

[davebollinger]

having already said that you can ignore it, here’s more in-depth as to the “why”, IFF you’re curious…

for sake of discussion, let’s imagine you have a simpler/typical config, width=320, height=480, still letterbox.

your content aspect ratio is 3:2 (ie 480:320), so consider what happens on a 4:3 (fe ipad) device:  you’ll end up with

display.actualContentWidth = 360 – 40 extra pixels of letterbox added to match device aspect ratio

display.actualContentHeight = 480

let’s also assume you’ve left xAlign=“center”, so those 40 pixels of letterbox will be evenly divided on left/right sides of content.  Intuitively, you’d expect display.screenOriginX to be -20.  that is, that actual x zero of the screen is 20 content pixels left of where content-x == 0.

there are several ways you could word the “equation” that determines the screen origin values.  I’m pretty sure (i’ll explain why later *) that corona internally words it something like this (considering only the single case of xAlign=“center”, to simplify):

screenOriginX = -(actualContentWidth - contentWidth)/2

screenOriginX = -(360-320)/2

screenOriginX = -20

so far so good, but…

now consider what happens if you run on a 4:3 aspect device that matches your content aspect ratio, then

display.actualContentWidth = 320 – 0 extra pixels of letterbox added

display.actualContentHeight = 480

now run the math above:

screenOriginX = -(320-320)/2

screenOriginX = -(0)/2

screenOriginX = -0

and there’s your negative zero.

* corona could “fix” this weird negative zero if they chose to, just by restructuring their math.  if you instead distribute the negative sign through the equation, you’d get a positive zero, fe:

screenOriginX = (contentWidth-actualContentWidth)/2 – will produce identical result, except when zero

– 4:3 aspect device case

screenOriginX = (320-360)/2

screenOriginX = -20 – still correct

– 3:2 aspect device case

screenOriginX = (320-320)/2

screenOriginX = 0 – positive zero

(ie, the solution is to word the equation such that it avoids using an explicit “negate”)

[roaminggamer]

It’s just a side-effect of internal calculations and the fact that the number is represented with a signed type.

https://en.wikipedia.org/wiki/Signed_zero
 
These values should still be be treated as zero, but if you’re worried you can clean them.
 
I run into this issue in SSK when calculating certain global variables.  I fix these my rounding them to zero decimal places.
https://github.com/roaminggamer/SSK2/blob/master/ssk2/core/variables.lua
 
 
Stan: You didn’t say for what device you see these.  Obviously it can’t be all…  Also, since we (readers) don’t know what is in your config.lua we can’t be sure how to reproduce this.

(FYI - I do of course know that using letterbox, a fixed resolution, and a device of that resolution will do this…  I’m just saying, “Always provide details about your configuration and test device(s) for posts like this.”)

[roaminggamer]

Just for fun, in the same setup do this:

local n = display.screenOriginX print (n, (n) \< 0, n == 0) print (n + 0, (n+0) \< 0, (n+0) == 0) print (n + n, (n+n) \< 0, (n+n) == 0)

see how these are detected as zero?

[davebollinger]

>>I know there’s no such thing as “negative 0” in Lua, so … ?

but there is, as lua uses ieee754 double-precision floating point, which defines this value (as well as the sign of results deriving from it)

essentially -0 exists so that there is a “harmony” with -infinity, in the same way that 0/infinity go together – it simplifies the encoding of division overflow (when division is understood as multiplication of the reciprocal and the limit is taken, then you can kinda/sorta define division by zero, upholding the signed relationship 1/(1/x)=x).

the only real oddity about negative zero is that there now exists a negative number that is not less than zero!

(since -0 is defined to be equal to 0, thus -0 < 0 is false)

but for all practical purposes just ignore it

[sieler2]

Thanks, all.

@roaminggamer I hadn’t realized config might influence this, sorry.

My config:

local aspectRatio = display.pixelHeight / display.pixelWidth application = { content = { --graphicsCompatibility = 1, -- This turns on Graphics 1.0 Compatibility mode width = aspectRatio \> 1.5 and 640 or math.ceil( 960 / aspectRatio ), height = aspectRatio \< 1.5 and 960 or math.ceil( 640 \* aspectRatio ), scale = "letterbox", fps = 30, imageSuffix = { ["@2x"] = 1.5, ["@4x"] = 3.0, }, }, }

[davebollinger]

having already said that you can ignore it, here’s more in-depth as to the “why”, IFF you’re curious…

for sake of discussion, let’s imagine you have a simpler/typical config, width=320, height=480, still letterbox.

your content aspect ratio is 3:2 (ie 480:320), so consider what happens on a 4:3 (fe ipad) device:  you’ll end up with

display.actualContentWidth = 360 – 40 extra pixels of letterbox added to match device aspect ratio

display.actualContentHeight = 480

let’s also assume you’ve left xAlign=“center”, so those 40 pixels of letterbox will be evenly divided on left/right sides of content.  Intuitively, you’d expect display.screenOriginX to be -20.  that is, that actual x zero of the screen is 20 content pixels left of where content-x == 0.

there are several ways you could word the “equation” that determines the screen origin values.  I’m pretty sure (i’ll explain why later *) that corona internally words it something like this (considering only the single case of xAlign=“center”, to simplify):

screenOriginX = -(actualContentWidth - contentWidth)/2

screenOriginX = -(360-320)/2

screenOriginX = -20

so far so good, but…

now consider what happens if you run on a 4:3 aspect device that matches your content aspect ratio, then

display.actualContentWidth = 320 – 0 extra pixels of letterbox added

display.actualContentHeight = 480

now run the math above:

screenOriginX = -(320-320)/2

screenOriginX = -(0)/2

screenOriginX = -0

and there’s your negative zero.

* corona could “fix” this weird negative zero if they chose to, just by restructuring their math.  if you instead distribute the negative sign through the equation, you’d get a positive zero, fe:

screenOriginX = (contentWidth-actualContentWidth)/2 – will produce identical result, except when zero

– 4:3 aspect device case

screenOriginX = (320-360)/2

screenOriginX = -20 – still correct

– 3:2 aspect device case

screenOriginX = (320-320)/2

screenOriginX = 0 – positive zero

(ie, the solution is to word the equation such that it avoids using an explicit “negate”)