Unsigned Bitshift

[WhiteDragon]

Hello all,

Since Stefan thought it would be hilarious to ignore my PM, I'll ask in here.

I'm trying to do a unsigned bitshift to the right (equiv of >>> in some other dynamically typed languages).

However, Graal does not provide any operator for this, nor a method to cast your signed integer to an unsigned integer.

I would also like to get past the max signed int value.

If anyone has experienced this problem before and has a solution, let me know!

Thanks

[Novo]

From what I know, Graal encodes the values as string-representations... So there is no true 'type' of variable. value = 12 and value = "12" is the same thing!

The best way to do the bit-shift is just... number = number >> 2;
This would work for unsigned values... And would do a bit-shift!

There is no special signed bit-shift around.

As for the max integer... Because values are numbers represented by strings... There is no real boundary.

You might want to look here for basic operators:
http://wiki.graal.net/index.php/Crea...uide#Operators

[Inverness]

Originally Posted by Novo

From what I know, Graal encodes the values as string-representations... So there is no true 'type' of variable. value = 12 and value = "12" is the same thing!

The best way to do the bit-shift is just... number = number >> 2;
This would work for unsigned values... And would do a bit-shift!

There is no special signed bit-shift around.

As for the max integer... Because values are numbers represented by strings... There is no real boundary.

You might want to look here for basic operators:
http://wiki.graal.net/index.php/Crea...uide#Operators

WhiteDragon is of sufficient skill to be able to tell if Graal has a max integer value or not. If he says he's hitting the limit then you should do a test for yourself right now before saying otherwise.

[Skyld]

Originally Posted by Novo

From what I know, Graal encodes the values as string-representations... So there is no true 'type' of variable. value = 12 and value = "12" is the same thing!

...

As for the max integer... Because values are numbers represented by strings... There is no real boundary.

Well, there is, because when you perform a mathematical operation on a string, it is converted from a string to a float/int internally so the same restrictions apply.

[xXziroXx]

Skyld double posting, epic moment.

[Skyld]

Originally Posted by xXziroXx

Skyld double posting, epic moment.

Shows how awesome my internet connection is.

[Inverness]

If Graal could implement something like Python's long integer, then we could have infinitely sized numbers.

[napo_p2p]

Originally Posted by Novo

The best way to do the bit-shift is just... number = number >> 2;
This would work for unsigned values... And would do a bit-shift!

Sometimes you go over the max positive value and it "wraps around" to the lowest negative value. I guess this may have been why he also asked about getting past the max value.

[WhiteDragon]

Well, for those who are interested, I did get a reply from Stefan about a week ago (after PMing him again):

Graal is using floating-point numbers (64 bit), for bit-wise operation it's converting to 32-bit signed integer and back to floating point. It could theoretically be possible to use 64-bit integers for that, for what kind of stuff do you need it?

However, he never responded to what I sent back to him.
And also, I think Stefan was talking about numbers on the server rather than on the client, because it would obviously be impossible to have a 64-bit integer on a 32-bit processor.

Even if the client did support 64-bit numbers, that isn't even what I'm looking for. I am specifically looking for an unsigned 32-bit integer, so I can make use of the overflow that is commonly used in many algorithms and hash functions.


And in reply to Inverness' post about Python's long integer, although having an arbitrary-precision arithmetic library would be useful, it would also be very slow because of the time complexity it takes to do arbitrary-precision operations.



Basically the only way I can pull off exactly what I'm trying to do is with direct access to unsigned 32-bit integers, not some slow pseudo-big-integer.

I can't think of any way to do this without Stefan intervening unless he has done so before and someone remembers how he said to do it.

[Inverness]

Originally Posted by WhiteDragon

And in reply to Inverness' post about Python's long integer, although having an arbitrary-precision arithmetic library would be useful, it would also be very slow because of the time complexity it takes to do arbitrary-precision operations.

I don't think you'll find a more efficient implementation than Python's. And Python uses a trailing L to differentiate between the long object (arbitrary), and the int object (signed 32-bit).

Though in Python 3.0 the long object is being removed and the int object will behave as a long did. I'm sure this would not be done unless their implementation was efficient enough to warrant it. The source code is available for you to view on your own

[WhiteDragon]

Originally Posted by Inverness

I don't think you'll find a more efficient implementation than Python's. And Python uses a trailing L to differentiate between the long object (arbitrary), and the int object (signed 32-bit).

Though in Python 3.0 the long object is being removed and the int object will behave as a long did. I'm sure this would not be done unless their implementation was efficient enough to warrant it. The source code is available for you to view on your own

It's not really a matter of "more efficient" when there is a upper bound on the mathematical model required to do arbitrary-precision operations.

Where two n-digit numbers:
Addition and subtraction take O(n)
For multiplication and division, they either use the Toom-Cook (O(n**1.465)) or Schonhage-Strassen (O(n * log n * log log n)) algorithm based on the size of the integer.

These are the accepted time complexities for arbitrary-precision operations, which makes certain algorithms horribly inefficient compared to doing the operations directly with the processor.


And in response to your "efficient enough to warrant it" comment, there is a reason that algorithms are coded in ASM and C++ rather than Python. When finer granularity is needed for something you wouldn't use a high-level language like Python.


However, something as simple as a unsigned bit-wise shift should be possible in GraalScript, which is why I'm inquiring Stefan.