# SKIP with *very* large values

### [1/18] from: greggirwin:mindspring at: 15-May-2002 16:21

OK, I'm not expecting to ever need the use values this large with SKIP, but
I'm a little puzzled by the behavior.

>> skip [1 2 3] 99999999999999999999

== []

>> skip [1 2 3] 999999999999999999999

== [1 2 3]

>> skip [1 2 3] -99999999999999999

== [1 2 3]

>> skip [1 2 3] -999999999999999999

== []

>> skip [1 2 3] -9999999999999999999

== []

>> skip [1 2 3] -99999999999999999999

== []

>> skip [1 2 3] -999999999999999999999

== [1 2 3]
Any thoughts?
--Gregg

### [2/18] from: tomc:darkwing:uoregon at: 15-May-2002 23:01

thoughts? sure ... promises no.
overall geuss, your decimal! is interperted as an integer.
either the set of bits begins with 1 it is taken as a negative skip
and since before the head is still the head, the block is returned
orherwise the set of bits is interpeted as a large positive skip value
and beyond the tail is still the tail so the tail of tour block is
returned.
time to test the theory

>> a: [ 1 2 3]

== [1 2 3]

>> b: tail a

== []

>> c: skip a 99999999999999999999

== []

>> equal? b c

== true

>> d: head a

== [1 2 3]

>> f: skip a 999999999999999999999

== [1 2 3]

>> equal? d f

== true
at least it does not disprove the theory :)
On Wed, 15 May 2002, Gregg Irwin wrote:

### [3/18] from: carl:cybercraft at: 16-May-2002 21:27

On 16-May-02, Gregg Irwin wrote:

> OK, I'm not expecting to ever need the use values this large with
> SKIP, but I'm a little puzzled by the behavior.

<<quoted lines omitted: 13>>

> == [1 2 3]
> Any thoughts?
I'd think it's due to the maths routines your OS uses, as on Amiga I
don't get the results you get, the positive numbers all returning an
empty block and the negative ones a full one. What do you get when
you enter just the numbers at the Console? ie...

>> 99999999999999999999

== 1E+20

>> 999999999999999999999

== 1E+21

>> -99999999999999999

== -1E+17

>> -999999999999999999

== -1E+18
--
Carl Read

### [4/18] from: greggirwin:mindspring at: 16-May-2002 10:49

Carl and Tom,
Thanks for the thoughts. I figured it was wrapping around, but I'm still not
clear why. In any case, I don't think it should.
<< What do you get when you enter just the numbers at the Console? >>
The same thing you do. Here's what I get:

>> 99999999999999999999

== 1E+20

>> 999999999999999999999

== 1E+21

>> -99999999999999999

== -1E+17

>> -999999999999999999

== -1E+18
--Gregg

### [5/18] from: nitsch-lists:netcologne at: 16-May-2002 12:14

Am Donnerstag, 16. Mai 2002 00:21 schrieb Gregg Irwin:
this large numbers are automatically converted to decimals.
could be skip does not like that?

>> skip [1 2 3] 2

== [3]

>> skip [1 2 3] 2.0

== [1 2 3]
bug, to feedback?
-volker

### [6/18] from: tomc:darkwing:uoregon at: 16-May-2002 21:36

the 'Why' has to do with how numbers of different sizes are represented
by machines.
for regular everyday integers not "far" from zero the computer uses a
fixed number of bits to represent it, independent of the number of bits
required to express the number, typicaly 16,32 or 64 bits with 32 being
most common now.
example using 8 bits:
101 is five represented in binary using three bits
00000101 is five represented in binary using eight bits (just as 005 = 5)
any number from 0 to (2^8 - 1) can be represented in these eight bits
or 256 distinct values (this would be called an "unsigned integer").
however this does not allow for negative integers
So the first bit (leftmost) can be reserved as a negative flag)
in which case
10000101 is negative five represented in binary using eight bit integer
in this case we have 7 bits to represent the value or 0 thru (2^7 - 1)
and -2^7 (this would be called a "signed integer")
on the (64 bit) machine I am sitting at I can find the cutoff point where
a value is to large to fit in a rebol integer which is appearently 32
bits.

>> (power 2 31) - 1

