World: r3wp

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

the equality for example...  testing it out in code would surely 
help, but deciding for sure, could be left at the devcon...

this might also raise REBOL's case about it not being a totally closed 
source effort.

My big issue with stuff like this is how people will use these kinds 
of examples to show how "stupid" REBOL is, and make them reasons 
not to use it, and to drive others from using it. e.g. "if it can't 
even return a positive value from ABS...". Doc'ing the behavior, 
even pointing out that it's more akin to how C might work, will go 
a long way toward that, but maybe not all the way.

I don't understand - there is no ideal way. The best possible way 
is to use one general principle. Such principle may be to let the 
arithmetic work like the C language arithmetic does (use wrapping 
for integer arithmetic). Another principle is to use the "Python 
principle" - use a "more general datatype", if the original datatype 
is unable to represent the result. And the third alternative is to 
cause an error if the original datatype cannot represent the result. 
I think, that the slowest is the "error causing principle". The most 
unsafe is the "wrapping principle". The "more general datatype" looks 
like the most comfortable.

I agree, we must not think in terms of how C does it, this would 
be a step backwards.  REBOL is more natural than that...

BUT as I said earlier, this must not contradict the first principle 
of an expression's meaning.  if abs means "return a positive VALUE" 
then that's what it should first and foremost.

note I use the word VALUE, not int, not decimal... this lets the 
whole be consistent and precise.

I looked up the ABS description. It is quite funny: "Returns the 
absolute value."

I might have used number instead, in REBOL's pov this is even more 
precise as you can then expect to use number? on it.