World: r3wp

Henrik: yes, it is!

Back to ROUND for a moment. It seems so long ago...


I think the goal was to have things make sense to normal people, 
while still allowing Ladislav and John to have their way. :-) Most 
programmers just want results that make sense to them as humans.

Does Chat system work? Mine shows off-line ...

Most programmers just want results that make sense to them as humans.

I can agree with that. It would be a benefit, if it still make sense, 
when you think a little deeper about it.

I still find the equal operator with its trying to be clever about 
rounding errors in decimals a strange thing. Try this example:

for i 4.0 6.0 0.1 [print i if i = 6.0 [print [i "= 6.0"]]]

The last line output is:

5.99999999999999 = 6.0


So those two numbers are the same for the equal operator. Let's check 
it:

>> 5.99999999999999 = 6.0
== false

Now see what happens, if I let the loop run a little longer:

for i 4.0 7.0 0.1 [print i if i = 7.0 [print [i "= 7.0"]]]


Now the equal test within the loop doesn't become true. The last 
number output is 6.99999999999999, so this number doesn't equals 
7.0, like 5.99999999999999 equals 6.0. I know, we don't see all possible 
decimals, but that's not my point. My point is, that if equal can't 
cope with rounding errors always, then it shouldn't try to do it 
at all. (My opinion.) The current behaviour isn't a good thing for 
the language.

A side note: FOR doesn't allow money! as its start argument in R3. 
It does in R2.

I could of course use == instead of =, and then none of the above 
tests would be true. The reason I find the behaviour strange might 
be the way, PRINT output the numbers.

Geomol: you did not read the decimal! documentation. The fact, that 
(print i) prints 5.99999999999999 does not mean you know what I is.

I probably read it and forgot. I'll read it again. :-)

after a slight modification I get:


for i 4.0 6.0 0.1 [print i if i = 6.0 [print [mold/all i "= 6.0"]]]
5.9999999999999929 = 6.0

doesn't it look different now?

I'm questioning the "nearness" in equal. Another example:

>> 0.1 + 0.1 + 0.1 = 0.3
== true
>> 0.1 + 0.1 + 0.1 - 0.3 = 0.0
== false


STRICT-EQUAL returns false for both of these. Is the "nearness" a 
good thing to have from a language design point of view?

nearness

 is not equality, it is just symmetric and reflexive (no transitivity)

I just came across this yet again, when I was preparing scientific 
data using R2. I can deal with it fairly easily in R2 by using money! 
datatype with the FOR function.

money! datatype in R2? What is the advantage, when you ignore the 
ability to express the denomination?

I got all the decimals after a while with this:

for a 4.0 5.9 0.1 [print a]

so I changed it to:

for ma $4.0 $5.9 0.1 [a: load next form ma print a]

I'm not sure, why it isn't allowed to write this in R2:

to decimal! $4.0

Maybe just missed. It's fixed in R3.

I'm actually messing around with REBOL (actually R2) and been away 
from it so long I forgot a lot of stuff.  Anyway, was wondering how 
R3 is progressing.  I was just using parse and thought about rejoin. 
 For example, if we can parse something such as:

blk: parse "this, simple, csv, string" "," 


wouldn't it be cool to just come back along and rebuild it with something 
such as:

rejoin/csv blk ","

or have any deliminater you specify.

Geomol: "FOR doesn't allow money! as its start argument in R3. It 
does in R2." - Write it up as a wish in CureCode please :)

Paul, that function has been proposed as DELIMIT - not as REJOIN 
because that function needs to be low-level - but hasn't been added 
yet since there is no consensus about the feature set. No consensus 
means it goes in the library rather than the mezzanines. If you can 
make a version that is so awesome that everyone will agree with your 
feature set, we'll add it :)

I don't agree with such fundamental functionality of R2 to go into 
some optional library. Better to have some standard, than not. The 
same goes for easy read/lines equivalence. Dunno how current read/as 
turns out, if it will end-up as separate read-text or so, but we 
need easy way of having R2 analogy here. Those working with CSV data 
on a daily basis will greatly miss such features ....

