World: r3wp

pekr, it calculates date, not time difference that way. you need 
to:

start: now/time/precise wait 5 print (now/time/precise - start)

there is an interesting "bug" that way: you'll be shifted back 24 
hours if the difference is calculated across midnight.

it would be nice if it calculated the complete time and date difference

Use 'difference

ah... thanks

(but IMHO not particularly obvious)

You pick up these things by talking to people ... not reading obscure 
manuals :)

and then you write them down in wikibooks :-)

Geomol, let me see what I can do myself first. I like to know what 
is happening in my scripts.

Isn't this a bit strange?
>> 3 // 3
== 0
>> 3 // 2
== 1
>> 3 // 2.6
== 0.4
>> 3 // 3.4
== 3.0

Very!

yes, it is, try MOD and MODULO functions, if you need a different 
behaviour

Same behaviour:

>> mod 3 3
== 0
>> mod 3 2
== 1
>> mod 3 2.6
== 0.4
>> mod 3 3.4
== 3.0

right, in these specific cases, otherwise the behaviour may differ.

what would did you expect to get?

I guess, I was just surprised, that it worked with decimals. Then 
it can maybe be argues, if 3 // 3.4 should return an integer or a 
decimal.

argues = argued

the definition is as follows: if r = a // b, then a - r // b should 
be zero

Been thinking about it too....It is surprsing, but does make sense.
It's returning the remainder:
3 // 2.6 --> remainder is 0.4
3 // 3.4 --> remainder is 3

other formulation: if r = a // b, then a = some-integer * b + r

In rebcode, I guess the upcode rem is remainder. It works a little 
different there:
set a 3
rem a 3

now a is 0. If doing this:
set a 3.0
rem a 3

then a is 3.0.

I guess, it has to do with the internal floating-point representation 
of numbers.

rebcode's rem does *not* support decimals.

will it be possible to do easy types conversion with rebcode? regard 
me being stupid, but I regard following being  bug or at least inconsistence:

type? #{77}
== binary!    ; so no excuse it is a string later!

to-integer #{77}
== 119

to-binary to-integer #{77}
== #{313139}

If pure functions which serve datatype conversion work one way, it 
is imo inconsistent that it does not work the same way in the reverse 
mode ....a

If you want to convert a number to binary, number must be enclosed 
in brackets, to binary! [119] , not to binary! 119

so your example should look like:

to binary! reduce [to integer! #{77}]
== #{77}

we are not converting here string of "119" values, but integer!

why?

that's what's written in documentation

I don't know the reason

And you cannot convert numbers bigger than 255

I said no excuses or silly walkarounds. We are converting integer. 
Take your calculator and look how it converts it ;-)

to binary! [256]
== #{00}

This is not a workaround, that's in the documentation :)

Kru - interesting example with integer in the block, but even more 
twisted imo :-)

http://rebol.com/docs/core23/rebolcore-16.html#section-2.1

To convert an integer into its binary value, pass it in a block

so we take binary as an argument, convert it to integer. Then we 
take exactly the same integer, and convert it back to binary and 
we get different result? :-))

It is like doing 3 * 7 = 21 on calculator, then pressing /, 7, enter, 
and not getting back to 3!

I don't understand what do you mean. If you've got integer less than 
256, you'll get same result

Pekr: why don't you check RAMBO and put it there (if not already 
present)?

I am far from being expert in assembler etc., but imo the proof of 
misconception in the first place is, that it has to be explicitly 
stated in the docs. Imo it is because naturally one would expect 
different result ... :-)

Ladislav: well, because maybe it is intended? We have it this way 
for ages, lots of code relies on it!

and because I know my knowledges are limited here, I ask gurus for 
some sane explanation of concept behind such logic, maybe there is 
one?

take it as my advice

ok, I just wanted to discuss it here first, to not flood Rambo by 
unnecessary input ....

It may be already there, though

so, direct question - do you personally think current state is ok 
from "language purity" pov? :-)