Is there any limitation in Hexadecimal/Octal/Binary number notation?

[nek]

It might be a stupid question, but I have to ask.
The results does not match between Windows Calc and Rainmeter. Is there any limitation in Hexadecimal/Octal/Binary number notation?
IfCondition=(0x7FFFFFFF=0xFFFFFFFF) returns True in the testing skin below.

Windows Calc app

WinCalc.png

About Rainmeter > Skins

RmLog.png

Testing skin

Code: Select all

[Rainmeter]
Update=-1
;DefaultUpdateDivider=-1
AccurateText=1

[0xFF]
Measure=Calc
Formula=0xFF

;; Decimal number
[4294967295]
Measure=Calc
Formula=4294967295

;; Hexadecimal number (4294967295)
[0xFFFFFFFF]
Measure=Calc
Formula=0xFFFFFFFF

;; Binary number (4294967295)
[0b11111111111111111111111111111111]
Measure=Calc
Formula=0b11111111111111111111111111111111

;; Octal number (4294967295)
[0o37777777777]
Measure=Calc
Formula=0o37777777777

;; Log says "True"
[sTest1]
Measure=String
IfCondition=(0x7FFFFFFF=0xFFFFFFFF)
IfTrueAction=[!Log "#CURRENTSECTION# | True" Warning]
IfFalseAction=[!Log "#CURRENTSECTION# | False" Warning]

[Meter1]
Meter=String
Text=Testing Number Notation
AntiAlias=1
FontColor=171717
FontSize=24
SolidColor=E5E5E5

0b - Binary number (base 2) (ex: 0b110110 - returns 54 in decimal)
0o - Octal number (base 8) (ex: 0o123 - returns 83 in decimal)
0x - Hexadecimal number (base 16) (ex: 0xF1 - returns 241 in decimal)

What I was trying to do is... Getting Windows Accent Color from Registry and convert to RGBA color code.
For example Formula=(4292311040&0xFF000000)>>24 expected value is 255, but Rainmeter returns 127 in [sAlpha] section.
Now Formula=(4292311040>>24)&0xFF got 255 as expected.

Code: Select all

 [HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\DWM]
 "AccentColor"=dword:ffd77800        >> ABGR(alpha-blue-green-red), 0xffd77800 is 4292311040 in decimal.

Code: Select all

[Rainmeter]
Update=-1
;DefaultUpdateDivider=-1
AccurateText=1

;; Hex 0xFFD77800, Dec 4292311040
[sAccentColor]
Measure=Registry
RegHKey=HKEY_CURRENT_USER
RegKey=SOFTWARE\Microsoft\Windows\DWM
RegValue=AccentColor

;; Hex 0x00, Dec 0
[sRed]
Measure=Calc
Formula=sAccentColor&0xFF

;; Hex 0x78, Dec 120
[sGreen]
Measure=Calc
;Formula=(sAccentColor&0xFF00)>>8
Formula=(sAccentColor>>8)&0xFF

;; Hex 0xD7, Dec 215
[sBlue]
Measure=Calc
;Formula=(sAccentColor&0xFF0000)>>16
Formula=(sAccentColor>>16)&0xFF

;; Hex 0xFF, Dec 255
[sAlpha]
Measure=Calc
;; 0xFF000000 does not work. in Rainmeter 4.5.13.3632 / 2022-03-23 15:23:40
;Formula=(sAccentColor&0xFF000000)>>24
Formula=(sAccentColor>>24)&0xFF

[Square]
Meter=Image
W=100
H=100
;; 0,120,215,255
SolidColor=[sRed],[sGreen],[sBlue],[sAlpha]
DynamicVariables=1

https://forum.rainmeter.net/viewtopic.php?p=209192#p209192

Code: Select all

Rainmeter 4.5.13.3632 (64-bit)
Language: English (1033)
Build time: 2022-03-23 15:23:40
Windows 10 Pro 2009 64-bit (build 19043) - Japanese (1041)

---

Rainmeter has bitwise shift operators << >>
📗 Formula Syntax 📜 MathParser.cpp 📘 C++ operator precedence

[SilverAzide]

It might be a stupid question, but I have to ask.
The results does not match between Windows Calc and Rainmeter. Is there any limitation in Hexadecimal/Octal/Binary number notation?
IfCondition=(0x7FFFFFFF=0xFFFFFFFF) returns True in the testing skin below.

Could the conversion from binary/hex/octal be using signed integers internally?

[Active Colors]

https://forum.rainmeter.net/viewtopic.php?t=14896#p84009

