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

World: r3wp

[Core] Discuss core issues

Oldes
24-Mar-2009
[13142x2]
maybe not such a big gain.. as I must use:
abin: func[block][append copy first block reduce next block]
which has result 0:00:02.078... but anyway.. every ms counts:)
mazbe it's strange that works:
>> make string! reduce ["a" "b"]
== "ab"
but not:
>> to binary! reduce [#{00} "a"]
** Script Error: Invalid argument: #{00}
** Near: to binary! reduce [#{00} "a"]
[unknown: 5]
24-Mar-2009
[13144]
abin: func[blk][head insert tail blk/1 blk/2]
Oldes
24-Mar-2009
[13145]
abin: func[

 "faster binary creation of a block where the first arg is already 
 binary!"
	block
][
	head insert tail copy first block: reduce block next block
]
;to be able have code like:
abin [to-binary #"^(00)" "a" "b"]
BrianH
24-Mar-2009
[13146x5]
I didn't decompile or disassemble, I just used the scientific method 
to evaluate behavior.
Same way I came up with the initial documentation about REBOL contexts 
and binding back in 2000.
Everything else is based on public discussions in various chat groups.
Oldes, a faster way (in R2) is this:
abin: func[

 "faster binary creation of a block where the first arg is already 
 binary!"
	block
][
	head insert copy #{} reduce block
]
Of course the doc string would need to be changed, because there 
would be no restriction on the type of the first expression.
Oldes
24-Mar-2009
[13151x2]
you are right.. thanks:)
how zou would call it?
BrianH
24-Mar-2009
[13153x2]
bjoin, since it is a binary version of ajoin.
bjoin [#"^(00)" "a" "b"]
Gregg
24-Mar-2009
[13155x2]
What do you see as the arguments to both have = and == in REBOL?


There are times when you care about strict equality, and times when 
you don't. And it's a balancing act between usability, strictness, 
and risk; similar to the choice of making a language case sensitive 
or not.
It's tricky, too, because sometimes you'll want to add something 
that you think will make things easier, but it really causes more 
problems in the grand scheme of things. TO-STRING versus FORM is 
a good example. I would like to see REBOL minimize the number of 
things that differ only in very subtle ways (which are often not 
explicitly documented).
Geomol
24-Mar-2009
[13157x4]
Let's look at this example. I have two words, iss and str, that represent 
some value, and they're some datatype. This is charasteristics of 
them:

>> series? iss
== true
>> series? str
== true
>> first iss
== #"a"
>> first str
== #"a"
>> length? iss
== 3
>> length? str
== 3
>> pick str 2
== #"b"
>> pick iss 2
== #"b"
>> str/3
== #"c"
>> iss/3
== #"c"

They seem quite alike. Are they equal?

>> str = iss
== false

Nope! Why not?

>> str
== "abc"
>> iss
== #abc


Again, I see little point in having both equal and strict-equal, 
when there's so little difference between them. If there were more 
differences between them, it would be good arguments to me for having 
both.
Issues and strings should be equal, I think, like integers and decimals 
can be equal, and numbers and chars can be equal.
Also I think, you can do exactly the same things with e.g. blocks 
and lists, but they're not equal:

>> [1 2 3] = make list! [1 2 3]
== false
(I totally agree, they shouldn't be strictly equal using ==.)
[unknown: 5]
24-Mar-2009
[13161x3]
But if we didn't have strict-equal then how would we know when a 
variable is a pointer?
;consider:

>> a: "123"
== "123"
>> b: a
== "123"
>> b
== "123"
>> a
== "123"
>> append a "4"
== "1234"
>> b
== "1234"
>> a == b
== true
Obviously, a and b are pointers to the same memory address that  
holds the string.
Geomol
24-Mar-2009
[13164]
You don't check, if they point to the same mem area with strict-equal, 
you use same? (or =?) for that:

>> a: "abc"
== "abc"
>> b: "abc"
== "abc"
>> a == b
== true
>> a =? b
== false


So it's not obvious, they point to same memory address, just because 
a == check returns true.
BrianH
24-Mar-2009
[13165]
There are bugs in strict-equal? in R2 as well.
Geomol
24-Mar-2009
[13166]
Can you give an example?
[unknown: 5]
24-Mar-2009
[13167]
Ah right John, thanks.
BrianH
24-Mar-2009
[13168x2]
Sorry, it is strict-not-equal? that has the bug:
>> strict-not-equal? 1 2
== false
STRICT-NOT-EQUAL? only checks types with integer! values. Use NOT 
STRICT-EQUAL? instead.
Geomol
24-Mar-2009
[13170x2]
ok
Something funny. (We had a long discussion about this in R3-alpha.):

>> 0.3 - 0.2 - 0.1 = 0.0
== false

This is also false in e.g. the C language.
BrianH
24-Mar-2009
[13172]
It's a floating point thing - 0.1 can't be represented exactly in 
IEE754 floats.
Geomol
24-Mar-2009
[13173]
yes
Oldes
24-Mar-2009
[13174x2]
>> $3.0 - $2.0 - $1.0
== $0
use money! datatype if you need precision
BrianH
24-Mar-2009
[13176x2]
Those aren't IEEE754 :)
Or you could use fixnums: integer! and a scale.
Geomol
24-Mar-2009
[13178x4]
In REBOL:
>> 0.1 + 0.1 + 0.1 = 0.3
== true


In C, this is not true. So REBOL tries to cope with this problem, 
but don't do it 100%.
In e.g. Python, my last test is also not true.
But Python is also a bit strange, it seems. From Python prompt:

>>> 0.1 + 0.1
0.20000000000000001
>>> 0.1 + 0.1 == 0.2
True
>>> 0.1 + 0.1 + 0.1
0.30000000000000004
>>> 0.1 + 0.1 + 0.1 == 0.3
False
Ah, maybe it's not so strange. C does the same.
Graham
24-Mar-2009
[13182x2]
anyone remember where the parse demos showed a calculator dialect 
?
just need simple arithmetic
Geomol
24-Mar-2009
[13184]
This? http://www.rebol.com/docs/core23/rebolcore-15.html#section-6
Graham
24-Mar-2009
[13185x2]
yes .. thanks
saves me a few mins writing my own !
Pekr
26-Mar-2009
[13187]
I was trying to help new guy on ML, and just would like to ask - 
why is there a difference in evaluation when printing a block, and 
printing first block?

>> colors: [red green blue]
== [red green blue]
>> print colors
255.0.0 0.255.0 0.0.255
>> print first colors
red

so 'first does not reduce the value, while print itself does?
Steeve
26-Mar-2009
[13188]
it doesn't come from print behavior
but, it's how reduce works
reduce first [red]
PeterWood
26-Mar-2009
[13189]
>> a: 1

== 1

>> type? a

== integer!

>> type? 'a
== word!

>> b: [a
]
== [a
]
>> type? first b

== word!

>> print a

1

>> print first b

a

>> print 'a

a
Sunanda
26-Mar-2009
[13190]
Help says print does an evaluate (presumably a reduce) if the value 
to print is a block....So it is documented behavior:
  http://www.rebol.com/docs/words/wprint.html
Pekr
26-Mar-2009
[13191]
ok, thanks ....