Graal Forums

Graal Forums (https://forums.graalonline.com/forums/index.php)
-   NPC Scripting (https://forums.graalonline.com/forums/forumdisplay.php?f=8)
-   -   Unsigned Bitshift (https://forums.graalonline.com/forums/showthread.php?t=82600)

WhiteDragon 11-01-2008 02:24 AM

Unsigned Bitshift
 
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 11-20-2008 07:27 PM

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 11-20-2008 09:30 PM

Quote:

Originally Posted by Novo (Post 1443645)
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 11-20-2008 10:54 PM

Quote:

Originally Posted by Novo (Post 1443645)
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 11-20-2008 11:18 PM

Skyld double posting, epic moment.

Skyld 11-20-2008 11:23 PM

Quote:

Originally Posted by xXziroXx (Post 1443665)
Skyld double posting, epic moment.

Shows how awesome my internet connection is.

Inverness 11-20-2008 11:39 PM

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

napo_p2p 11-21-2008 04:35 AM

Quote:

Originally Posted by Novo (Post 1443645)
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 11-21-2008 05:28 AM

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

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 11-21-2008 05:49 AM

Quote:

Originally Posted by WhiteDragon (Post 1443720)
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 :p

WhiteDragon 11-21-2008 06:13 AM

Quote:

Originally Posted by Inverness (Post 1443727)
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 :p

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.


All times are GMT +2. The time now is 02:44 PM.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2025, vBulletin Solutions Inc.
Copyright (C) 1998-2019 Toonslab All Rights Reserved.