filePro "eq" (was Re: Question about checks for min and max values)

[Kenneth Brody]

[...]
> 3 separate threads have all gotten conflated, here.  Let us try to
> untangle them.

Okay.

[...]
> > You haven't explained how filePro's "algebraic equals" is different
> > from other languages.
>
> We got off onto how eq behaves numerically, I believe, when you
> mentioned 0.0 != 0.00.  The original topic that drew me (and, I think,
> Mark) into the thread, was the behavior of eq with strings, and
> specifically that strings are 'eq' if they match to the length of the
> shorter variable.

Well, the start of the thread concerned an empty numeric field comparing
equal to "0".  I don't recall when the strings topic got added.

> *This* was the behavior which I asserted was counter to that of
> equivalent operators (or functions, when that's necessary for
> comparison) in other languages, some of which already existed when
> filePro's design was being taken.

Yes, I know your stand on filePro's comparison on two strings of
differing lengths.

> As far as numerical equality is concerned, if filePro *does* believe
> that 0.0 != 0.00, then I disapprove of that as much as I disapprove of
> floating point implementations where 6 - ( 2*3 ) != 0.  (Ok, that's a
> weak example, but I believe you know which artifact I'm referring to.)

No, filePro compares "0.0" and "0.00" numerically the same.  I was
really using that as an example of how most peoples' conception of how
math treats "equals" is wrong.  Someone was complaining that filePro
doesn't follow the "long established rules" of mathematics.  (And, I
doubt there are many computer languages out there that would follow
these "rules" and compare them as not equal.)

> As for "a number with a value", I much prefer the phrasing "a numeric
> variable to which no value has been assigned".

But that's *not* the same thing.

"A numeric variable to which no value has been assigned" simply means
"uninitialized".  Some programming languages will implicitly set such
a variable to zero.  Others will leave the variable in an undetermined
state.  Some will do both, depending on the variable.  (eg: in C, an
uninitialized variable outside of a function will be initialized to
zero, but an uninitialized non-static variable within a function will
not be initialized to anything and will remain in an undetermined
state until explicitly set.)  There is nothing you can to do an
existing variable with a value to make it "no value has been assigned".

"A number with no value" is one which has been set to a "no value"
value.  For example, you can explicitly set a numeric variable in
filePro to "".

Since this state (an empty numeric field) is what started this thread,
and your argument (or was it Mark's) was that filePro was breaking all
of these "long established rules" of mathematics and other programming
languages, such a claim couldn't go unchallenged.  Since neither math
nor these other languages have the concept of a numeric field with no
value, how can filePro's logic break their rules?

> How such a variable
> should be expected to behave is, in fact, implementation-dependent, and
> is the sole item I do *not* take issue with filePro on, here, oddly
> enough: you can do anything you like with them.

Then I guess it was Mark's point that filePro broke all of those rules?

Hold on...

Wasn't it you who said in <20050726181534.L1248 at cgi.jachomes.com>:

   Alas, they defined "equals" to mean something other than what every
   other programming language (as well as common mathematics) defines it
   to mean, which is the sole point that Mark and I are debating.

and

   Nope.  But I'm not going to repeat myself.  How filepro's 'eq'
   differs from the algebraic and string equals operator in other
   languages is something I've explained about 5 times on this thread
   so far.

Sounds like you disagree with numeric compares as well.

> If you choose to leave them blank as the representation of 'undef',
> instead of returning a '0', that's fine. In fact, it's *good*: it
> preserves some useful out-of-band information. It would be useful to be
> able to distinguish those cases, and I don't object to extra code for
> that, either.

--
KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
http://www.hvcomputer.com
http://www.fileProPlus.com