World: r3wp

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.

I guess, that you are able to articulate your preferences too, so 
go ahead and speak. What are your preferred behaviours?

well, predicable behaviors are preferred :-) Could there be performance 
hits if behavior is to be 100% consistent?

Of course, the "cheapest" is the wrapping behaviour.

in that case the integer division may be defined as in C

the question is, would there not also be a performance hit if you 
need to check for wrapping inside your rebol code?

Ladislav - dunno in that particular case. But I am just sensible 
enough to what others say. I reacted to the fact, that Rebol does 
have side effects. I don't know if it was Erlang or other functional 
language, where they claimed programmers like it, because of no side 
effects = predictable. But maybe it is just the case of documentation, 
but really - many novices just try in console by trial and error 
....

performance hit if you need to check for wrapping inside your ... 
code
 - that is exactly what every C programmer needs to do

ladislav: yep, but isn't that faster to do in C than moving that 
check out into rebol code?

...and it is the highest performance solution, because you usually 
don't need to "check..."