r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Core] Discuss core issues

Ladislav
17-Oct-2005
[2367]
what would did you expect to get?
Geomol
17-Oct-2005
[2368x2]
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
Ladislav
17-Oct-2005
[2370]
the definition is as follows: if r = a // b, then a - r // b should 
be zero
Sunanda
17-Oct-2005
[2371]
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
Ladislav
17-Oct-2005
[2372]
other formulation: if r = a // b, then a = some-integer * b + r
Geomol
17-Oct-2005
[2373x2]
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.
Gabriele
17-Oct-2005
[2375]
rebcode's rem does *not* support decimals.
Pekr
21-Oct-2005
[2376x2]
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
Rebolek
21-Oct-2005
[2378x3]
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}
Pekr
21-Oct-2005
[2381x2]
we are not converting here string of "119" values, but integer!
why?
Rebolek
21-Oct-2005
[2383x3]
that's what's written in documentation
I don't know the reason
And you cannot convert numbers bigger than 255
Pekr
21-Oct-2005
[2386]
I said no excuses or silly walkarounds. We are converting integer. 
Take your calculator and look how it converts it ;-)
Rebolek
21-Oct-2005
[2387x2]
to binary! [256]
== #{00}
This is not a workaround, that's in the documentation :)
Pekr
21-Oct-2005
[2389]
Kru - interesting example with integer in the block, but even more 
twisted imo :-)
Rebolek
21-Oct-2005
[2390x2]
http://rebol.com/docs/core23/rebolcore-16.html#section-2.1
To convert an integer into its binary value, pass it in a block
Pekr
21-Oct-2005
[2392x2]
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!
Rebolek
21-Oct-2005
[2394]
I don't understand what do you mean. If you've got integer less than 
256, you'll get same result
Ladislav
21-Oct-2005
[2395]
Pekr: why don't you check RAMBO and put it there (if not already 
present)?
Pekr
21-Oct-2005
[2396x3]
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?
Ladislav
21-Oct-2005
[2399]
take it as my advice
Pekr
21-Oct-2005
[2400]
ok, I just wanted to discuss it here first, to not flood Rambo by 
unnecessary input ....
Ladislav
21-Oct-2005
[2401]
It may be already there, though
Pekr
21-Oct-2005
[2402x2]
so, direct question - do you personally think current state is ok 
from "language purity" pov? :-)
#3820? :-)
Rebolek
21-Oct-2005
[2404]
I don't think it's ok, that to binary! treats integer! as string!, 
but it's in the docs...
Ladislav
21-Oct-2005
[2405]
I don't mind that much about "language purity" as it may look. It 
is inconvenient above all.
Pekr
21-Oct-2005
[2406]
Kru: thanks a lot, adding to-block to the code solves it ;-)
Rebolek
21-Oct-2005
[2407]
Pekr: solves it for one-byte integers and that's not so good :)
Pekr
21-Oct-2005
[2408]
:-)
Chris
21-Oct-2005
[2409x2]
How do you change the content type of outgoing emails?  I want to 
change the charset to UTF-8...
Meh, just create a custom header...
Brock
22-Oct-2005
[2411x2]
Be careful of using the BCC feature with emails.  I sent mails at 
one time were the BCC recipients were viewable in the header information 
from within Outlook.  A disgruntled recepient then SPAMMED all who 
were BCC'd using my companies email address as the from Address.... 
Corporate Security didn't like me very much.
... they eventually identified the spammer by the way  :-)
Graham
22-Oct-2005
[2413]
Don't you mean .. beware of using "Outlook" ?
Brock
22-Oct-2005
[2414]
I think if you BCC someone in an email it should not appear in the 
header of an email.  I don't know the spec, but it doesn't make sense 
if you want to hide who received an email that is displayed in the 
mail header.
Graham
22-Oct-2005
[2415]
We've discussed this before, and the RFC does allow the BCC header 
to appear.
Gabriele
22-Oct-2005
[2416]
SEND does not take the recipients from the header, so it has no reason 
to preprocess it. if you include a BCC header, it's because you want 
it to pass... otherwise, why do you include it?