hmm, there is a 'delimit function ... it seems to be renamed to 'split 
....

'dehex does not work as I'd anticpated:

	dehex "em%E2%80%94dash" ; s/b "em--dash" (where -- is em-dash)

More like:

	dehex: use [hx ch][
		hx: charset [#"0" - #"9" #"a" - #"f" #"A" - #"F"]
		func [text][
			parse/all text: to-binary text [
				any [
					to #"%" remove [#"%" copy ch 2 hx] ; change <> remove insert
					(ch: debase/base ch 16) insert ch
				] to end
			]
			to-string text
		]
	]

I need a map! with 60'000'000 entries. But in R3, I cannot do that:

>> make map! 500'000
** Script error: maximum limit reached: 500000

Why the limit is so small?

CC it, please ...

I think that some things are settable, via enchant or so function, 
e.g. stack size, but not sure ...

Ok, I will CC it.

Thanks Brian, I'll try to look up the discussions regarding DELMIT 
tonight if I have some time.

This:

parse "this, simple, csv, string" ","


I believe was meant to be removed, because it's too obscure. I think 
the intended function for this is SPLIT.

I didn't know that.

I don't know if it has been removed yet or if that will be a 3.1 
feature.

Back to my question (a long time ago :-) May I assume that the behaviour 
I wrote about in my question is a bug? A probe works, but anyhow 
the window won't move anymore.

what happens if you change show-later to show?

seems host code work is now continuing. Something with a MinGW C 
target.

how can I remove an entry from a map! in R3? BTW, I use string! (not 
word!) as index here, so I cannot just say:  my-map/my-word: none

Geomol; I have to go with Gregg on this one.  I'd much rather have 
to deal with grenade close on output than NOT seeing your for example 
fire true on the if i = 6.0.  Is that attitude good for REBOL or 
rocket science?  Perhaps not.  Small business owner/hobbyist?  Yep. 
 In my humble, liable to blow up rockets, opinion.

oops, didn't notice how far back the scroll bar was...  "this one" 
being the post re decimal! with base 2 conversion precision.   this 
line in particular.    for i 4.0 6.0 0.1 [print i if i = 6.0 [print 
[i "= 6.0"]]]f

Jerry: try my-map/( my-string ): none

thanks Izkata

btiffin, did you notice, that the i = 7.0 test in my other example 
fails? Try:

for i 4.0 7.0 0.1 [print i if i = 7.0 [print [i "= 7.0"]]]


The problem is, that you can make examples, where the "nearness" 
works. So the small business owner/hobbyist will come to think, the 
language actually handle those base-2 precision problems, but it 
doesn't. The only way, as I see it, to really handle this problem 
is by using true decimal arithmetic (e.g. some kind of binary-coded 
decimal as in money!). I believe, the current behaviour will only 
lead to more confusion.

How will you explain this behaviour to someone learning how to program?

>> 0.1 + 0.1 + 0.1 = 0.3
== true
>> 0.1 + 0.1 + 0.1 > 0.3
== true


I can explain this next behaviour, even it seems illogical at first:

>> 0.1 + 0.1 + 0.1 == 0.3
== false
>> 0.1 + 0.1 + 0.1 > 0.3
== true

even *if* it seems ...

Do or do not... there is no try.

REBOL try to solve the base-2 precision problem.

Henrik: the behaviour is the same when I use show instead of show-later.

For the record; I am using: Windows XP Pro SP3
Rebol3 2.100.94.3.1
GUI 0.2.1

arie, ok. I don't have a solution, but this needs to be looked into 
once GUI work continues. While the Core of R3 has moved forward a 
lot, GUI has not moved in the past year. it could be that a feature 
is broken in the GUI now because of this.

>> 0.1 + 0.1 + 0.1 > 0.3
 - this differs from the behaviour in R2, maybe an error?

If you change it, then you'll have problem with < > and ==, because 
you can have situations, where all those 3 return false.