B4J Question B4J and unsigned long?

[giggetto71]

Hi Guys,
I need to use unsigned long in my application but if use long I think B4J mean signed long.
so for power(2,63) I get 9223372036854775807 while I would like to get 9223372036854775808.
thanks for your help.

 

[agraham]

Java, and hence B4A and B4J, doesn't support any unsigned integer types. It was a deliberate design decision taken when implementing the Java language.

 

[giggetto71]

thanks agraham, my problem is that I am working on a chess program and the chess board is made of 64 squares. having the possibility to use the 64 bit of a long to denote if a square is occupied or not is extremely convenient and enables very elegant and efficient operations using bitwise operands and long.
any library? inline-C or anything I could use ?

 

[agraham]

If you only need bitwise operations then a signed long will work fine.

 

[giggetto71]

sorry for coming back on this but I have read here https://en.wikipedia.org/wiki/Java_version_history that the unsigned arithmetic was actually introduced in SE 8.
Any hope to get that available in B4j?
thanks

 

[agraham]

I have to admit that I was totally unaware of this. It is however a rather awkward hack of adding static methods to the boxed integer classes. You could quite easily implement a class or code module to do this in B4A and B4J. For example unsigned comparison

Sub CompareUnsigned(l1 As Long, l2 As Long) As Int
    Dim jo As JavaObject
    jo.InitializeStatic("java.lang.Long")
    Return jo.RunMethod("compareUnsigned", Array As Object (l1, l2))
End Sub

 

[OliverA]

having the possibility to use the 64 bit of a long to denote if a square is occupied or not is extremely convenient and enables very elegant and efficient operations using bitwise operands and long.

If you only need bitwise operations then a signed long will work fine

For the requirement that you posted, @agraham’s answer is the correct answer. Why are you still exploring another solution?

 

[giggetto71]

I am exploring further (and I have already apologised for that) for the following reasons:

- my application is a chess engine and one key feature of a chess engine is the ability to detect trasnpositions (positions already analysed). to do that you need a way to map a position to a number (Zobrist keys).now the number of chess positions is numerical absurd so you can only mitigate the risk of so called "collisions" (same Zobrist key for different position) by using big keys (64 or even more..). They have demonstrated that you can expect a collision every about 2 billions position if you use a 64 bit while with a 32bit key, as I am using now, the number of collisions is way way higher and that reduces greatly the benefit of a hash table.

- I have already been given by @Erel and @agraham solutions which essentially make use of 8 byte arrays converted to signed long and XORArray to XOR. the XOR operations are done milions of times every seconds (actually at the moment I hardy do 1M nodes per second...but I will get there...) so having native long arithmetic would save a lot of computations (I guess there is a reason why 99% of chess engines are coded in C...). also the Zobrist keys must be positive as they are used to index the hash table itself.

Bottom line..right now I am using 32 bit and that 's fast but generating several collisions so I may decide to go for the array of bytes and XOR array to get to the 64 bits but of course I would be much much happier if I had a native unsigned arithmetic (type and XOR) I could get the benefits of reduced collision without paying computational horse power...

 

[Erel]

The next version of B4J will include long bitwise methods.

 

[giggetto71]

Yes! Yes! Yes!