| # | User | Message | Date |
| 15979 | Paul | For example, in set of data you might find how many occurences of 3 '0 bit squences you have in the data. Once you now the number of the occurences then for random data the 4 '0 bit sequences should be about half that and so on. | Fri 16:15 |
| 15978 | Paul | Additionally, the distribution of bits are tight. Meaning that the distribution of 10, 01, 00, 10 bit sequences for example are very close to the same quantity. | Fri 16:12 |
| 15977 | Paul | I found some interesting observations in working with Random data recently. I was mostly working with the RandomMilliondigit.bin file data that is used to test compression algorithms. It exhibits a characteristic in that repetitious data is ascends in almost a 1-2 ratio. | Fri 16:11 |
| 15976 | Ladislav | yes. If the difference is detectable by a test, then we should change the implementation | Fri 14:48 |
| 15975 | Geomol | The first random function was: tt62: to integer! 2 ** 62 r: func [x [decimal!]] [(random tt62) - 1 / tt62 * x] and if (random tt62) - 1 result in tt62 - 257, the space between numbers are smaller than if (random tt62) - 1 result in 1. Hope I make sense. | Fri 12:22 |
| 15974 | Geomol | Yes, it can. If
random tt62
result in tt62 - 257 >> 1.0 - (tt62 - 257 / tt62) == 1.11022302462516e-16 So the problem is there, just not as big as I first thought. | Fri 12:19 |
| 15973 | Geomol | Hm, this is not trivial! :-) | Fri 12:08 |
| 15972 | Geomol | Oh! Yes, I didn't have that in mind. So the smallest result larger than zero from RANDOM 1 is: >> tt62: to integer! 2 ** 62 >> 1 / tt62 == 2.16840434497101e-19 It's still smaller than 1.11022302462516e-16 Can RANDOM 1.0 produce a result equal to 1.0 - 1.11022302462516e-16 ? | Fri 12:04 |
| 15971 | Ladislav | (by the implementation) | Fri 11:14 |
| 15970 | Ladislav | but, you did not take into account, that the spacing of 4.94065645841247e-324 is not used | Fri 11:13 |
| 15969 | Geomol | I added another comment to ticket #1027 in curecode. | Fri 8:46 |
| 15968 | Geomol | It should be clear, that it's a bad idea to move the outcome giving 1.0 to 0.0, as is done now with the current RANDOM function in R3. | Fri 8:29 |
| 15967 | Geomol | It's easier to illustrate it with an image: http://www.fys.ku.dk/~niclasen/rebol/random-dist.png
The x-axis is the possible IEEE 754 numbers going from 0.0 to 1.0. The y-axis is how many 'hits' ever possible number gets, when doing RANDOM 1.0. Every gray box holds the same amount of possible number, namely 2 ** 52. I use the color to illustrate the density of numbers. So the numbers lie closer together at 0.0 than at 1.0. The destribution is of course flat linear, if the x-axis was steps of e.g. 0.001 or something. There is the same amount of hits between 0.001 and 0.002 as between 0.998 and 0.999. It's just, that there are many more possible numbers around 0.001 than around 0.999 (because of how the standard IEEE 754 works). | Fri 8:28 |
| 15966 | Geomol | The space between possible decimals around 1.0 is: >> (to-decimal #{3ff0 0000 0000 0000}) - to-decimal #{3fef ffff ffff ffff} == 1.11022302462516e-16 The space between possible decimals around 0.0 is: >> to-decimal #{0000 0000 0000 0001} == 4.94065645841247e-324 That's a huge difference. So it'll give a strange picture, if converting the max output of random (1.0 in this case) to 0.0. | Fri 7:35 |
| 15965 | Geomol | "for random 1.0 you cannot find any irregularities, there aren't any" I think, there are. Decimals with a certain exponent are equal spaced, but there are many different exponents involved going from 0.0 to 1.0. The first normalized decimal is: >> to-decimal #{0010 0000 0000 0000} == 2.2250738585072e-308 The number with the next exponent is: >> to-decimal #{0020 0000 0000 0000} == 4.4501477170144e-308 I can take the difference: >> (to-decimal #{0020 0000 0000 0000}) - to-decimal #{0010 0000 0000 0000} == 2.2250738585072e-308 and see the difference double with every new exponent: >> (to-decimal #{0030 0000 0000 0000}) - to-decimal #{0020 0000 0000 0000} == 4.4501477170144e-308 >> (to-decimal #{0040 0000 0000 0000}) - to-decimal #{0030 0000 0000 0000} == 8.90029543402881e-308 >> (to-decimal #{0050 0000 0000 0000}) - to-decimal #{0040 0000 0000 0000} == 1.78005908680576e-307 So doing random 1.0 many times with the current random function will favorize 0.0 a great deal. The consequence is, 0.0 will come out many more times than the first possible numbers just above 0.0, and the mean value will be a lot lower than 0.5. | Fri 7:26 |
| 15964 | Ladislav | bye | Thu 16:48 |
| 15963 | Geomol | Nice talk. Time for me to move to other things... | Thu 16:48 |
| 15962 | Geomol | yeah, r-uni is better, I think. | Thu 16:47 |
| 15961 | Ladislav | (since in that case no additional rounding occurs) | Thu 16:47 |
| 15960 | Ladislav | r-uni surely differs from r when X is equal to 1.0 | Thu 16:46 |
| 15959 | Ladislav | sorry, ignore my post | Thu 16:45 |
| 15958 | Ladislav | r-uni is integer, guaranteeing uniformity by using rejection | Thu 16:44 |
| 15957 | Geomol | Is r-uni better than the version, you gave earlier? tt62: to integer! 2 ** 62 r: func [x [decimal!]] [(random tt62) - 1 / tt62 * x] | Thu 16:43 |
| 15956 | Ladislav | another variant would be to generate the uniform deviates in the definite interval not allowing multiplication to "mess things" | Thu 16:37 |
| 15955 | Geomol | I like it better than the version, where max is changed to 0.0 | Thu 16:34 |
| 15954 | Geomol | yes | Thu 16:34 |
| 15953 | Ladislav | that is caused by the multiplication rounding | Thu 16:34 |
| 15952 | Geomol | It give same result as your first RANDOM: d: to-decimal to-binary 1023 blk: [] insert/dup blk 0 1024 random/seed now loop 1000000 [i: to-integer to-binary r-uni d blk/(i + 1): blk/(i + 1) + 1] >> print [blk/1 blk/512 blk/1024] 462 1036 481 | Thu 16:33 |
| 15951 | Ladislav | ...multiplication may still trigger rounding, though | Thu 16:30 |
| 15950 | Ladislav | yes | Thu 16:29 |
| 15949 | Geomol | If all possible values of d is equal possible, and d now can have values from 0 to two**53, then d / two**53 will return values from 0.0 to 1.0 both inclusive, and d / two**53 * x will return values from 0.0 to x both inclusive. Right? | Thu 16:28 |
| 15948 | Ladislav | as follows: rnd: func [ {random range with rejection, not using last bits} value [integer!] /local r s ] [ s: two-to-62 - (two-to-62 // value) until [ r: random two-to-62 r <= s ] s: s / value r - (r // s) / s + 1 ] | Thu 16:27 |
| 15947 | Ladislav | hmm, to make sure, I should use rejection | Thu 16:24 |
| 15946 | Geomol | After you do: d: d // two**53+1 Are we sure, the new d is even distributed? That every value, d can now take, is equal possible? | Thu 16:23 |
| 15945 | Geomol | Yes, I understand. | Thu 16:22 |
| 15944 | Ladislav | (I mean, it exceeds the precision limit) | Thu 16:21 |
| 15943 | Geomol | I see. | Thu 16:21 |
| 15942 | Ladislav | no, it is the precision limit of IEEE754 | Thu 16:21 |
| 15941 | Geomol | But!? :-) >> to integer! 2 ** 62 - 1 == 4611686018427387904 >> to integer! 2 ** 62 == 4611686018427387904 Isn't that a bug? | Thu 16:20 |
| 15940 | Geomol | yeah | Thu 16:20 |
| 15939 | Geomol | no wait, it's 2 ** 63, that should give overflow. | Thu 16:20 |
| 15938 | Ladislav | no, R3 uses 64-bit integers | Thu 16:19 |
| 15937 | Geomol | This should give an math overflow, I think: >> to integer! 2 ** 62 == 4611686018427387904 Like this does in R2: >> to integer! 2 ** 31 ** Math Error: Math or number overflow | Thu 16:19 |
| 15936 | Ladislav | "Why is that?" - rounding | Thu 16:18 |
| 15935 | Geomol | (I wanted to check , if d // two**53+1 gave an even distribution, but there seem to be something wrong with calculations of large numbers.) | Thu 16:16 |
| 15934 | Geomol | >> two**62 / two**53+1
== 512.0 So two**53+1 * 512 should equal two**62, but it doesn't: >> two**62 == 4611686018427387904 >> two**53+1 * 512 == 4611686018427388416 Why is that? | Thu 16:13 |
| 15933 | Gregg | In any case, this chat should be the basis for the docs that go with it. People aren't aware of how much thought goes into these things. | Thu 15:40 |
| 15932 | Ladislav | hmm, seems, that the former may still produce X when rounding? | Thu 15:33 |
| 15931 | Geomol | I'll just grab some food, then I look at your r-uni. | Thu 15:29 |
| 15930 | Ladislav | anyway, this is always a problem, when we try to generate numbers in an "exotic" interval, not in the usual [0.0 .. 1.0] | Thu 15:01 |
| 15929 | Ladislav | LOL, that is what we are just discussing | Thu 14:54 |
| 15928 | BrianH | When you two are done, could you look at CureCode ticket #1027 and R3's alpha 66 behavior and see if it is correct? I can't judge. | Thu 14:52 |
| 15927 | Ladislav | a modification: two**62: to integer! 2 ** 62 two**53: to integer! 2 ** 53 two**53+1: two**53 + 1 r-uni: func [x [decimal!] /local d] [ d: random two**62 ; transform to 0..2**53 d: d // two**53+1 ; transform to 0.0 .. x (0.0 inclusive, x inclusive) d / two**53 * x ] | Thu 14:51 |
| 15926 | Ladislav | how about this, do you think, that there is a problem with it too? two**62: to integer! 2 ** 62 two**9: to integer! 2 ** 9 two**53: to integer! 2 ** 53 r-uni: func [x [decimal!] /local d] [ d: random two**62 ; transform to 0..2**53-1 d: d // two**53 ; transform to 0.0 .. x (0.0 inclusive, x exclusive) d / two**53 * x ] | Thu 14:49 |
| 15925 | Geomol | This mean, there is as many different possible decimals between 0.0 and 1.5 as between 1.5 and the highest possible 64-bit decimal, when talking floating points in a computer using the 64-bit IEEE 754 standard. | Thu 14:09 |
| 15924 | Geomol | where hi is: hi: to-decimal #{7fef ffff ffff ffff} | Thu 14:07 |
| 15923 | Geomol | Funnily enough, 1.5 is the middle value when talking ulps: >> ulps 0.0 1.5 == 4609434218613702656 >> ulps 1.5 hi == 4609434218613702655 | Thu 14:07 |
| 15922 | Geomol | space between *numbers* are ... | Thu 14:03 |
| 15921 | Geomol | The highest decimal is
>> to-decimal #{7fef ffff ffff ffff}
== 1.79769313486232e+308 There is the same number of ulps between 0.0 and 2.0 as between 1.0 and the highest decimal: >> ulps 0.0 2.0 == 4611686018427387904 >> ulps 1.0 to-decimal #{7fef ffff ffff ffff} == 4611686018427387903 I think, the space between number are different all the way from zero to the highest decimal, but I'm not sure. | Thu 14:03 |
| 15920 | Ladislav | etc. | Thu 13:54 |
| 15919 | Ladislav | yes, you get different result only when trying (dec-as-int 0.0) - (dec-as-int -0.0) | Thu 13:54 |
| 15918 | Geomol | If this is correct, then my suggestion to do random 1.0 many times will actually show the problem. | Thu 13:53 |
| 15917 | Geomol | >> (dec-as-int 0.1) - (dec-as-int 0.0)
== 4591870180066957722
>> (dec-as-int 0.2) - (dec-as-int 0.1)
== 4503599627370496 Same result. Now I'm confused! :-) | Thu 13:53 |
| 15916 | Ladislav | sorry, (dec-as-int hi) - (dec-as-int lo) | Thu 13:50 |
| 15915 | Geomol | It seems, numbers lie much closer around zero than around 0.1. | Thu 13:50 |
| 15914 | Ladislav | (as-int hi) - (as-int lo) | Thu 13:50 |
| 15913 | Geomol | >> ulps 0.0 0.1 == 4591870180066957722 >> ulps 0.1 0.2 == 4503599627370496 | Thu 13:49 |
| 15912 | Geomol | So an R3 ulps could be: ulps: func [ lo [decimal!] hi [decimal!] ][ (to-integer to-binary hi) - to-integer to-binary lo ] | Thu 13:48 |
| 15911 | Ladislav | your "difference in ulps" is just the difference between the ordinal numbers | Thu 13:44 |
| 15910 | Ladislav | REBOL [
Author: "Ladislav Mecir"
Purpose: {Converts decimal to ordinal and back}
] make object! [ int-min: to integer! #{8000000000000000} set 'dec-as-int func [x [decimal!]] [ x: to integer! to binary! x either x < 0 [int-min - x] [x] ] set 'int-as-dec func [x [integer!]] [ if x < 0 [x: int-min - x] to decimal! to binary! x ] ] | Thu 13:43 |
| 15909 | Geomol | The reason, I prefer your first version is: - I always know the endpoints exactly. - The mean is well defined. - The function is simpler and faster. | Thu 13:43 |
| 15908 | Ladislav | suggestion: R3 | Thu 13:43 |
| 15907 | Geomol | I'm in doubt about the distribution of numbers. Is this R2 function calculating ulps between two number ok? ulps: func [ value1 value2 /local d1 d2 ][ d: make struct! [v [decimal!]] none d1: make struct! [hi [integer!] lo [integer!]] none d2: make struct! [hi [integer!] lo [integer!]] none d/v: value1 change third d1 third d d/v: value2 change third d2 third d print [d1/hi d1/lo d2/hi d2/lo] print [d1/hi - d2/hi * (2 ** 32) + d1/lo - d2/lo] ] | Thu 13:42 |
| 15906 | Ladislav | ...and your main reason is, that you know the endpoints exactly? | Thu 13:41 |
| 15905 | Geomol | yes | Thu 13:40 |
| 15904 | Ladislav | do I understand correctly, that you prefer the variant including both endpoints? | Thu 13:40 |
| 15903 | Ladislav | - in that case the chances are much higher, that you could detect any irregularities | Thu 13:38 |
| 15902 | Ladislav | for sure, if the difference should be detectable, then you should try random 2 ** 1023 | Thu 13:37 |
| 15901 | Geomol | ah yes. :) You need larger numbers. Up to what number is the distance between numbers the same? 2.0? | Thu 13:34 |
| 15900 | Ladislav | (the random numbers you may obtain are regularly spaced in that case) | Thu 13:34 |
| 15899 | Ladislav | for random 1.0 you cannot find any irregularities, there aren't any | Thu 13:33 |
| 15898 | Geomol | A test could be to run random 1.0 many many times and save the results coming close to zero. Like my other test, checking if the result is within the first 1024 number close to zero. After running the test many times, a picture can be seen. | Thu 13:32 |
| 15897 | Ladislav | yes, you would have to run the test "almost forever" to see anything | Thu 13:31 |
| 15896 | Ladislav | but, anyway, I am still pretty sure, that such a difference actually is undetectable | Thu 13:30 |
| 15895 | Geomol | It could take a long long time to run an example showing this. | Thu 13:29 |
| 15894 | Ladislav | aha, more hits for the max...sorry, did not take that into account | Thu 13:27 |
| 15893 | Ladislav | ...it could influence the mean value only if the compiler used an "insensible" way of rounding | Thu 13:23 |
| 15892 | Geomol | You take a lot of hits for the max value and convert them to 0.0. | Thu 13:22 |
| 15891 | Geomol | yes, it does. I would say, of course it does. :) | Thu 13:21 |
| 15890 | Ladislav | but, that cannot influence the mean value | Thu 13:21 |
| 15889 | Geomol | The result will look strange around zero. Many many counts for 0.0 and very few counts for the following numbers. | Thu 13:21 |
| 15888 | Geomol | yes | Thu 13:20 |
| 15887 | Ladislav | less numbers (lower density of numbers) = higher hit count per number | Thu 13:20 |
| 15886 | Geomol | So when you do the calculation going from a random integer and divide to get a decimal, you get a result between zero and 10.0. If the result is close to zero, there are many many numbers to give the result, while if the result is close to 10.0, there are much fewer possible numbers to give the result. | Thu 13:19 |
| 15885 | Ladislav | aha, yes, the numbers aren't uniformly distributed; well, can you test it? | Thu 13:18 |
| 15884 | Geomol | But the number lie much closer around zero than around 10.0. | Thu 13:16 |
| 15883 | Ladislav | (if it does not work that way, then there is a bug) | Thu 13:16 |
| 15882 | Ladislav | no, the hits are expected to be uniformly distributed, i.e. the same number of hits for 0.0 as for any interior point is expected | Thu 13:16 |
| 15881 | Geomol | If you did e.g. random 10.0 many many times, wouldn't you get a result, where 0.0 has a lot of hits, the first number higher than 0.0 will get close to zero hits, and then the number of hits will grow up to the number just below 10.0, which will have almost as many hits as 0.0? | Thu 13:14 |
| 15880 | Ladislav | I think, that the "main problem" may be, that the uniform deviates are only rarely what is needed, quite often it is necessary to transform them to normal, lognormal, exponential, or otherwise differently distributed deviates | Thu 13:05 |
| 15879 | Ladislav | hmm, but I am still not sure, you would have to use a denormalized number as an argument to be able to detect the difference | Thu 13:01 |
| 15878 | Geomol | You're doing a good job, I just don't agree with Carl's view on this. | Thu 13:01 |
| 15877 | Ladislav | yes, in that case, sure | Thu 13:00 |
| 15876 | Geomol | If you do a lot of random 2 ** 300 , the mean will be a lot below 2 ** 300 / 2. | Thu 13:00 |
| 15875 | Ladislav | moreover, this version is quite standard - see e.g. Wikipedia, or the Dylan programming language, etc. | Thu 12:59 |
| 15874 | Ladislav | "slightly below 5.0 and 50.0" - certainly, but the difference is "undetectable" in these cases | Thu 12:58 |
| 15873 | Geomol | With the new random, 0.0 will also get a lot more hits than numbers close to 0.0. It's because the distance between different decimals is small with number close to zero, while the distance gets larger and larger with higher and higher numbers. (Because of IEEE 754 implementation.) So the max value will get a lot more hits than a small number, and all hits on the max value gets converted to 0.0. I wouldn't use the new random function with decimals. | Thu 12:57 |
| 15872 | Geomol | Ladislav wrote: "5.0 and 50.0 (or, do you mean, it is only "roughly" 5.0 and 10.0?)" Yes, the mean must be slightly below 5.0 and 50.0 with the new random. With your first version, it is exactly 5.0 and 50.0. | Thu 12:46 |
| 15871 | Anton | BrianH, oh well, it's a pity. | Thu 5:21 |
| 15870 | PeterWood | Brian H: My "suggestions" are not suggestions merely questions. | Thu 5:20 |
| 15869 | BrianH | Anton, we decided that making EQUAL? more worthy of its name would break too much code that depends on it being loose. Oh well :( | Thu 5:02 |
| 15868 | BrianH | Peter, in response to the suggestions in your last message:
- issue! = binary! : not good, at least in R3. Perhaps issue! = to-hex binary!
- integer! = binary! : not good, at least in R3. Use integer! = to-integer binary! Actually, anything-but-binary! = binary! is a bad idea in R3, since encodings aren't assumed. The TO whatever conversion actions are good for establishing what you intend the binary! to mean though, especially since extra bytes are ignored - this allows binary streams. | Thu 5:00 |
| 15867 | Anton | Ladislav, your "parsing a lit-path" example above looks ok to me for the proposed ALIKE?/SIMILAR? operator, and EQUAL? if it's been decided that EQUAL? remains just as ALIKE?/SIMILAR?, but not ok if EQUAL? is refitted to name its purpose more accurately (ie. EQUAL? becomes more strict). | Thu 4:03 |
| 15866 | Anton | Peter, are you sure you would never want to compare an email with a url?
What about urls like this?
http://some.dom/submit?email=somebody@somewhere.net I might want to see if a given email can be found in the query string. | Thu 3:52 |
| 15865 | Maxim | wouldn't it be cool to load a rebol instance as a plugin within rebol? :-) this could be the basis for an orthogonal REBOL kernel :-) | Thu 1:05 |
| 15864 | Maxim | I WANT PLUGINS !!!!! :-) | Thu 1:03 |
| 15863 | PeterWood | I believe that there needs to be some restriction on the datatypes on which the '= function will work. It seems to make no sense to comparer a URL! with an email! (Unless you define a URL! to be equla to an email! if they refer to the same ip address or domain name. Perhaps that's something for same?). It's harder to say whether an issue! can be equal to a binary! but waht about an integer! with a binary!? | Thu 0:41 |
| 15862 | PeterWood | The R2 behaviour has the advantage that it is easy to define and understand (especially if the function helpext was improved). If other options are to be considered, defining the desired results will be more difficult. No wonder you ar taking this on. | Thu 0:35 |
| 15861 | Ladislav | actually, my task now is to define the desired results of such comparisons for R3, (which may serve as documentation too) | Wed 23:55 |
| 15860 | PeterWood | Ladislav: I reported bug #3518 in Rambo mainly because the behaviour of the '= function is not consistent. My thinking was if 1 = 1.0 why doesn't #"a" = "a"? It appears that the '= function acts as the '== function unless the types are number!. I have come to accept that Rebol has been designed pragmatically and, understandably, may be inconsistent at times. I thing this makes the need for accurate documentation essential. I would hope that the function help for = can be changed to accurately reflect the functions behaviour. | Wed 23:54 |
| 15859 | Ladislav | 5.0 and 50.0 (or, do you mean, it is only "roughly" 5.0 and 10.0?) | Wed 23:53 |
| 15858 | Geomol | RANDOM is a distribution. Getting random integers, the mean value is well defined as: (max + 1) / 2 So e.g. random 10 will give a mean of 5.5. What is the mean of random 10.0 or random 100.0 | Wed 23:00 |
| 15857 | Ladislav | just for the record: a variant yielding all values in the interval including the endpoints with equal frequency is possible too (just the generating formula is a bit different) | Wed 22:38 |
| 15856 | Ladislav | well, for some applications (Fourier analysis) it makes the most sense that way | Wed 22:37 |
| 15855 | Geomol | I find, the first version, with both endpoints (0.0 and the input value) as possible output with half frequency than other possible values in between, gives most sense. I think of a number line going from 0.0 to the given value, and a random number is picked on the line. | Wed 22:34 |
| 15854 | Ladislav | it has been corrected (ticket #1027) yesterday, but Geomol seems to dislike the fact, that the correction excluded the given value. Anybody wanting to express their preferences? | Wed 22:29 |
| 15853 | Ladislav | showing, that my "original" implementation of the uniform deviates actually generated both endpoints of the specified interval: the 0.0 as well as the given value, but both with the frequency equal to the half of the frequency of any interior value | Wed 22:27 |
| 15852 | Ladislav | ;This is an example by Geomol: d: to-decimal to-binary 1023 blk: [] insert/dup blk 0 1024 random/seed now loop 1000000 [ i: to-integer to-binary random d blk/(i + 1): blk/(i + 1) + 1 ] print [blk/1 blk/512 blk/1024] | Wed 22:24 |
| 15851 | BrianH | I like the idea of non-datatype-specific EQUAL? considering datatypes in the any-string! family to be equal to each other, and also the any-block!, any-word! and number! families. I'm a little wary of the potential breakage, though have no idea of the scale of it. Is anyone aware of any code that wouuld be broken if EQUAL?, =, NOT-EQUAL?, <> and != changed in this way? | Wed 21:35 |
| 15850 | Ladislav | (it is related to the Rambo#3518 ticket) | Wed 21:19 |
| 15849 | Ladislav | this is a test that succeeds in R2 as well as in R3; but, is it really supposed to? a-value: first ['a/b] parse :a-value [b-value:] not equal? :a-value :b-value | Wed 20:56 |
| 15848 | Ladislav | Peter once ( Rambo#3518 ) objected against some things being inequal. I could use more opinions on this. | Wed 19:37 |
| 15847 | BrianH | If necessary, put off releasing the plugins until after the vacation, in case perspective is needed :) | Wed 15:01 |
| 15846 | Pekr | Well, summer is going to be a slow time anyway, for many of us ... | Wed 14:50 |
| 15845 | Pekr | Do you think fixing another 20 tickets, or releasing plugins finally? :-) | Wed 14:50 |
| 15844 | Anton | Nothing. Better let him finish up what he was doing. | Wed 14:32 |
| 15843 | Pekr | If I understand it correctly, Carl is leaving for vacation in France at the end of the week. So - what last minute fixes do we request, before Carl vanishes for 2 or so weeks? :-) | Wed 14:29 |
| 15842 | BrianH | Once the data structure is in memory, it doesn't matter whether it was created with a mezzanine or a native - all that matters is what kind of data structure it is. The nested block style is better for some things (data structure manipulation, flexibility) but worse at others (vector math). You make your tradeoffs. At least in R3 you have a choice :) | Wed 13:54 |
| 15841 | BrianH | I don't understand: "I never use them, as I worry they are slow (mezzanine)." REBOL doesn't really have multidimensional arrays. There is an ARRAY function that creates nested blocks (which is as close as C gets to multidimentional arrays too), but once created they aren't mezzanine, they're a data structure. | Wed 13:49 |
| 15840 | BrianH | It is possible that vectors will get multidimensional addressing - it is sort-of planned to do so, but nothing concrete yet. | Wed 13:43 |
| 15839 | Pekr | btw - as for 'arrays - will there be any change in R3? I never use them, as I worry they are slow (mezzanine). Now with vectors, blocks and arrays - do we have fast multidimensional arrays and vectors? | Wed 12:59 |
| 15838 | Ladislav | seems, that Carl agrees with you | Wed 9:19 |
| 15837 | sqlab | why should be this
>> equal? b []
== true
but
>> equal? [] b
** Script error: out of range or past end
** Where: equal?
** Near: equal? [] b equal? should just compare the two params, but not test if they are in in their own limits. As I understand this, blocks are containers and empty containers are equal from the outside. Even errors should be equal.) | Wed 5:43 |
| 15836 | BrianH | Internally you could even convert the datatype! to a typeset! and use FIND; since typesets are immediate there would be no overhead. | Tue 18:25 |
| 15835 | BrianH | It could take a datatype/typeset parameter (probably the first parameter of two). | Tue 18:23 |
| 15834 | Henrik | the lack of datatype screening might be a problem. | Tue 18:21 |
| 15833 | Henrik | I have not thought it through that much, other than figuring there would have to be a way to shorten that code to one step. I have compiled a list of neutral values for all types, that are capable of producing neutral values. Some can't, and I wonder what the response to NEUTRAL? would be there. | Tue 18:19 |
| 15832 | Maxim | my name for the function was: meaningfull? | Tue 18:17 |
| 15831 | Maxim | its just different allows different optimisation of conditionals. neutral? can be very usefull, especially for GUI handling code... where you usually don't care for the type, but only if a value is meaningfull. | Tue 18:17 |
| 15830 | BrianH | I prefer REBOL's false/none treatment to Python's, but that NEUTRAL? sounds good, especially if it also checked for unset values, and SERIES? instead of BLOCK?. | Tue 18:12 |
| 15829 | Maxim | (altme is fast here. (very)) | Tue 18:07 |
| 15828 | Maxim | I have often wondered what the name for the function would be.... 'NEUTRAL? is not bad! | Tue 18:06 |
| 15827 | Maxim | henrik: the neutral? is very usefull, python uses that as the false values. when everything is coded using this it simplifies a lot of code, even more than using none. | Tue 18:05 |
| 15826 | BrianH | (AltME is slow for me today) | Tue 18:01 |
| 15825 | BrianH | (that was in answer to your last message) | Tue 18:00 |
| 15824 | BrianH | Yeah. However, consistently not caring about out-of-bounds on read seems more useful. We only care on write. | Tue 17:59 |
| 15823 | Ladislav | my experience tells: it is better to be able to find out what the value of INDEX actually is (even for debugging), than to obtain an error, which does not tell me where I actually am | Tue 17:59 |
| 15822 | Ladislav | aha, so you examined the possibility to change the INDEX? behaviour as well | Tue 17:57 |
| 15821 | BrianH | Ladislav, my point was that if bounds matter, INDEX? *not* generating an error (or changing its results) for an out-of-bounds index *is itself an error*. If bounds don't matter (except apparently for POKE), then INDEX? not changing its behavior is fine. | Tue 17:56 |
| 15820 | Ladislav | sorry, I mean poke block 4 index | Tue 17:54 |
| 15819 | Ladislav | "using an object for the index should raise an error" - you mean e.g. poke 4 index, when the index is "out"? | Tue 17:53 |
| 15818 | Maxim | as long as the index can be used as such. using an object for the index should raise an error. | Tue 17:52 |
| 15817 | Ladislav | moreover, the INDEX? function does not show you an error. | Tue 17:51 |
| 15816 | BrianH | I'm OK with declaring that bounds don't matter, and that INDEX? is not an error. The rationale for the new series bounds model was my idea, anyways. And having =, !=, == and !== (and their actions) not generate an error is consistent with that. Just taking the devil's advocate position :) | Tue 17:49 |
| 15815 | Ladislav | PICK happily allows you to examine any position, so a code that works in a manner incompatible with PICK is violating the block design principle IMO | Tue 17:46 |
| 15814 | BrianH | So we could either have INDEX? be an error, or unstable. Which do you prefer? | Tue 17:45 |
| 15813 | BrianH | So, either b is an error in R3, or INDEX? is an error (which might be the case). | Tue 17:45 |
| 15812 | BrianH | There is a lot of correct code that would assume that >>greater-or-equal? length? head b index? b If this is ever not the case and I try to retrieve a value from that reference before that condition is true again, that is a serious error. If you fill in the missing data before you attempt to retrieve anything, not an error. | Tue 17:44 |
| 15811 | Ladislav | If we examine the "nature" of the implementation of REBOL blocks, then we come to the conclusion (at least I do), that the "abstraction" is as follows: (at least when we examine the PICK function): a block is an "essentially unlimited" series of values, the majority of them are #[none] s, except for a limited "segment", which may "contain" other values as well | Tue 17:43 |
| 15810 | BrianH | I'm not convinced that the lack of an error with the straight b reference is good either. It seems like a good error to throw. | Tue 17:39 |
| 15809 | Ladislav | EQUAL? b b causes an error. The value of such an error is doubtful, taking into account, that e.g. the MOLD function accepts the series happily, in an incompatible manner. So, what is "more useful"? To cause or not to cause? My personal opinion is, that the value of causing the error is totally negligible even for the beginners. (the EQUAL? function is not meant to be used as the function supposed to be used for such checking) | Tue 17:37 |
| 15808 | BrianH | No "but there also" related to EQUAL? in your statement, so that was the assumed subject of "The current behaviour in R3". | Tue 17:35 |
| 15807 | BrianH | EQUAL? b b gives an error in R3, as does = and ==. | Tue 17:32 |
| 15806 | sqlab | No, it does not give an error in R3. >> b: tail [1 2 3] == [] >> clear head b == [] >> b == [] | Tue 17:30 |
| 15805 | BrianH | It yields an error in R3 too. You *want* that error because it tells you that you have bad series references. You want to know that. | Tue 17:27 |
| 15804 | sqlab | Why should equal? b b yield a error? Just because it gives back an error in R2, but there also b alone gives back an error. The current behaviour in R3 is much better. | Tue 17:24 |
| 15803 | Henrik | I'm considering the concept of neutral values: Empty blocks, empty strings, zero, true and generally what is default made with MAKE <type> []. It comes from typing this alot: all [ val block? val empty? val ] which would be equivalent to: neutral? val It may be a bad idea. | Tue 17:21 |
| 15802 | BrianH | EQUAL? is used more often by newbies and people doing quick programming. Such people would be better served by the error. | Tue 17:18 |
| 15801 | Anton | I think this is just about performance. SAME? has a simple job to do to see if two values are the same. EQUAL? investigates in more depth, and then discovers the range problem. This seems like a good implementation and I like the current behaviour. | Tue 13:57 |
| 15800 | Ladislav | the above was yet another domain-related example. I can imagine the EQUAL? example to yield TRUE as an alternative. Which one do you prefer??????? | Tue 7:49 |
| 15799 | Ladislav | >> b: tail [1 2 3]
== [] >> clear head b == [] >> same? b b == true >> equal? b b ** Script error: out of range or past end ** Where: equal? ** Near: equal? b b ** Note: use WHY? for more about this error | Tue 7:48 |
| 15798 | Ladislav | Domain of EQUAL? EQUIVALENT? STRICT-EQUAL? and SAME?: currently they are declared to accept all values except for #[unset!] Any proposals for change? | Tue 7:47 |
| 15797 | Ladislav | as far as I am concerned, this looks acceptable | Tue 7:29 |
| 15796 | Ladislav | A question from Carl: Should #877 just cause an error (infinite cycle): a: copy [] insert/only a a copy/deep a | Tue 7:29 |
| 15795 | BrianH | Whoops, typo. Fixed. | Tue 1:01 |
| 15794 | Pekr | A65 notes mention bind-of .... but A65 release does not know this function - it is undefined. So - what is 'bind-of? | Mon 22:38 |
| 15793 | Ladislav | for Henrik (and others?): you can add your BUILD requirements/notes to http://www.rebol.net/wiki/Replacement | Mon 16:03 |
| 15792 | Maxim | version A62 just has to be a special version, it was released on my birthday :-) | 26-Jun 3:58 |
| 15791 | PeterWood | Thanks, Sunanda | 26-Jun 0:16 |
| 15790 | Sunanda | You are missing a TO (or a MAKE) a: TO map! [a 1 b 1 c 1] to-block a == [a 1 b 1 c 1] | 26-Jun 0:02 |
| 15789 | PeterWood | How do you convert a Map! to a Block! in R3? The obvious way doesn't seem to work: >> a: map! [a 1 b 1 c 1] == [a 1 b 1 c 1] >> b: to block! a == [map!] | 25-Jun 23:57 |
| 15788 | BrianH | Yeah, it's why there is no NOT-SAME? function - no operator needs it. | 25-Jun 19:49 |
| 15787 | Izkata | and I didn't know about the op! mapping | 25-Jun 19:47 |
| 15786 | Izkata | Mmk, I must have just never run across a case where I would have seen that by coincidence. | 25-Jun 19:46 |
| 15785 | BrianH | You need a NOT-EQUAL? action so you can have a != operator. Every op! maps to an action!, no exceptions. | 25-Jun 19:26 |
| 15784 | BrianH | EQUAL? in R2 is level 1. Changing it to level 2 would break a lot of code, particularly for word equivalence :( | 25-Jun 19:25 |
| 15783 | Izkata | I meant the one he labeled "the bottom level", the non-transitive one ;)
I'll call "the bottom level" level 1, then increase to 4, for now. Generally I only use EQUAL? in R2, which appears to me to be level 2 (although you named it level 1?), but can see why the stricter levels 3 and 4 are helpful - I just don't see where level 1 can be used right now. As far as naming goes, my only question is the need for negatives. Why isn't NOT sufficient? ("not equal?" rather than "not-equal?", etc) I forget MAKE can be used with things other than object!, I use it that way so rarely. So yeah, /deep doesn't make sense now that I think about it =P | 25-Jun 19:23 |
| 15782 | BrianH | Adding a refinement to MAKE would be a bad idea, since it is a very low-level action that all datatypes support. COPY/types though... :) | 25-Jun 18:36 |
| 15781 | BrianH | Izkata, when refering to Ladislav's levels, please number them (as he should have). I'm not sure what you mean by "the bottom level". If you mean the first level, that is an exact description of the behavior of EQUAL? or = in R2. | 25-Jun 18:34 |
| 15780 | Sunanda | Another update of my R2--->R3 porting adventures. Highlights of new stuff: -- pick 0 vs pick -1 -- hash vs map -- examples of version sniffing to ensure one source works in R2 and R3 (thanks to Ladislav for the method of distingishing R2 from R3) http://www.rebol.org/art-display-article.r?article=j26z | 25-Jun 18:14 |
| 15779 | Izkata | (I went to sleep right after my last comment, hence the lag) On equality: Ladislav's idea sounds good, but I don't exactly see the point for having the bottom level in there. What use would it be for? How/where would the range for "approximate" be set? On objects: I think I may have misread it earlier - my comment was, "copy/deep [object1 object2]" should return a new block that still points at object1 and object2, rather than creating two duplicates of them. But from the comments it certainly doesn't sound like I was thinking. (Although make/deep or "copy/deep/types foo [object! series!]" suggestions sound like they may help..?) | 25-Jun 16:54 |
| 15778 | BrianH | Keep in mind that BIND/copy is more efficient in R3, and in theory doesn't even need to be a copy: It could be copy-on-write., | 25-Jun 8:10 |
| 15777 | BrianH | So I'm suggesting that the things that would normally be bound in an object spec get BIND/copy when you MAKE from an object prototype, but otherwise referenced. That means BIND/copy of blocks, words, functions and closures. The rest can be copied by the init spec if you need to, or not. | 25-Jun 8:09 |
| 15776 | BrianH | And if you have MAKE do a deep copy (as it does now in R3), memory explodes and you can't do graph references. So you need a way to make a deep copy too, in case you need to. | 25-Jun 8:04 |
| 15775 | BrianH | However, you can't have MAKE do a shallow copy: Spec blocks would explode in size. So you need another way to do a shallow copy. | 25-Jun 8:02 |
| 15774 | BrianH | Without rebinding, both shallow and deep copy of objects can have problems. That's why MAKE is the sensible default, the easy thing. | 25-Jun 8:00 |
| 15773 | Izkata | I haven't been following too closely, but I'm against copy making a new object from an old one. I'd have to look at the suggestions more to have more comments | 25-Jun 7:58 |
| 15772 | BrianH | I am overdue to go to sleep - it's 3am here. I expect to wake up and find more comments, darnit :) | 25-Jun 7:57 |
| 15771 | Pekr | ouch, meeting in 4 minutes ... starting my preparation work :-) | 25-Jun 7:56 |
| 15770 | Pekr | We imo need to quickly proceed to Beta. I want to start using R3 as an R2 replacement soon. I need SQLite and then GUI, but I can wait with the GUI. | 25-Jun 7:56 |
| 15769 | BrianH | Max is missing that I already proposed a more flexible solution than he is proposing. He is so focused on the behavior of MAKE that he missed that I also made proposals for COPY andf COPY/deep. | 25-Jun 7:55 |
| 15768 | Pekr | Well, if you agree, it is cool. Make a decision and move on - we have still tonnes of issues to solve :-) You know - half functional modules, no concurrency, no upper layer networking, still no plugins, no GUI (and Flash is going to be everywhere by the end of the year) ... that seems like a really lot of catch-up we need to play ... | 25-Jun 7:54 |
| 15767 | Pekr | Well, but then there are those, who's opinion is irrelevant, as mine :-) As for equality, I think you are directing a good direction, as well as for copying. I do agree with Max, that we need max flexibility to decide what gets copied and what not. Some things can then be pre-set, other set by users at will. We need good memory management ... | 25-Jun 7:53 |
| 15766 | BrianH | Especially since Ladislav and I agree about levels of equality - it's usually scary when we agree :) | 25-Jun 7:53 |
| 15765 | BrianH | We could use more opinions on two short-term decision blogs: - http://www.rebol.net/r3blogs/0211.html Levels of equality - http://www.rebol.net/r3blogs/0212.html Copying and/or making objects Please chime in! We need more opinions than just those of Ladislav, Maxim and I :) | 25-Jun 7:51 |
| 15764 | Sunanda | Apologies and thanks, Ladislav -- I'll update the article again probably tomorrow. | 24-Jun 18:06 |
| 15763 | Ladislav | Sunanda: your alphametics problem is caused by bug#851 | 24-Jun 17:58 |
| 15762 | Ladislav | conversion done, you can download A62 | 24-Jun 17:42 |
| 15761 | Pekr | back from business trip. So what's the binary conversion status? Is it just a test how it turns out, or are we definitely going that direction? | 24-Jun 17:41 |
| 15760 | Ladislav | Sunanda: Correction! I told you, that it was the largest INTEGER! prime in R3, I did not claim a larger one is not findable | 24-Jun 17:40 |
| 15759 | Steeve | As Brian pointed, it's not difficult to port to R3 but it's not optimized for R3 and to do so; it will need more rewrite. | 24-Jun 16:14 |
| 15758 | Sunanda | Thanks Steeve -- will try that later. Thanks Brian -- though it's early days yet. I've deliberately picked the nursery-slope scripts. I have others I'll build up to that regularly acted as R2 stress-testers. | 24-Jun 16:08 |
| 15757 | Steeve | for RSE-IDS source | 24-Jun 15:51 |
| 15756 | Steeve | sunanda, in insert-compact, replace: >>prev: pick here -1 by >>prev: pick here 0 | 24-Jun 15:50 |
| 15755 | BrianH | Interesting article :) It's great to see how easy porting from R2 to R3 is :) | 24-Jun 15:45 |
| 15754 | BrianH | Some tweaks: - OR~, not ~OR - AND~, OR~ and XOR~ work in R2 as well, and should be used instead of AND, OR and XOR for prefix use. | 24-Jun 14:58 |
| 15753 | Sunanda | Just updated my article about my early R3 porting adventures. Highlights of changes: -- shout outs to Ladislav and Steeve -- thanks, guys -- fix of to-pair issue -- aside about the largest prime discoverable prime number in REBOL -- I suggest any discussion on that goes into [Puzzle answers] -- problem with parse --- see ISSUE under rse-ids.r -- Can anyone help diagnose the issue? Thanks! http://www.rebol.org/art-display-article.r?article=j26z | 24-Jun 14:50 |
| 15752 | Maxim | yep... I just meant... it has to be very precisely/explicitely documented :-) btw, I added other qualitative word examples for equality-likeness-sameness on the post... might give you ideas for a better scalling of the four levels | 24-Jun 5:08 |
| 15751 | BrianH | I believe there is a blog conversation about that now :) | 24-Jun 4:29 |
| 15750 | Maxim | the difference between EQUAL? and SAME? | 24-Jun 4:27 |
| 15749 | Maxim | the EQUAL? note is very important to mention in the docs... and its important for the difference between them to be very explicitely defined for all types, somewhere. | 24-Jun 4:27 |
| 15748 | BrianH | The advantage of map keys is that they don't have to be the SAME? as the key, they can just be EQUAL? and the hashing speeds things up. With objects you either have a reference to it or you don't. If you have a reference, you can extend it with new fields, which can refer to the values you want to associate with the object. If you don't have a reference you need to specify a key within the object that you are searching for, and hashing won't help there, but we're going to add a mezzanine to do that kind of searching. | 24-Jun 4:22 |
| 15747 | Maxim | he'll ask me for an example of usage... now I have to scan my brain for the last 10 years of REBOL usage... and remember when I'd used this... hehe | 24-Jun 4:01 |
| 15746 | BrianH | Bring it up with Carl :) | 24-Jun 3:55 |
| 15745 | Maxim | but the object pointers can be hashed? no? | 24-Jun 3:54 |
| 15744 | BrianH | Map keys get hashed when the map gets large enough. No, I don't know how large that is :) | 24-Jun 3:52 |
| 15743 | BrianH | You can use objects as the values, but the keys need to be hashable :) | 24-Jun 3:51 |
| 15742 | Maxim | like find with blocks is very fast. it only maps the exact same object, not a similar object AFAIK. | 24-Jun 3:49 |
| 15741 | Maxim | if you used the object's pointer in the map internally, we could use objects too, it would actually be very usefull and not that much heavy to implement. | 24-Jun 3:49 |
| 15740 | Maxim | yep this means we can use the map exactly like in AREXX, very usefull for sparse arrays :-) | 24-Jun 3:48 |
| 15739 | BrianH | All types can be used as values though, except #[none] which will make the key disappear. | 24-Jun 3:44 |
| 15738 | BrianH | Binaries too, but not block, object or vector types. Word types are converted to word!. | 24-Jun 3:43 |
| 15737 | Maxim | I'm not sure what I wrote above makes sense.. hahaha | 24-Jun 3:43 |
| 15736 | Maxim | to me an unbound word is a lit-word in the context of the map... | 24-Jun 3:42 |
| 15735 | Maxim | a trick question... are set and get words enabled? and are they differentiated from lit-words? | 24-Jun 3:41 |
| 15734 | BrianH | Yup. | 24-Jun 3:40 |
| 15733 | Maxim | so scalars, pairs, tuples, strings, words at least? | 24-Jun 3:40 |
| 15732 | BrianH | Other types too, but not all other types. | 24-Jun 3:39 |
| 15731 | Maxim | are only words supported in map! or are other types usable for the key? | 24-Jun 3:38 |
| 15730 | Maxim | it makes me think of the array type in AREXX ;-) | 24-Jun 3:38 |
| 15729 | BrianH | Most of map!'s behavior was my idea. | 24-Jun 3:24 |
| 15728 | BrianH | Yup :) | 24-Jun 3:24 |
| 15727 | Maxim | yep :-) I guess asking for a word in a map which isn't there returns none ? | 24-Jun 3:23 |
| 15726 | BrianH | You can't bind to something that might go away :) | 24-Jun 3:22 |
| 15725 | BrianH | You can't bind to a map! because the keys are handled differently, with the keys going away when assigned none. | 24-Jun 3:22 |
| 15724 | Maxim | I've tried several times... I usually end up doing: load mold myblock | 24-Jun 3:21 |
| 15723 | BrianH | I'm trying to backport UNBIND to R2, but it's really tricky. | 24-Jun 3:20 |
| 15722 | Maxim | I could see the binding to map being usefull, it might be impossible due to the inner implementation of map | 24-Jun 3:20 |
| 15721 | BrianH | WORDS-OF works on any-object!, any-function! and map! too, though it's only bound to any-object!. | 24-Jun 3:19 |
| 15720 | Maxim | I see unbind is now part of R3 :-D | 24-Jun 3:17 |
| 15719 | Maxim | oh that is cool. | 24-Jun 3:16 |
| 15718 | BrianH | And the returned words are bound to the object. | 24-Jun 3:16 |
| 15717 | Maxim | no self ... COOL :-) | 24-Jun 3:16 |
| 15716 | BrianH | WORDS-OF, but the 'self word is not included. | 24-Jun 3:15 |
| 15715 | Maxim | the why? in R3 is a fabulous idea! | 24-Jun 3:15 |
| 15714 | Maxim | what is the replacement for first context [] in R3 I can't remember the function's name | 24-Jun 3:14 |
| 15713 | BrianH | I added a fairly comprehensive comment, with tests. I had to generate 3 CureCode tickets as a result :( | 24-Jun 2:26 |
| 15712 | Maxim | allowing COPY on objects makes much more sense to me. | 24-Jun 0:20 |
| 15711 | Maxim | IMO we need choice. this is such a fundamental part of data management that we cannot let the compiler decide. would you code in C if all structure copies behaved this way? if this where the case an OS would probably need 1TB of RAM to run. | 24-Jun 0:13 |
| 15710 | BrianH | Either way you need constructor code. The real question is balance. | 24-Jun 0:11 |
| 15709 | Maxim | (and ram too) | 24-Jun 0:11 |
| 15708 | Maxim | Plus all that binding takes MASSIVE amounts of time for nothing. | 24-Jun 0:10 |
| 15707 | BrianH | I'm still thinking. I'll comment after I narrow down this parse bug. | 24-Jun 0:09 |
| 15706 | Maxim | exactly, which is why I think we should not be bound by one or the other .... did you see my posts... I provide some alternatives. | 24-Jun 0:08 |
| 15705 | BrianH | I have been trying to think think it through - there are advantages and disadvantages to either way. It is harder to undo a copy than not... | 24-Jun 0:07 |
| 15704 | Maxim | brian I would like your comments on the deep object copy issue ( http://www.rebol.net/r3blogs/0212.html ) | 24-Jun 0:03 |
| 15703 | Ladislav | http://www.rebol.org/art-display-article.r?article=w24v - porting INCLUDE to R3 | 23-Jun 20:46 |
| 15702 | Sunanda | The link in the blog does not work [has /rebol3/ not /r3/ ] This link does work: http://www.rebol.com/r3/downloads/r3-a60.exe | 23-Jun 20:15 |
| 15701 | Carl | http://www.rebol.net/r3blogs/0213.html - A60 special release. | 23-Jun 20:01 |
| 15700 | Maxim | that is unless you consider a 100x (thats 10000%) increase in RAM usage and script slowdown acceptable. | 23-Jun 18:47 |
| 15699 | Maxim | in my case, it breaks every single API I have. | 23-Jun 18:39 |
| 15698 | Maxim | pekr: well, I did add new posts, but I think everyone MUST participate. this is such a core issue, it can make / break many systems out there. | 23-Jun 18:39 |
| 15697 | Maarten | I think I ran into him before (may be virtually), I remember him as a very kind and nice person. | 23-Jun 16:36 |
| 15696 | Maarten | Notice Meijeru's daytime work... must be a fruitful hobby. | 23-Jun 16:36 |
| 15695 | Sunanda | The bug fixes just keep coming -- Alpha 59 out barely a day after A58:
http://www.rebol.net/wiki/R3_Releases#View.exe_2.100.59_23-June-2009 Curecode #961 was fixed in less than 24 hours....That must be a record! | 23-Jun 13:50 |
| 15694 | Oldes | It's not another (secret) Pekr's name? :) | 23-Jun 13:02 |
| 15693 | BrianH | One more mystery person to go: Peta, are you out there? :) | 23-Jun 12:41 |
| 15692 | BrianH | Cool - we need as much help as we can get. I'm glad he participates in the chat too, and his testing has been very helpful. | 23-Jun 12:40 |
| 15691 | Pekr | BrainH: btw - Meijeru's identity confirmed - http://users.telenet.be/rwmeijer/ , he now mentions REBOL - http://users.telenet.be/rwmeijer/proglang/ | 23-Jun 7:20 |
| 15690 | Pekr | Maxim, now you can defend your copy deep on object issue - http://www.rebol.net/r3blogs/0212.html | 23-Jun 7:05 |
| 15689 | BrianH | SAME? meaning same bits should include the type flags too - otherwise same bits is meaningless or cooincidental. | 22-Jun 23:48 |
| 15688 | Ladislav | yet another posted | 22-Jun 23:09 |
| 15687 | BrianH | I hadn't noticed the new blog post. Replied there. | 22-Jun 22:51 |
| 15686 | Ladislav | how about my last comment to r3blog? | 22-Jun 22:42 |
| 15685 | BrianH | Struct! is not implemented, nor is denomination in money!. Closed ports are not errors and decimals are fixed. Unset and error are still not values. The only thing left is the date! zones and the type-ignorant any-word comparisons. | 22-Jun 22:25 |
| 15684 | BrianH | Ladislav, just checked your SAME? criticisms from the wiki against R3, and only the date! transitivity thing still applies. | 22-Jun 22:21 |
| 15683 | Tomc | better bit twitteling would be good | 22-Jun 20:15 |
| 15682 | BrianH | Including proper, powerful support for binaries in PARSE. | 22-Jun 19:05 |
| 15681 | BrianH | We gain a host of potential new abilities to work with binaries. Right now the half-assed way that binaries sometimes act like strings is making it difficult to process binaries like binaries. Getting rid of the false equivalency will make all sorts off improvements possible. | 22-Jun 19:04 |
| 15680 | Pekr | BrianH: if binary and string types are more divorced, what do we gain in particular? | 22-Jun 18:57 |