World: r3wp

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..."

especially when we take into account the fact, that integers will 
be 64-bit

so, performance-wisely speaking the fastest solution *is* wrapping, 
no doubt

OTOH, the safest solution is to either yield a meaningful value when 
appropriate, or cause an error

moreover, "yielding a meaningful value" is faster than "causing an 
error"

but a meaningfull value is subjective.  what is meaningfull in one 
context can be your worst ennemy in another.

basically, the interpretet at some points "chooses" what it thinks 
is the best behaviour when it finds something screwy... but really... 
the fundamental event is that something screwy occured.  so for correctness 
and intuitive consistency, screwy things should error, not try to 
recover.

if we know the INPUT is subject to screwy behaviour, our code will 
obviously take that into account.

if we don't know that input data is invalid within REBOL (like an 
integer specification which does not fit inside an integer) then 
I don't see why REBOL should try to cope.  its plain logic to me. 
 this decimal issue can drag around a LONG time before you realise 
what is going on and by that time... its a hard thing to fix.

others will say that crashes are evil and should be circumvented 
whenever... well, this is sloppy IMHO, and where does it end?

do we then recover division by 0 errors and quietly return 0.0  ? 
 why not, then also convert unset words internally to lit-words and 
return that ... hey we'd have no more errors... and also no bearing 
of what is going on, and would have to check each and every operation 
to be sure its doing what its supposed to...

Max, this isn't necessarily "something screwy". It's entirely possible 
that you know how REBOL works, and you expect it to behave that way, 
so you're not surprised. REBOL *can't* know anything about how it's 
being used, so all it can do is behave a certain way, and the onus 
is on us to deal with it. The important thing is knowing how it works, 
so we know what to expect. 


REBOL is pragmatic. How many times have you seen this particular 
discussion, or issue, debated since REBOL was released? Obviously, 
not too many people have been hurt by it enough to make much noise. 
That said, I'm all for more consistency. WRT divide-by-zero, there 
are some langs that have a NAN (not a number) vals to represent infinity 
and things like that; again, it's just choices.

but do you agree that make integer! returning a decimal is a bug, 
whatever the reason?

I will shut up now!!  (hehe, seems I'm getting beaten by a few sticks 
this week.  Though I like the discussion, I feel I am going to be 
tagged as a troll, by those who might not like the noise a few threads 
are generating compared to the whole .   ;-)

no problem with me, Max. I think, that to integer! should yield an 
integer or cause an error too. What I wanted to discuss in addition 
to that is the general behaviour of other operators/expressions.

meaning full values, imply choosing out of several options.

I am just a bit concerned that some functions should be too pure 
to return alternate values when input is not "perfect".

this is like to-integer and as-integer.  the later could ALWAYS return 
an error, even when the input is obviously wrong and return 0.  but 
to-integer should either return an integer, raise an error, or maybe 
none instead... which is gradually being accepted as a softer error 
value... llike the switch to first/second... etc.