Mailing List Archive: 49091 messages

# 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
== [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

### [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
>> 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}
== decimal!
>> append big "1"
== {99999999999999999999999999999999999999999999999999999999999999991}
** 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