World: r3wp

ok, thanks, will read it ...

Expected behavior: things  which are modified  when one thing is 
 modified should be same.

Expected Reason for  current behavior:  bitsets with the  same data 
 share the  same data automatically  to save  space.

Expected Reason for bug: 'same? compares the  pointer to  the data, 
which is automatically made same with equal data.
Expected Fix: comare something else :)

:-)

Expected Reason for  current behavior:  bitsets with the  same data 
 share the  same data automatically  to save  space.
 proven wrong above

Expected Reason for bug: 'same? compares the  pointer to  the data, 
which is automatically made same with equal data.
 proven wrong above

Yep, I think SAME? was just quickly implemented using the existing 
equality function.

then it needs to be fixed, and we need precise definition, of what 
actually 'same compares and decides upon

can you make a simpler example, so i can analyze code? My tests say 
 yes, what  do i miss?

The the explanation with equal? makes sensse too.

I have proven, that there is a function (IDENTICAL?), which has got 
the following property:
a: b: charset [#"a" #"b"] c: insert charset [#"a"] #"b
identical? a b ; == true
identical? a c ; == false
identical? a copy a ; == false

but  how does itdecide that? If  it is by modifying the data, that 
would be re-samed when you change  the data  back

nothing is re-samed, if it were, IDENTICAL? a b would have to yield 
FALSE

hu? a and b have the equal content. so  they would point to  the 
same  data. so  'same? would return true.

Hmm, complicated . you may be  right. *thinking

would cost  much performance to keep track of all the data.

you are right, that it is *theoretically* possible, but in that case 
my IDENTICAL? function wouldn't be able to yield TRUE

It would if there is  an intemediate  structure. value -> intermediate 
-> bitsetdata.

then a and b point to that structure. the pointer in the structure 
is  changed. but a and b return the same still  the stuff.

.. return still the equal stuff.

I rather state it in a positive way: since my IDENTICAL? function 
correctly compares bitsets (can be tested), the model I am using 
is correct

IMHO  but  implementations would  have the same results, but mine 
is more silly;)

but -> both

as I said, I consider my claims proven. The IDENTICAL? function explores 
the identity by manipulating the data, so it actually is able to 
find out whether two bitsets share data or not

You modify the  a-node and  b points to the same node. if you check 
b you see the same changes.

yes, I found out, that A and B share data

in the same way I found out the A and C don't share data

They still  share the same data  if you point  a pointer in the node 
to something else. But - here is  rambo, move somewhere else. Your 
 version seems more  plausible from the  implementation effort, i 
want to makemy point  for  academical reasons.

understood, but you are missing an inconsistency in your reasoning

.. let us move somewhere else? (do not want to command you ;)

I am still not sure, whether this can or cannot be called a bug:

    #"a" = #"A" ; == false

Not a bug.

DESCRIPTION:
     Returns TRUE if the values are equal.

>> equal? #"a" #"A"
== false

and

>> to integer! #"a"
== 97
>> to integer! #"A"
== 65

Definitely not equal.

it is related to:

    difference [#"a"] [#"A"]

I think that case-sentisitivity does matter only with string! not 
with char!

looks so, but I don't think it is explicitely stated anywhere

but that's not true with FIND, hm.

yes, the situation is somewhat "mixed"

If FIND can be changed for R3, I'll be glad. I remember having problems 
with finding bytes in binary because of this inconsistency. I had 
to use find/case always.

unfortunately for you it seems to make sense, because the opposite 
refinement does not exist

yes, but it seems little bit strange, use find/case with pure binary 
data :)

But I though changing it only for char!, you can always use (find 
string "a") for case insensitive search.

Ladislav, I wonder if your task will be easier if you have an semantic 
model for the language instead of trying to create a coverage test 
set.

Another question worth asking: I can agree that it is useful to obtain 
TRUE from equal? 0.1 + 0.1 + 0.1 0.3, although zero? 0.1 + 0.1 + 
0.1 - 0.3 cannot yield TRUE due to the limitations of 64-bit IEEE754 
floating point format. On the other hand the STRICT-EQUAL? and/or 
SAME? functions may be stricter. E.g. my IDENTICAL? function (see 
above) is the most strict possible in that respect and yields FALSE.

AFAIK equal? in rebol is relaxed and does a range-check. For close-to-zero. 
And 'equal?  is the  relaxed version. 'strict-equal? should not. 
IMHO.

that is my understanding too. what about SAME?,  where would you 
like to see that in the strictness scale?

even more strict than 'strict-equal? :)

may break with  save/load because of conversion-errors, but if i 
use that i know what i do.

actually, e.g. for decimal! values there *is* a way how to suppress 
the conversion errors

(we only need 17 digits instead of 15)

AFAIK this  periodical things may clash. like 1/3. There  are values 
which work perfectly with one base and have periods in another. and 
then there are never enough digits. But i may thinking wrong.

I am going to submit a request to implement para/margin/y

any comments before I do ?