AltME groups: search

If we're really lucky we'll get the STRICT-NOT-EQUAL? integer! integer! 
fix (crossing fingers...).

compare: func [

    "Returns -1, 0 or 1 if the first value is lesser, equal, greater 
    than the second value."
    a b /else "Return NONE when equal (useful to chain COMPARE)"
][
    case [a < b -1 a > b 1 else [none] true 0]
]

all cards have different pipelines which calculate specific arythmetic 
in different order and with various optimisations.  texture mapping 
algorithms are different, and even the anti-aliasing is done differently 
from one card to another... unless you go with very basic settings 
which are equal on all cards.

But it's important to note that all styles are equal citizens in 
the R3 GUI. Tags are used for conceptual separation.

Hmm, you don't have to forbid setting INIT-SIZE. As I mentioned, 
it suffices to make sure INIT-SIZE, MIN-SIZE and MAX-SIZE are all 
equal.

I'll cast my vote to allow 'REBOL as an optional key, rather than 
'core, and leave it at that.

Documented does not equal explicit.

Since making the object doesn't change the block" - it does, I leave 
it as an exercise for the reader to find out how"

>> b: [print 'ok a: 1]
== [print 'ok a: 1]
>> b2: copy b
== [print 'ok a: 1]
>> make object! b
ok
>> b = b2
== true
>> b == b2
== true


b and b2 are clearly not the same, so I won't test that. Now, before 
you suggest a fourth type of equal test, maybe you should reconsider 
your statement, that this is a simple part of the language? And that 
my claim of this being a bug has something to it.


(I know, the difference lies in the binding, so you don't have to 
make any 'smart-ass' points about that, just take a step back and 
look at all this again. That's all I'm asking.)

Now, before you suggest a fourth type of equal test, maybe you should 
reconsider your statement, that this is a simple part of the language?

 - Ah, so now you are saying that the problem is that REBOL's MOLD 
 function does not *show* the binding of words?


This has nothing to do with simplicity, rather, it has to do with 
being intuitive. make object! changing the binding of words inside 
your B block is not intuitive, i agree. Intuition is not very useful 
when programming; still, there are many programming languages that 
try to be intuitive. I think REBOL is the *least* intuitive, especially 
if you have learned something about programming already.

Technical speaking, it's an expanded coercion for the equal operator, 
=, (and so also for the equal? function).

How about a minor addition to/restructuring of the comparison functions:
- equal?
- equiv?: equal + binding

- strict-equal?: equal + type + case + alias + decimal  (but _no_ 
binding)
- srict-equiv?: strict-equal + binding
- same?: as currently


(See http://www.rebol.net/wiki/Comparisons#EQUAL.3Ffor the status 
quo.)

The proposal above now is to have equal/strict-equal not respect 
binding, and have equiv/strict-equiv be their binding-respecting 
counterparts.

#1830 doesn't actually use STRICT-EQUAL?, so reordering the hierarchy 
won't help. You need to see the new 1830.

With the above strict-equal, it could safely use it.

For reference, also be aware that we have operator shortcuts for 
the comparison functions. At the moment:
=: equal? (and !=
==: strict-equal? (and !==)
=?: same?


The == operators should then probably become shortcuts for strict-equiv.

So let's update this with the decimal precision moved:

- equal?
- strict-equal?: equal + type + case + alias

- equiv?: equal + binding + decimal 
- strict-equiv?: equiv + type + case + alias

- same?: as currently

Strangely enough, it's not binding or exact decimal comparison that 
are at issue with FIND or strict-map! either, it's case and type. 
Nonetheless, this would make it easier to point to the distinction 
between STRICT-EQUAL? and STRICT-EQUIV? when talking about those, 
precisely because those aren't at issue.

As you see, case and type are the major distinction between equal 
and strict-equal.

So that would make it easy to define FIND as using EQUAL? per default, 
and STRICT-EQUAL? with /case.

equal plus no aliasing
 is bad wording.

But to me, "equal plus no aliasing" still does not clearly express 
whether aliased words are considered to be equal or ignored in this 
case.

equal or different*

Equal plus alias distinction
 was clearer to me.

>> equal? -0. 0.
== true

>> equiv? -0. 0.
== true

>> strict-equal? -0. 0.
== true

>> same? -0. 0.
== false

I think the real question is: we also have strict-equal? which is 
(IIUC) as strict as equiv? for numeric code using decimals _and_ 
is also mapped to operators: == and !==.

If we keep the mapping of strict-equal? to == then == would loose 
the added decimal precision under the new proposal.

This would solve the operator problem for developers who understand 
the limits of IEEE754, and still let regular developers expect 0.3 
to equal 0.1 + 0.1 + 0.1.

we could also add EQUAL-LENGTH? just for completeness

(In respect to Red/System, where those will be equal, performance-wise.)

Wait, is
    a: &[integer! 0]
equivalent to:
    a: &[struct! [value [integer!]] 0]  ; a has a value of null
or this:

    a: &[struct! [value [integer!]] [0]]  ; a points to an integer with 
    a value of 0
I would prefer the former. Then this code:
    a: &[integer! [0]]

might be equal to the latter, with the integer being allocated as 
a local variable on the stack.

Will Red implement operators in a fixed-predefined-set way like R2, 
or in a user-defineable way like R3?

 Op! will be user-defined as they were in R-sharp interpreter. Here's 
 a short extract of R-sharp's boot script:

+:  make op! :add
-:  make op! :subtract
*:  make op! :multiply
/:  make op! :divide
=:  make op! :equal?
<>: make op! :not-equal?

*** Compiler Internal Error: Script Error : equal-types? expected 
type1 argument of type: word
*** Where: comp-either 
*** Near:  [last-type: either equal-types? t-true t-false]

For the floating point format experts around: 


I am investigating the simplest and most accurate way to support 
floating point comparison by implementing an `almost-equal` operator 
in Red/System. Due to the intricacies of such task, I have selected 
the two algorithms that look the best to me:


1) Tolerance-based: http://realtimecollisiondetection.net/blog/?p=89

2) Ulp-based: http://www.cygnus-software.com/papers/comparingfloats/Comparingfloating point numbers.htm


Of course, in both approaches, there are some accuracy parameters 
to be set by the user to adjust the comparison formula (good defaults 
will be provided anyway).


Are there better algorithms or better implementations of methods 
1) or 2)?

Th new fixed version of Dawson's article is split in a new series 
of blog entries: http://randomascii.wordpress.com/category/floating-point/


But, alas, he hasn't yet reached the point where he shows the fixed 
version of `almost-equal` function.

There are two additional assertions in the float-partial branch that 
you might find useful Oldes. They aren't in the documentation yet. 
They are:


--assertF~= which takes three float!s, it compares the first two 
to be equal within a tolerance supplied as a third argument. The 
tolerance is both an absolute and relative tolerance. So, a tolerance 
of 0.01 would return true if the two floats were equal + or - minus 
0.01 or within 1 percent.

I have used a tolerance of 1e-12 in testing.

I feel bad because we saw many projects failed because of the same 
reason.


Don't feel bad! A month ago, you didn't know about World. Now you 
do, and now you have an extra option. Where is no reason to feel 
bad.


Afaik projects like Boron are open source, and you may put it in 
the category of "failed projects". So open source doesn't equal success.

Pekr, sorry I don't comment on all you say. But look e.g. at a product 
like WebOS, which was mentioned here in this AltME world not long 
ago. It was developed to the current state as close source. Just 
recently HP announced it to go open source. I judge it to be an ok 
success for the people behind it, even if it was developed as close 
source. Open source doesn't equal success. And close source also 
doesn't equal success. But they may be related.