Bug? [SOLVED] Numberformat Output Wrong Value

[rwblinn]

[SOLVED] See Port #3.

Found a possible bug in NumberFormat.

Converting the ULong value 20250531 using NumberFormat(value, 0, 0) results in 20250532 instead 20250531?
So for this specific value 20250531 the result becomes off by 1 to 20250532.

Hardware: Arduino UNO, ESP32 Wrover-Kit. Software: B4R 4.00 (64-bit), Arduino-cli Version: 1.2.2

Test Code

#Region Project Attributes
    #AutoFlushLogs: True
    #CheckArrayBounds: True
    #StackBufferSize: 300
#End Region

Sub Process_Globals
    Public Serial1 As Serial
End Sub

Private Sub AppStart
    Serial1.Initialize(115200)
  
    Dim datetimestamp As ULong = 20250530
    LogULong(datetimestamp)
'    >>>
'    1 datetimestamp=20250530             
'    2 datetimestamp NumberFormat=20250530    <-- OK

    datetimestamp = 20250531
    LogULong(datetimestamp)
'    >>>
'    1 datetimestamp=20250531
'    2 datetimestamp NumberFormat=20250532    <-- BUG? 20250531 converted to 20250532
  
    datetimestamp = 20250532
    LogULong(datetimestamp)
'    >>>
'    1 datetimestamp=20250532
'    2 datetimestamp NumberFormat=20250532    <-- OK
End Sub

Private Sub LogULong(value As ULong)
    Log(">>>")
    Log("1 datetimestamp=", value)
    Log("2 datetimestamp numberformat=", NumberFormat(value, 0, 0))
End Sub

 

[janderkan]

Have you seen this

uLong to string changes value

Hello, I wrote a small program years ago to read out our rfid badges. Some recent cards showed up negative values. No problem but as I need to enter the badges into another system aswell I want to normalize things. So I switch everything from Long to uLong and all seemed fine until my eye...

www.b4x.com

 

[rwblinn]

Thanks = triggered the use of casting.

Have solved by casting first ULong to Long, then use Long to cast to string.

Dim ValueULong as ULong
' Check if value not exceeding Long max value
If ValueULong <= 2147483647 Then
  Dim ValueLong As Long = ValueULong
  Dim s As String = ValueLong
End If

 

[emexes]

Occurs because somewhere in original code, the value was converted to a 32-bit float, which is only accurate to 1 part in 16 million (approximately, more like 2^24 actually) and beyond that doesn't have enough bits to represent each and every integer number eg between 16 million and 32 million, every second number is skipped (ie missed).

I imagine it's happening in the B4R NumberFormat function, and there's probably nothing you can do to fix it, other than be aware of it.

 

[emexes]

This might be a better (more general) point to be aware of: in B4R, apparently Float and Double are both 32-bits (4-bytes):

The following data types are available in B4R:
Numeric types:
...
Double (4 bytes): 4 bytes floating point. Similar to Float in other B4X tools.
Float is the same as Double.

https://x.com/i/grok/share/ZIHYZoW6xKRpHaiSpZy4tVAyY

 

[rwblinn]

Thanks and yes I was aware of the data types - esp. from wrapping Arduino / ESP C++ libraries.

To note is that the issue came up for the Solar Info Panel project, i.e. on the display top left, the date 31.05.2025 was displayed as 32.05.2025.
The date DD.MM.YYYY, as string, is converted using NumberFormat (and some further formatting) from its value received from the HTTP RESTful server, i.e. 1547,0,1307,240,0,0,100,20250531,1440.
What I am planning is to change the RESTfull server response by splitting the date into YYYY,MM,DD, i.e. 1547,0,1307,240,0,0,100,2025, 5,31,1440 to avoid using Double/Float value.

 

[emexes]

the date into YYYY,MM,DD

Dates are slightly out of the resolution of 32-bit floats but fit nicely into 32-bit integers, even if they're signed (well, up to the year 214748 AD, anyway).