World: r3wp
[Core] Discuss core issues
older newer | first last |
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 .... |
older newer | first last |