compare several boolean matrix’s

[Keivan Jafari]

Den onsdagen den 6:e februari 2013 kl. 18:29:39 UTC+1 skrev Lars Enderin:

2013-02-06 18:14, Keivan Jafari skrev:






I see that you are new (and that you probably are posting from Sweden,

like me). You did reply to me correctly, so you do know how to do it. It

helps to keep message threads consistent. A traditional news client may

have a little trouble otherwise.

Ok!
Now, I go to the match between Argantina and Sweden.

 

[Lars Enderin]

2013-02-06 19:18, lipska the kat skrev:

Den onsdagen den 6:e februari 2013 kl. 18:19:58 UTC+1 skrev lipska the
kat:

On 06/02/13 16:42, Keivan Jafari wrote:

[snip]

I'm too old and busy!
Please stick to the problem, take it as a challenge!

What is it with you Scandinavian types ?

I warned him privately about your possible reaction.
Keivan's name is not Scandinavian, although he lives near Stockholm. I
have no idea how long he's been living in Sweden, maybe his whole life,
but his roots are probably somewhere in the Middle East.

 

[T®oll]

lipska the kat <"nospam at neversurrender dot co dot uk">
blew smoke:
/clipT

You warned him did you ... oh dear, my reputation precedes me :-(

you betcha sweet bippy it does, asshole.

Thank you (I think).

be sure;
http://preview.tinyurl.com/b3ygsjt
or wrapped URL
http://groups.google.com/groups/search?as_q=seamus+derbyshire+kook+twisted&as_
epq=&as_oq=&as_eq=&num=100&scoring=&lr=&as_sitesearch=&as_qdr=&as_mind
=1&as_minm=1&as_miny=2013&as_maxd=1&as_maxm=1&as_maxy=2013&as_
ugroup=&as_usubject=&as_uauthors=&safe=off

lips stuck to Lews ass

sig corrected for all to know, lamer.

 

[Keivan Jafari]

Den onsdagen den 6:e februari 2013 kl. 19:18:04 UTC+1 skrev lipska the kat:

Den onsdagen den 6:e februari 2013 kl. 18:19:58 UTC+1 skrev lipska the kat:

On 06/02/13 16:42, Keivan Jafari wrote:

[snip]



I'm too old and busy!

Please stick to the problem, take it as a challenge!

What is it with you Scandinavian types ?



I'll give you the benefit of the doubt this one time only.



http://pastebin.com/iNpSxjJd



This is a starting point only. There is no error handling

minimal comments and lots of assumptions made.



Eric Sosman also gave you an outline solution upthread.



I have provided you with a simple working solution that you can build

upon. The result matrix is filled with the '1 counts' at each position



The rest is up to you.



lipska



--

Lipska the Kat�: Troll hunter, sandbox destroyer

and farscape dreamer of Aeryn Sun

Tanks man!
I'm trying to create new revolutionary android application allots things tothink about.
I will remember your help.
Sometimes you have so little time!

Br/
Keivan

 

[Keivan Jafari]

Den fredagen den 8:e februari 2013 kl. 20:21:39 UTC+1 skrev Keivan Jafari:

Den onsdagen den 6:e februari 2013 kl. 19:18:04 UTC+1 skrev lipska the kat:

On 06/02/13 17:29, Keivan Jafari wrote:

Den onsdagen den 6:e februari 2013 kl. 18:19:58 UTC+1 skrev lipska the kat:

On 06/02/13 16:42, Keivan Jafari wrote:

[snip]

I'm too old and busy!

Please stick to the problem, take it as a challenge!

What is it with you Scandinavian types ?
I'll give you the benefit of the doubt this one time only.

http://pastebin.com/iNpSxjJd

This is a starting point only. There is no error handling
minimal comments and lots of assumptions made.
Eric Sosman also gave you an outline solution upthread.
I have provided you with a simple working solution that you can build
upon. The result matrix is filled with the '1 counts' at each position
The rest is up to you.

lipska

--
Lipska the Kat�: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun

Tanks man!

I'm trying to create new revolutionary android application allots things to think about.

I will remember your help.

Sometimes you have so little time!



Br/

Keivan

got the help! tanks alots to "lipska the kat"

 

[Keivan Jafari]

Den fredagen den 8:e februari 2013 kl. 20:49:01 UTC+1 skrev lipska the kat:

Den fredagen den 8:e februari 2013 kl. 20:21:39 UTC+1 skrev Keivan Jafari:

Den onsdagen den 6:e februari 2013 kl. 19:18:04 UTC+1 skrev lipska thekat:

On 06/02/13 17:29, Keivan Jafari wrote:

[snip]

Sometimes you have so little time!

Indeed



Because you bothered to respond here's one that works with boolean values



http://pastebin.com/ay5hCBuZ



lipska



--

Lipska the Kat©: Troll hunter, sandbox destroyer

and farscape dreamer of Aeryn Sun

I take my hatt for you "lipska"
this is my last post.

 

[Arne Vajhøj]

some clarification;
Is there any way to compare several boolean matrix’s(25 matrix’s) and bild a new matrix of those 25.

The elements in the new matrix will be, an example:

If matrix M(0) to M(5) element(2, 1) have value false

And if matrix M(6) to M(24) element(2, 1) have value true,
Then most probably the value of element(2, 1) is true, since much more matrix’s shows that element(2, 1) is true

Java code will be mostly appreciated

All the Matrixes have same size
NXM

What is wrong with the trivial double for loop and counting?

Arne

 

[Arne Vajhøj]

I'm trying to create new revolutionary android application allots things to think about.

Sometimes you have so little time!

A revolutionary application and you are stuck in for loops??

Arne

 

[Arne Vajhøj]

Den fredagen den 8:e februari 2013 kl. 20:21:39 UTC+1 skrev Keivan
Jafari:

Den onsdagen den 6:e februari 2013 kl. 19:18:04 UTC+1 skrev lipska
the kat:

On 06/02/13 17:29, Keivan Jafari wrote:

[snip]

Sometimes you have so little time!

Indeed

Because you bothered to respond here's one that works with boolean values

http://pastebin.com/ay5hCBuZ

The code is not too big to post here.

Arne

 

[Arne Vajhøj]

Den fredagen den 8:e februari 2013 kl. 20:21:39 UTC+1 skrev Keivan
Jafari:
Den onsdagen den 6:e februari 2013 kl. 19:18:04 UTC+1 skrev lipska
the kat:

On 06/02/13 17:29, Keivan Jafari wrote:
[snip]


Sometimes you have so little time!

Indeed

Because you bothered to respond here's one that works with boolean values

http://pastebin.com/ay5hCBuZ

The code is not too big to post here.

And the code is OK.

I would have done a few things differently, but ...

Arne

====

public class MatrixSummarize {
public static boolean[][] summarize(boolean[][][] matrices) {
assert matrices.length % 2 == 1 : "Number of matrices must be odd";
int majority = (matrices.length + 1) / 2;
boolean[][] result = new
boolean[matrices[0].length][matrices[0][0].length];
for(int i = 0; i < result.length; i++) {
for(int j = 0; j < result.length; j++) {
int ntrue = 0;
for(int k = 0; k < matrices.length; k++) {
if(matrices[k][j]) ntrue++;
if(ntrue >= majority) {
result[j] = true;
break;
} else if(k + 1 - ntrue >= majority) {
break;
}
}
}
}
return result;
}
public static void print(boolean[][] result) {
for(int i = 0; i < result.length; i++) {
for(int j = 0; j < result.length; j++) {
System.out.printf(" %-5b", result[j]);
}
System.out.println();
}
}
public static void main(String[] args){
boolean [][] matrix1 = {
{ true, true, false },
{ true, false, true },
{false, true, false }
};
boolean [][] matrix2 = {
{ false, true, false },
{ true, false, false },
{ false, true, false }
};
boolean [][] matrix3 = {
{ true, false, true },
{ true, false, false },
{ false, true, false }
};
boolean[][][] matrices = { matrix1, matrix2, matrix3 };
boolean[][] result = summarize(matrices);
print(result);
}
}

 

[Lew]

I would have done a few things differently, but ...

public class MatrixSummarize {
public static boolean[][] summarize(boolean[][][] matrices) {
assert matrices.length % 2 == 1 : "Number of matrices must be odd";

Nitpicks: Some details that separate pedagogy from production.

Arne's code is very good, and proper for instruction. However, if it were
to serve in production there is more to do.

This is an improper use of 'assert' because there is no code to
enforce the invariant. Properly, there should be argument-checking prior to
the assertion so that it represents an actual invariant.

There's no check for a null argument. One could assert non-nullity after
the check.

By dropping the 'assert' in here like this, Arne has presented a secret
challenge to fill in the gaps, as anyone schooled in the use of 'assert'
might have noticed.

 

[Lew]

I would have done a few things differently, but ...

public class MatrixSummarize {
public static boolean[][] summarize(boolean[][][] matrices) {
assert matrices.length % 2 == 1 : "Number of matrices must be odd";

Nitpicks: Some details that separate pedagogy from production.

Arne's code is very good, and proper for instruction. However, if it were
to serve in production there is more to do.

This is an improper use of 'assert' because there is no code to
enforce the invariant. Properly, there should be argument-checking priorto
the assertion so that it represents an actual invariant.

There's no check for a null argument. One could assert non-nullity after
the check.

By dropping the 'assert' in here like this, Arne has presented a secret
challenge to fill in the gaps, as anyone schooled in the use of 'assert'
might have noticed.

I am not that advanced.

Passing null, passing arrays with wrong dimensions etc. will all
give various exceptions.

The odd number requirement will not give an exception if violated.

So I flipped a coin (virtually) between an if throw new
RuntimeException and the assert. Assert won.

It's not a coin flip. They aren't equivalent. This is well known in Java,
as 'assert' has been around since Java 1.4.

Assertions are more runtime comments than code. They do you no good when
disabled. Exceptions cannot be suppressed.

Assertions are not even slightly meant for argument checking of public
methods.

That's the job of exceptions.

Assertions come in after the exception, or in private methods, to document
and enforce invariants for programmers. For example, a getter method that
expects the private member to be non-null can assert non-nullity. Only
something under complete control of the implementation, i.e., the private
member, is involved, so it's time for 'assert'.

When it's a public method you don't have that control. So you start with
a runtime check. Once that check is complete, i.e., either the method has returned, thrown an exception, or continued to where supposedly you've just
guaranteed non-nullity, if you are still in the method it is safe to
assert non-nullity.

public void checkArgumentsThenAssert(Foo foo, Bar bar)
{
/* It doesn't make sense to assert non-nullity here because you
* simply do not have that guarantee.
*/
if (foo == null || bar == null)
{
throw new IllegalArgumentException("Null argument");
}
/* NOW you have the guarantee. It would take a code mistake to mess up. */
assert foo != null && bar != null : "There was a code mistake";
}

A quick Google will reveal the expert wisdom on the subject.

http://lmgtfy.com/?q=java+assert
http://docs.oracle.com/javase/1.4.2/docs/guide/lang/assert.html
"There are also a few situations where you should not use them:

"Do not use assertions for argument checking in public methods."
....

"Do not use assertions to do any work that your application requires for
correct operation."

 

[Arne Vajhøj]

Arne Vajhøj wrote:
I would have done a few things differently, but ...

public class MatrixSummarize {
public static boolean[][] summarize(boolean[][][] matrices) {
assert matrices.length % 2 == 1 : "Number of matrices must be odd";

Nitpicks: Some details that separate pedagogy from production.

Arne's code is very good, and proper for instruction. However, if it were
to serve in production there is more to do.

This is an improper use of 'assert' because there is no code to
enforce the invariant. Properly, there should be argument-checking prior to
the assertion so that it represents an actual invariant.

There's no check for a null argument. One could assert non-nullity after
the check.

By dropping the 'assert' in here like this, Arne has presented a secret
challenge to fill in the gaps, as anyone schooled in the use of 'assert'
might have noticed.

I am not that advanced.

Passing null, passing arrays with wrong dimensions etc. will all
give various exceptions.

The odd number requirement will not give an exception if violated.

So I flipped a coin (virtually) between an if throw new
RuntimeException and the assert. Assert won.

It's not a coin flip. They aren't equivalent. This is well known in Java,
as 'assert' has been around since Java 1.4.

Assertions are more runtime comments than code. They do you no good when
disabled. Exceptions cannot be suppressed.

Assertions are not even slightly meant for argument checking of public
methods.

That's the job of exceptions.

Assertions come in after the exception, or in private methods, to document
and enforce invariants for programmers. For example, a getter method that
expects the private member to be non-null can assert non-nullity. Only
something under complete control of the implementation, i.e., the private
member, is involved, so it's time for 'assert'.

When it's a public method you don't have that control. So you start with
a runtime check. Once that check is complete, i.e., either the method has returned, thrown an exception, or continued to where supposedly you've just
guaranteed non-nullity, if you are still in the method it is safe to
assert non-nullity.

A quick Google will reveal the expert wisdom on the subject.

http://lmgtfy.com/?q=java+assert
http://docs.oracle.com/javase/1.4.2/docs/guide/lang/assert.html
"There are also a few situations where you should not use them:

"Do not use assertions for argument checking in public methods."
...

"Do not use assertions to do any work that your application requires for
correct operation."

Or maybe the method should just have been private instead of public.

Arne