From: Fuad Saud Date: 2013-08-03T17:24:17+09:00 Subject: [ruby-core:56349] Re: [CommonRuby - Feature #8723] Array.any? predicate returns true for empty array. --047d7b603c14f0435104e306cc48 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Some more explanation reading on the subject - and reasons for this: http://en.m.wikipedia.org/wiki/Universal_quantification http://en.m.wikipedia.org/wiki/Vacuous_truth It's a basic classic logic definition. On Aug 3, 2013 5:02 AM, Martin J. D=FCrst wrote: > On 2013/08/03 15:40, nurettin (Nurettin Onur TUGCU) wrote: > >> >> Issue #8723 has been updated by nurettin (Nurettin Onur TUGCU). >> >> >> I find I need to address all the questions >> > > However I find the result needs not be defined. Also, defining "all?" or >> "any?" makes no sense for empty set since they will never execute. >> > > You say: > > > Also, defining "all?" or "any?" makes no sense for empty set since they > will never execute. > > So should be write code like > > unless enum.empty? > enum.all { |x| predicate(x) } > end > > Think about this in a bigger context. Assume we are applying .any or .all > not to a simple array, but to an array of arrays. > > We would e.g. write > > arrays.all { |a| a.all { |x| predicate(x) } } > > If we use what we currently have in Ruby, this just works, even if there > are some empty lists in the 'arrays' array. With your proposal, we'd have > to write a lot of special code. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Of course I understand that there are other languages which do this the >> same, I also understand that it would break existing code, and I know th= at >> docs are clear, and of course I can write my own, but is it really corre= ct >> behavior to treat undefinedness as truth? In my opinion, no. >> > > It would be incorrect behavior to treat undefinedness as truth, but the > results of these operations are not undefined. They have a clear underlyi= ng > mathematical background. People familiar with this area know what the > results are, and they expect them to work the way they do. Anything else > would be highly confusing for everybody except maybe beginners. > > I suggest you read some introductory book in this area (discrete math). A= n > alternative is to read a book on Haskell, especially one that discusses > code transformations/equivalences and proofs. > > Regards, Martin. > > --047d7b603c14f0435104e306cc48 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Some more explanation reading on the subject - and reasons for this:
http://= en.m.wikipedia.org/wiki/Universal_quantification

http://en.m.wik= ipedia.org/wiki/Vacuous_truth

It's a basic classic logic definition.

On Aug 3, 2013 5:02 AM, Martin J. D=FCrst <duerst@it.aoyama.ac.jp> wrot= e:

On 2013/08/03 15:40, nurettin (Nurettin Onur TUGCU) wrote:

Issue #8723 has been updated by nurettin (Nurettin Onur TUGCU).

I find I need to address all the questions

However I find the result needs not be defined. Also, defining "all?&q= uot; or "any?" makes no sense for empty set since they will never= execute.

You say:

> Also, defining "all?" or "any?" makes no sense for= empty set since they will never execute.

So should be write code like

unless enum.empty?
=A0 =A0enum.all { |x| predicate(x) }
end

Think about this in a bigger context. Assume we are applying .any or .all n= ot to a simple array, but to an array of arrays.

We would e.g. write

arrays.all { |a| a.all { |x| predicate(x) } }

If we use what we currently have in Ruby, this just works, even if there ar= e some empty lists in the 'arrays' array. With your proposal, we= 9;d have to write a lot of special code.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Of course I understand that there are other languages which do this the sam= e, I also understand that it would break existing code, and I know that doc= s are clear, and of course I can write my own, but is it really correct beh= avior to treat undefinedness as truth? In my opinion, no.

It would be incorrect behavior to treat undefinedness as truth, but the res= ults of these operations are not undefined. They have a clear underlying ma= thematical background. People familiar with this area know what the results= are, and they expect them to work the way they do. Anything else would be = highly confusing for everybody except maybe beginners.

I suggest you read some introductory book in this area (discrete math). An = alternative is to read a book on Haskell, especially one that discusses cod= e transformations/equivalences and proofs.

Regards, =A0 Martin.

--047d7b603c14f0435104e306cc48--