World: r3wp

>> $65 / $1
== 65.0

Easy answer: Use divide :)

Great way to exploit a terrible bug for the benefit of all! :)

This is math ... not a bug

yes exactly.

The type conversion is a bug. The math is the benefit.

if you divided by a decimal, then it should return a money type. 
  which it does.

no its very consistent.... how many dollars in 65 dollars?   one... 
  not one dollar.

6 dollars divided by 2 is  3 dollars... not 3

What are you saying max?

You can also use First and Second

(in R2)

Second .. true

much better ..

the use of Mold is something I would discourage to use for this purpose

the denominator is handling the return type, which is consistent 
with how you'd express the division in real life.

No string conversion, no floating point division(?); we have a winner!

I still like the "Use R3" method, but that is not always practical 
:(

How about .. use R2 1.7.8 ?

Fixing conversions is not on the roadmap for 2.7.8.

ok, 2.7.9 then

thanks for the quick answers! you guys are great


I'm building a function that computes the challenging code for  web 
socket  protocol, 

It uses unsigned 32 bit integer, so I use money instead of integer, 
to avoid overflow.

there is no advantage to use money in R2 against the decimals, they 
are pretty much the same in R2

(by the way, which is the best method to convert 32 bit integer to 
4 byte string big endian ?)

thanks ladislav, I will use decimal.

Does it have to be a string, or will binary do?

I think binary would be ok too...

this is my quick & dirty func:

int-2-char: func [n [decimal!] /local ret] [
			ret: copy "" 
			repeat k [16777216 65536 256 1] [
				append ret to char! (n / k)
				n: modulo n k
			]
			ret
		]

That function would be sped up by unrolling the loop.

one way is to use my http://www.fm.tul.cz/~ladislav/rebol/peekpoke.r

(you can find other conversions in there)

and, btw, unsigned and signed integers differ only in interpretation, 
using the same representation

thanks ladislav, but I prefer a small routine ad hoc instead of a 
generic and more complex one.
I have to be small with this code

here we go:

int-2-char: func [n [decimal!] /local ret] [
	ret: copy "" 
	append ret to char! (n / 16777216) n: modulo n 16777216
	append ret to char! (n / 65536) n: modulo n 65536
	append ret to char! (n / 256) n: modulo n 256
	append ret to char! n			
	
	ret
]

mmm there's something strange, with the first version of the function 
the protocol works, 

with the second version every 10-20 times the protocol fails to estabilish

<poker face>

they return the same values, maybe some side-effects ?

Some standard R2 optimizations, but compare results to be sure, I 
might have messed it up:

int-2-char: func [n [integer! decimal!]] [
	n: to integer! n
	head insert insert insert insert make string! 4
		to char! n / 16777216
		to char! (n // 16777216) / 65536 
		to char! (n // 65536) / 256
		to char! n // 256
]

You messed up by using decimal. Integer division has different properties 
than decimal.

Crap, I messed it up too, / returns decimal in R2.

I should use SHIFT instead of // here.

ah ok  good to know !

Switching to bitwise operations:

int-2-char: func [n [integer! decimal!]] [
	n: to integer! n
	head insert insert insert insert make string! 4
		to char! shift/logical n 24
		to char! 255 and shift/logical n 16
		to char! 255 and shift/logical n 8
		to char! 255 and n

]

Note that this is R2 code, and it depends on R2's 32bit integers 
and SHIFT behavior.

umh... but this fails if I pass a number > 2^31

Try the last version then, tell me if it works.

Perhaps removing the n: to integer! n from the math version, instead 
of the bitwise version.

your function works well, but I'm getting random protocol fails