I’m just taking a look at roLongInteger. As far as I can tell, it suffers from the same shortcoming as roDouble. Namely, there’s no way to go back and forth to/from strings. Am I missing something? I have some monotonically increasing values that I’m worried will eventually overflow 32-bits. Currently I store them in the registry using toStr() and then use toInt() to convert the string back to an integer. There’s no toLongInt() that I’ve found.
When I ran across this issue with doubles, I used Eval. The same thing could be done for LongInts:
Now I’ve been told that Eval has been deprecated and also leaks memory. So… am I missing something simple? Is there really a problem if I use Eval a half a dozen times or so at the beginning of my code and then never again until it exits?
You can use .ToStr() on LongIntegers and Doubles to get a fixed format decimal representation, but you are correct that there aren’t currently any global Str() or Val() functions to work with them.
You can however use FormatJson and ParseJson to get the functionality.
(Note that ParseJson will only emit LongInteger for integer values that don’t fit in Integer, and will only emit Double for floating point values that don’t fit in Float).
BrightScript Debugger> n&=5123456789
BrightScript Debugger> s=n&.ToStr()
BrightScript Debugger> var
n& LongInteger refcnt=1 val:5123456789 (&h13161BF15)
s roString (2.1 was String) refcnt=1 val:"5123456789"
BrightScript Debugger> ss=FormatJson(n&)
BrightScript Debugger> var
n& LongInteger refcnt=1 val:5123456789 (&h13161BF15)
s roString (2.1 was String) refcnt=1 val:"5123456789"
ss roString (2.1 was String) refcnt=1 val:"5123456789"
BrightScript Debugger> nn&=ParseJson(s)
BrightScript Debugger> var
n& LongInteger refcnt=1 val:5123456789 (&h13161BF15)
s roString (2.1 was String) refcnt=1 val:"5123456789"
ss roString (2.1 was String) refcnt=1 val:"5123456789"
nn& LongInteger refcnt=1 val:5123456789 (&h13161BF15)
Thanks! That should do nicely and probably a lot better than using Eval. I’ve always thought it’s an oversight not to have ifStringOps akin to toInt() and toFloat() for Doubles and now LongIntegers, so I hope they’re somewhere on a ToDo list.
“renojim” wrote:
I’ve always thought it’s an oversight not to have ifStringOps akin to toInt() and toFloat() for Doubles and now LongIntegers, so I hope they’re somewhere on a ToDo list.
-JT
The specifics of the bug aren’t important. Suffice it to say that some values > &h80000000 work and some don’t.
Now why it’s mildly concerning:
That was taken from a Roku Stick running FW v7.1.0 build 4096-24. The same test on a Roku 3 with FW v7.2.0 build 4091-04 works just fine.
Does it make sense to report a bug in a FW version that’s less than the latest? Keep in mind that there’s still a good number of devices unable to update to v7.2.
For my purposes, I can either set the minimum firmware version to 7.2 or just leave it at 7.0 (when LongInteger appeared) since my counters aren’t likely to need more than 32 bits for quite some time and, even if one does overflow, it’s completely harmless. I’ll probably go with the latter.
The specifics of the bug aren’t important. Suffice it to say that some values > &h80000000 work and some don’t.
Now why it’s mildly concerning:
That was taken from a Roku Stick running FW v7.1.0 build 4096-24. The same test on a Roku 3 with FW v7.2.0 build 4091-04 works just fine.
Does it make sense to report a bug in a FW version that’s less than the latest? Keep in mind that there’s still a good number of devices unable to update to v7.2.
For my purposes, I can either set the minimum firmware version to 7.2 or just leave it at 7.0 (when LongInteger appeared) since my counters aren’t likely to need more than 32 bits for quite some time and, even if one does overflow, it’s completely harmless. I’ll probably go with the latter.
-JT
Does it make sense to report a bug in a FW version that’s less than the latest?
In general it will only be fruitful to report bugs that occur in the current firmware, but if you are seeking advice / workarounds for older firmware that’s valid too.
There were definitely fixes in 7.2 with respect to numeric parsing etc.
Just to confirm, your use case(s) works correctly on 7.2, right?
Keep in mind that there’s still a good number of devices unable to update to v7.2.
I can’t speak to details, but my impression is that the Roku-branded 7.2 rollout should be nearing completion.
“RokuKC” wrote:
There were definitely fixes in 7.2 with respect to numeric parsing etc.
Just to confirm, your use case(s) works correctly on 7.2, right?
Correct.
“RokuKC” wrote:
I can’t speak to details, but my impression is that the Roku-branded 7.2 rollout should be nearing completion.
I’m stilling seeing users on 7.0, so I’m wondering if they’re going to jump to 7.2?
I’m still seeing users on 7.0, so I’m wondering if they’re going to jump to 7.2?
Roku Stick running FW v7.1.0 build 4096-24
If you are seeing a non-trivial #/percentage of active/ongoing reports of users with Roku Stick (platform 24) with firmware version < 7.2 that seems like a problem.
If you have more other data with model #s / platform IDs, and country code if non-US, of your client devices reporting < 7.2 that you can share, I can forward it for investigation.
I can’t say I’m seeing many Sticks. Most of what I’m seeing are Model 5000X (TVs). In the last week I’ve seen about 6% of all devices with FW < 7.2 and of those 85% are TVs. In addition, 17% of devices with FW < 7.2 have v7.0.x.
I’m counting total pennies in one of my games. It’s purely informational and may or may not ever need more than 32 bits. I just figured I’d use LongInteger since it’s available. If it weren’t and the counter just wrapped around, it would be no big deal.
If one gets a penny for every second they play, it will take 2^31 seconds or 68 years to reach the horizon and they’ll have $21M at that point
(do you offer cash out option? :twisted: )
For counting money though, just use Double - per IEEE it’s guaranteed to preserve at least 15 digits during conversion. Which means you can hold amounts up to the US federal budget ($3+ trillion) with precision down to a cent. The nice thing is that even if exceeding that, it will start “failing” in a nice way, i.e. losing the cents like IRS does. Not to mention there is 2 hidden digits precision (it works internally at 17 decimal digit precision equivalent).
“renojim” wrote:
But what if it’s 1000000 pennies at a time?
Then you can afford yourself ~2000 of these $10,000 wins.
Or if you switch to Double - which i advocate - then can handle 1,000,000,000 events like the above, which if they happen 1/sec would take 30+ years to lose the penny precision (not to overflow!). And after that, umm… why do you exactly need to pinch every penny?
