World: r3wp

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.

I understand your arguments. But let's take a look at the following 
example:

    abs -2147483648


The -2147483648 is a result in the C language (using wrapping). Python 
uses a "larger" datatype and raising an error is yet another option. 
All three variants are "reasonable" in a sense, but we may pick only 
one of them.

I must say that I "don't like" -2147483648, because it violates the 
fundamental mathematical principle, that ABS cannot yield a negative 
value.

If we accept 1 / 3 = 0.333333333333333 (which is mathematically sound, 
because all integers *are* real numbers too), then we should apply 
that to the ABS case as well and say, that abs -2147483648 = 2147483648.0

Python uses this "philosophy", except for the fact, that it uses 
bignums instead of decimals

indeed within mathematical operations, there is acceptible leniency 
in a "pragmatic" language like REBOL, and I agree completely.

but as you say about abs, there, the return value is the result of 
a mathematical expression.  so it is consistent throughout REBOL 
maths, that some equations return decimals, when values go out of 
range of integers.... just like power 2 32

actually, power 2 0 yields a decimal!, even though it might return 
integer! (but this is more efficient when comparing code size)

people who code in C are programmers.  there is no doubt about it. 
 and indeed, if they choose C, there are reasons, and they expect 
a harsh and unforgiving environment.

hehe

yes, Max, REBOL is and should remain more friendly, than C

we must just not forget the intent of the functions first and foremost. 
 if harsh and possibly faster algorythms are needed, I am all for 
it, but these should get specific names... pick and poke, ocome to 
mind as alternatives fewer of use use.

so for maths, I'd rather have a function which does not go haywire 
like the wrapping which can occur, which you describe, even if its 
slower... simply because its completely out of the reach of the reason 
of why I use REBOL to have to understand this.

hehe, I might seem to contradict myself wrt the whole to-integer 
thing, but the fundamental function of to-integer and make integere 
are getting an integer out of some other possibly compatible values.

I do agree with you completely.

its a bit like the law, there is the letter of the law, and the meaning 
of the law.

procecution and defence will try to bend the judge or jury towards 
one or the other... using the same text.

:-)

we are at a crossroad (R3) where we can pick the best direction, 
that is why it is time to ask these questions

so we must not get lost in proceeedings when the intent is so clear, 
even if precedents would tend to make us think we should continue.

yes.

do you agree about a panel at devcon 2007 for some of the more pointy 
issues?

i guess, that it may be too late for these issues

I would hope R3 beta/alpha would last a while for such issues to 
be compared empirically.

well, but some code needs to be written and we cannot prepare all 
variants