== 2147483647

>> type? 2147483647

== integer!

>> type? 2147483648

== decimal!

>> type? -2147483647

== integer!

>> type? -2147483648

== decimal!

>>
>> to-integer 2147483648

** Math Error: Math or number overflow
** Where: to-integer
** Near: to integer! :value
so numbers <= -2^31 or >= 2^31 must be expressed differently
a simplified floating point number scheme is to take those same 32 bits
keep the first one as the sign flag the next 8 as a signed exponent (e)
and the remaining 23 as a "normalized" base (b)
where b is between 1 and 2
so the 32 bits as a floating point number can _approximate_ values
in the (+/-)2^((+/-)2^7) range or numbers with 38 or 39 decimal digits
to make the aproximation point clear:

>> 99999999999999999999 = 99999999999999999998

== true
even tho it is easy to see they are not equal as integers
rebols decimals! seem larger than standard 32 bit floating point and
smaller than standard 64 bit floating point so I'm really not sure how
they are represented.
but it is clear that skip should not accept values which are not discrete
unit steps.
i.e.

>> skip foo 3.14159

is hard to make sense of (like half a hole or a little bit pregnant)
when you ask for

>> skip foo 99999999999999999999

you are also asking for

>> skip foo 99999999999999999998.323322

because they _are_ the same decimal! value
so I do not think it is a bug that skip returns nonsense when it gets
nonsense but the doc could indicate non-integer numbers! are invalid
as arguments.
aside:
if you were wondering just how big a decimal! gets ...

>> big: copy "" loop 64 [append big "9"]

== {9999999999999999999999999999999999999999999999999999999999999999}

>> type? load big

== decimal!

>> append big "1"

== {99999999999999999999999999999999999999999999999999999999999999991}

>> type? load big

** Syntax Error: Invalid integer --
99999999999999999999999999999999999999999999999999999999999999991
** Near: (line 1)
99999999999999999999999999999999999999999999999999999999999999991
more than the 39 places for a 32 bit float
and far less than the 308 places of a 64 bit float
On Thu, 16 May 2002, Volker Nitsch wrote:

### [7/18] from: carl:cybercraft at: 17-May-2002 17:59

On 16-May-02, Volker Nitsch wrote:

> this large numbers are automatically converted to decimals.
> could be skip does not like that?

<<quoted lines omitted: 3>>

> == [1 2 3]
> bug, to feedback?
Definately bugged...

>> skip [1 2 3] 2

== [3]

>> skip [1 2 3] 2.0

== []
That's with Amiga View.
Will you report it Gregg?
--
Carl Read

### [8/18] from: carl:cybercraft at: 18-May-2002 0:29

On 17-May-02, Tom Conlin wrote:

> so I do not think it is a bug that skip returns nonsense when it
> gets nonsense but the doc could indicate non-integer numbers! are
> invalid as arguments.

The datatype 'skip accepts is number!, not integer! ...

>> ? skip

USAGE:
SKIP series offset
DESCRIPTION:
Returns the series forward or backward from the current position.
SKIP is an action value.
ARGUMENTS:
series -- (Type: series port)
offset -- Can be positive, negative, or zero. (Type: number)
but I guess that's for the larger integers floats allow so that bigger
series can be handled. Still, I do think we should get an error if
decimals are not to be used. We get them with 'copy for instance...

>> copy/part [1 2 3 4] 2

== [1 2]

>> copy/part [1 2 3 4] 2.2

** Script Error: Invalid /part count: 2.2
** Near: copy/part [1 2 3 4] 2.2
--
Carl Read

### [9/18] from: rotenca:telvia:it at: 17-May-2002 18:02

Hi,

> > bug, to feedback?
>
> Definately bugged...

Skip and others functions accept a number! datatype.
I don't find any documentation about this datatype in Core.
Where is it? Or it does not exist?
---
Ciao
Romano

### [10/18] from: greggirwin:mindspring at: 17-May-2002 10:48

Hi Carl,
I reported mine Carl. Do you want me to report yours (2 vs 2.0) as well?
--Gregg

### [11/18] from: nitsch-lists:netcologne at: 17-May-2002 21:59

