Arithmetic shifts
[1/12] from: jacereda:users:sourceforge at: 17-Aug-2004 3:30
Hi all,
How can I perform an arithmetic shift (or a floored division) in REBOL?
TIA,
Jorge Acereda
[2/12] from: tomc:darkwing:uoregon at: 16-Aug-2004 23:32
the simplest way is
n: to-integer (n / 2)
On Tue, 17 Aug 2004, [ISO-8859-1] Jorge Acereda Maci=E1 wrote:
[3/12] from: greggirwin:mindspring at: 17-Aug-2004 0:56
Hi Jorge,
JAM> How can I perform an arithmetic shift (or a floored division) in
JAM> REBOL?
to integer! value / radix
(newer betas have a mezzanine ROUND function with a /floor refinement)
-- Gregg
[4/12] from: carl:cybercraft at: 17-Aug-2004 19:43
>Hi Jorge,
>
>JAM> How can I perform an arithmetic shift (or a floored division) in
>JAM> REBOL?
>
>to integer! value / radix
Note that to-integer (or to integer!) isn't always required to return an integer with
division...
>> type? 3 / 2
== decimal!
>> type? 4 / 2
== integer!
>> type? 12 / 4
== integer!
Which also allows us to do the likes of this...
>> x: 5 and 254 / 2
== 2
>> type? x
== integer!
I suspect this has speed advantages too, though I've not done any tests.
-- Carl Read
[5/12] from: carl:cybercraft at: 17-Aug-2004 19:54
>Note that to-integer (or to integer!) isn't always required to return an
>integer with division...
<<quoted lines omitted: 10>>
>== integer!
>I suspect this has speed advantages too, though I've not done any tests.
Have now and indeed it does...
>> t: now/time/precise loop 1000000 [2 / 2]print now/time/precise - t
0:00:00.93
>> t: now/time/precise loop 1000000 [2 / 2]print now/time/precise - t
0:00:00.94
>> t: now/time/precise loop 1000000 [2 / 2]print now/time/precise - t
0:00:00.94
>> t: now/time/precise loop 1000000 [3 / 2]print now/time/precise - t
0:00:01.43
>> t: now/time/precise loop 1000000 [3 / 2]print now/time/precise - t
0:00:01.43
>> t: now/time/precise loop 1000000 [3 / 2]print now/time/precise - t
0:00:01.37
And using AND's quicker than TO INTEGER! too...
>> t: now/time/precise loop 1000000 [3 and 254 / 2]print now/time/precise - t
0:00:01.59
>> t: now/time/precise loop 1000000 [3 and 254 / 2]print now/time/precise - t
0:00:01.59
>> t: now/time/precise loop 1000000 [3 and 254 / 2]print now/time/precise - t
0:00:01.54
>> t: now/time/precise loop 1000000 [to integer! 3 / 2]print now/time/precise - t
0:00:02.85
>> t: now/time/precise loop 1000000 [to integer! 3 / 2]print now/time/precise - t
0:00:02.86
>> t: now/time/precise loop 1000000 [to integer! 3 / 2]print now/time/precise - t
0:00:02.8
-- Carl Read
[6/12] from: tomc:darkwing:uoregon at: 17-Aug-2004 2:03
On Tue, 17 Aug 2004, Carl Read wrote:
> >Note that to-integer (or to integer!) isn't always required to return an
> >integer with division...
<<quoted lines omitted: 41>>
> 0:00:02.8
> -- Carl Read
it may be faster but what results are you getting?
I see things like
>> 1 and 3 / 2
== 0.5
and it does not fill me with confidence that you are doing what you hope
to be doing, precedence is left to right so what you may be seeing is
>> 3 and 254
== 2
>> 2 / 2
== 1
>> 3 and 255 / 2
== 1.5
[7/12] from: jacereda:users:sourceforge at: 17-Aug-2004 11:25
On 17/08/2004, at 8:32, Tom Conlin wrote:
>
> the simplest way is
>
> n: to-integer (n / 2)
But that fails for n=-1. It yields 0, an arithmetic shift should return
-1.
[8/12] from: jacereda::users::sourceforge::net at: 17-Aug-2004 11:56
On 17/08/2004, at 9:43, Carl Read wrote:
>> Hi Jorge,
>>
<<quoted lines omitted: 15>>
>>> type? x
> == integer!
The to-integer approach seems invalid for my purposes, but this one
seems correct:
fdiv: func[n1 [integer!] n2 [integer!]][
n1 and (negate n2) / n2 ]
ashift: func [n [integer!] amount [integer!]][
fdiv n to-integer (2 ** amount)]
ashift -1 10
== -1
Thanks to all for your responses.
Jorge Acereda
[9/12] from: tomc:darkwing:uoregon at: 17-Aug-2004 9:27
On Tue, 17 Aug 2004, [ISO-8859-1] Jorge Acereda Maci=E1 wrote:
yes, you would need an either negative? ...
But there has been alot of work on a round function that does all that
and more. it should not be hard to find, and is slated to make it into the
next major release.
[10/12] from: greggirwin:mindspring at: 17-Aug-2004 15:07
Hi Jorge,
>> n: to-integer (n / 2)
JAM> But that fails for n=-1. It yields 0, an arithmetic shift should return
JAM> -1.
What it should return depends on whether you want a signed or unsigned
shift; both are valid. Glad you figured out a solution though.
-- Gregg
[11/12] from: gabriele:colellachiara at: 18-Aug-2004 13:41
Hi Tom,
On Tuesday, August 17, 2004, 11:03:14 AM, you wrote:
TC> it may be faster but what results are you getting?
The results are correct because he is dropping the least
significant bits with AND. So you AND with 254 if you are dividing
by 2, 252 if you are dividing by 4, 244 for 8 and so on.
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/
[12/12] from: carl:cybercraft at: 19-Aug-2004 0:52
>> And using AND's quicker than TO INTEGER! too...
>>
<<quoted lines omitted: 30>>
>>> 3 and 255 / 2
>== 1.5
Hi Tom. I missed your reply. Sorry about that, though I see Gabriele's answered it.
Anyway, using AND only makes sense if you're used to playing with Boolean arithmetic.
But as you can see by the times returned above, the gains can be worth it. Using 254
(11111110 in binary) for divisions by 2 only works with 8-bit numbers though - if you
had larger numbers, say up to 16 bit, you'd need to use 65534 (11111111 11111110 in binary),
and larger numbers up to 32 bit.
Which has just got me thinking. Does this answer Jorge's negative value problem...?
>> x: -2
== -2
>> 4 and x / 2
== 2
>> 3 and x / 2
== 1
>> 2 and x / 2
== 1
>> 1 and x / 2
== 0
>> 0 and x / 2
== 0
>> -1 and x / 2
== -1
>> -2 and x / 2
== -1
>> -3 and x / 2
== -2
The -2 there works (I think) because it creates a signed 32bit value with just the least
signifigant bit set to 0. (You'd up the value for greater powers of 2.)
Jorge - would this work for you?
-- Carl Read
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted