World: r3wp

OUCH !!! to-integer error! 

>> to-integer "2147483648"
==  2147483648.0

@ Gregg: well it depends on what you are doing.  any serious date 
management will eventually break if its trying to calculate anything 
remotely old  :-(


having to work around something as basic like this is anoying.. (although 
like you say, possible)

I just ramboed my discovery, as I did not find any reference to it 
in searching to-integer

this is a very dangerous bug for any dialect writer... beware!

to-integer - what do you want to get?

an error! obviously.

It will only break if you try to do it this way. I haven't heard 
of many places where this is an issue, and it isn't hard to work 
around if you really need to.

if I try to use the decimal and converting it to integer it will 
return the error.

to-integer  2147483648.0
** Math Error: Math or number overflow
** Where: to-integer
** Near: to integer! :value

so we must not allow different type! representation of a value be 
considered different through the most basic type converting natives.

its an issue when you load data and make a dialect loader.  It just 
fucked up a week's work ... now I have to completely change the way 
I handle Integers...  had this broken early on, it would not even 
have slown me down.

:-(

I have to agree that this is not correct behavior.

the data is not of REBOL origin.  and has to be spitted out the same, 
cause it will break the external tool's understanding of the value...

What's the actual issue? I agree that it's not correct, but maybe 
there's an easier way to solve your current problem.

Or maybe we can all learn what not to do if we try something similar.

I can work around it (obviously).. but its just a core REBOL consistency 
issue.


its semantically unacceptable for a function called  to-INTEGER  
 to return anything else than an integer.  imagine if to-string decided 
to return words sometimes... its the same dangerous issue.

many places this can be a total fuck up
imagine this:

as-integer: func [value][
	any [
		attempt [to-integer value]
		0
	]
]


here we end up with a broken logic and impending doom...not of our 
fault.

so for now, we should all do this IMHO:

to-integer to-integer value

how could that help you?

it raises the error overflow error.

the way to-integer is implemented right now it should be called
to-number

to-integer is consistent as long as the value being given to it is 
within the bounds of 32-bit integer; outside that range, all bets 
are off. Your solution isn't going to help you, or catch other errors, 
e.g.:

>> to-integer to-integer "2147483646344.0"
== -1656
>> to-integer to-integer "2147483648343.0"
== 343

Only Carl can say why he designed it this way or, indeed, if it's 
intentional

my god this horror is worse than I thought !

thanks for catching the 32 bit rollover

I don't know if I'd call it "horror", though it's obviously not what 
some people will expect. It just means having to deal with those 
cases differently; use LOAD or TO DECIMAL! and check the range, etc.

hehe  load also returns a decimal... I guess THAT is where the to-integer 
reaction is comming from deep inside.

but LOAD's reaction would be open to subjective debate.  to-integer 
cannot return anything else than an integer... it just makes no sense. 
 the primary goal of the function is to have as a return value a 
specific type.

AH HA!  I have a fix !

Yeah, for that one, exact, string of ten characters, it's inconsistent.

make integer! reacts as it should.

sourcing 'TO-INTEGER I see that its not using make.

There you go then. :-) All the TO-* funcs are generated auotmatically 
I think.

I just discoverd something quite interesting...  is it generally 
know that the issue datatype is inherently hexadecimal?

Hmm, quick test; are you sure it does?

>> to-integer #a
== 10

Yes, that's known behavior; very handy.

I guess its just the 'TO function

MAKE does the same thing as TO here.

'MAKE already accepts strings and decimals for creating integers... 
maybe to-integer should be redefined as:

to-integer: func [value][make integer! :value]

oooh this is much worse than I tought ! 

make integer!  "2147483648"
== 2147483648.0

but this crashes:

make integer!  2147483648.0
** Math Error: Math or number overflow
** Near: make integer! 2147483648.0

so ignore my 'MAKE suggestion... IT is the culprit, obviously.

I agree, some of the TO- datatype functions need to be tightened 
up.

thanks for finding this, guys, I will do my best to convince Carl 
to correct it

Max: in RAMBO you wrote: "Some string values will crash to-integer, 
some decimal values will crash make integer some don't. " - I suppose 
you meant "cause an error" instead of "crash"?

the problem is, that integer arithmetic looks inconsistent

 - some integer operations "overflow to decimals":

    to integer! "2147483648" ; == 2147483648.0  
    1 / 3 ; == 0.333333333333333
    log-10 1 ; == 0.0

- some operations "wrap":

    to integer! "2147483646344.0" ; == -1656
    abs -2147483648 ; == -2147483648

- some operations cause errors:

    1 + 2147483647

The consistency requrement looks natural, but I don't think that 
it is easy to be consistent "regardless of the cost". Discussion 
welcome.

...adding to the list of integer operation behaviours.

- some operations crash:

    -2147483648 // -1

looking into that discussions, I wonder, if Rebol could be EVER considered 
to be used for the NASA purposes, as e.g. Python was used for some 
things.  Unless things are really predictable and without side effects, 
I am not sure it is.