Am Freitag, 17. Mai 2002 07:59 schrieb Carl Read:

> On 16-May-02, Volker Nitsch wrote:
> > this large numbers are automatically converted to decimals.

<<quoted lines omitted: 14>>

> == []
> That's with Amiga View.
looks like skip uses the raw memory content of the decimal
as an integer. the decimal encoding is different across
plattforms (today usually ieee, but amiga?).
there is the exponent ("binary decimal point") mixed with the mantissa
(the "integer" part). if one accesses a float as integer in c for example
it looks pretty strange.
Hmm, could one of the "patch function argument gurus" fix this
with an integer! - restriction until a new release? ;)

> Will you report it Gregg?

greetings
Volker

### [12/18] from: g:santilli:tiscalinet:it at: 18-May-2002 11:35

Hi Romano,
On Friday, May 17, 2002, 6:02:33 PM, you wrote:
[number!]
RPT> Where is it? Or it does not exist?
A NUMBER! is an INTEGER! or a DECIMAL!. (It's a pseudo-datatype,
like ANY-BLOCK! etc.)
BTW,

>> pick [1 2 3] 2.2

== 2
which shows some series functions actually work with decimals.
Regards,
Gabriele.
--
Gabriele Santilli <

**[g--santilli--tiscalinet--it]**> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r### [13/18] from: carl:cybercraft at: 18-May-2002 16:46

On 18-May-02, Gregg Irwin wrote:

> Hi Carl,
> I reported mine Carl. Do you want me to report yours (2 vs 2.0) as
> well?

Well, it wasn't mine, I just confirmed it on Amiga. Just forward that
email as another example of a problem with 'skip.
--
Carl Read

### [14/18] from: joel:neely:fedex at: 18-May-2002 10:06

Hi, Carl and Romano,
Carl Read wrote:

> On 18-May-02, Romano Paolo Tenca wrote:
> > Skip and others functions accept a number! datatype.

<<quoted lines omitted: 4>>

> series! datatype refers to string, blocks and so on. Thus integer!
> and decimal! datatypes are both also number! datatypes...
I think the REBOL documentation (somewhere) calls these "metatypes".
For those who know other languages, I'd say that they are closer
to the Java concept of "interface" than the Smalltalk concept of
supertype
-- although the REBOL type system isn't at all OO.
-jn-
--
; Joel Neely joeldotneelyatfedexdotcom
REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip
do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] {
| e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]

### [15/18] from: rotenca:telvia:it at: 18-May-2002 17:29

Hi Carl, Gabriele, Joel,
thanks for your anwsers.
What makes me wonder is the fact that Core 2.3 does not speaks of number!,
while it speaks of other pseudo-datatypes like series! any-string! any-block!
and so on. The only doc i have found is about the number? function but not in
Core.
---
Ciao
Romano

### [16/18] from: greggirwin:mindspring at: 18-May-2002 17:25

Hi Y'all,
I like "metatype", but you might also describe them as a "polytype".
--Gregg

### [17/18] from: carl:cybercraft at: 18-May-2002 16:55

On 18-May-02, Romano Paolo Tenca wrote:

> Hi,
>>> bug, to feedback?

<<quoted lines omitted: 3>>

> I don't find any documentation about this datatype in Core.
> Where is it? Or it does not exist?
It's a type of meta-datatype (there's no doubt a correct term:) that
can refer to a group of specific datatypes in the same way the
series! datatype refers to string, blocks and so on. Thus integer!
and decimal! datatypes are both also number! datatypes...

>> a: 1

== 1

>> type? a

== integer!

>> b: 1.1

== 1.1

>> type? b

== decimal!

>> decimal? a

== false

>> integer? b

== false

>> number? a

== true

>> number? b

== true
--
Carl Read

### [18/18] from: rotenca:telvia:it at: 19-May-2002 12:23

Hi,

> I like "metatype", but you might also describe them as a "polytype".

I think that datatype! is the metatype of every datatype!
And it is a class which contains itself (what could say B. Russell? :-)
I like RT name for series! any-block! and so on: pseudo-datatypes.
---
Ciao
Romano

Notes

- Quoted lines have been omitted from some messages.

View the message alone to see the lines that have been omitted