https://forum.rainmeter.net/viewtopic.php?t=11022#p63059

Maybe Brian one day will update his SysColor plugin

[nek]

To Developers

Just ignore my stupid question.

---

Edited 2022-08-17

I don't understand C++ code, but I can feel something from the code!
I am not a programmer, so it could be wrong, I gave it a try.

number.bases.data.type.png

0b - Binary number (base 2) (ex: 0b110110 - returns 54 in decimal)
0o - Octal number (base 8) (ex: 0o123 - returns 83 in decimal)
0x - Hexadecimal number (base 16) (ex: 0xF1 - returns 241 in decimal)

MathParser.cpp - Rainmeter Repository on GitHub

Code: Select all

switch (lexer.string[1])
{
case L'x':	// Hexadecimal
	num = wcstol(lexer.string, &newString, 16);
	break;

case L'o':	// Octal
	num = wcstol(lexer.string + 2, &newString, 8);
	break;

case L'b':	// Binary
	num = wcstol(lexer.string + 2, &newString, 2);
	break;

default:
	valid = false;
	break;
}

wcstol Convert wide-character string to a long integer value. 📘
wcstod Convert wide-character string to a double-precision value. 📘

Data Type Ranges - Microsoft Docs

data.type.range.png

---

Conclusion:

Code: Select all

 [HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\DWM]
 "AccentColor"=dword:ffd77800
 ; [ff(255)] alpha?, [d7(215)] blue, [78(120)] green, [00(0)] red
 ; 0xffd77800 is 4292311040 in decimal.
 ; 0xffd77800 is 1111 1111 1101 0111 0111 1000 0000 0000 in binary.

Why the code for retrieving the alpha value Formula=(4292311040 &0xFF000000) >>24 returns 127 not 255(0xFF)?
Because maximum value of a hexadecimal number is 0x7FFFFFFF.

Formula=(4292311040 &4278190080) >>24 should work and returns 255. (0xFF000000 is 4278190080 in decimal)
or Formula=(4292311040 >>24) &0xFF returns 255

[Yincognito]

It appears the conclusions here are correct - I didn't know about this particularity of hexa numbers in Rainmeter, thanks for pointing it out. So, it appears my old base converter skin will not yields the correct result when using a hexa notation as a starting point, despite the code being correct:

Code: Select all

[Variables]
Number=0xFFFFFFFF
Quotient=(#Number#)
Result=""
Base=10

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1

---Measures---

[MeasureConvert]
Measure=Calc
Formula=(#Quotient#%#Base#)
UpdateDivider=-1
RegExpSubstitute=1
Substitute="^10$":"A","^11$":"B","^12$":"C","^13$":"D","^14$":"E","^15$":"F","^16$":"G","^17$":"H","^18$":"I","^19$":"J","^20$":"K","^21$":"L","^22$":"M","^23$":"N","^24$":"O","^25$":"P","^26$":"Q","^27$":"R","^28$":"S","^29$":"T","^30$":"U","^31$":"V","^32$":"W","^33$":"X","^34$":"Y","^35$":"Z"
IfCondition=((#Quotient#)<>0)
IfTrueAction=[!SetVariable Result "[MeasureConvert]#Result#"][!SetVariable Quotient (Trunc(#Quotient#/#Base#))][!UpdateMeasure "MeasureConvert"]
IfConditionMode=1
DynamicVariables=1

---Meter---

[MeterConvert]
Meter=STRING
X=5
Y=5
FontFace=Consolas
FontColor=255,255,255,255
SolidColor=47,47,47,255
Padding=5,5,5,5
FontSize=16
AntiAlias=1
Text="Number = #Number##CRLF#Base   = #Base##CRLF#Result = #Result#"
DynamicVariables=1

0xFFFFFFFF to Decimal.jpg

however, the reverse (i.e. Number=4294967295 and Base=16) will, giving the expected FFFFFFFF:

4294967295 to Hexadecimal.jpg

Again, I come to the conclusion that strings are more reliable than numbers, especially in these cases. Not only the base conversion is a case of string manipulation, but representing the 0x... hexa number as a string could, in theory, avoid the type overflow problem.

P.S. I posted an adjustment of this in the related thread, in case it will be needed someday.

[Brian]

This has been "fixed" for the next release. Thanks for reporting!

By "fixed", I really mean that I changed the data type to support larger numbers. But there will still be a limit, plus there is some truncation converting from an integer based data type to a floating point data type. This is unavoidable since all measure values are stored internally as floating point data type (double).

-Brian