Prashant Mumbarkar

Greenhorn
+ Follow
since Apr 28, 2014
Prashant likes ...
Hibernate Spring Java
Merit badge: grant badges
Biography
Looking For Java Fresher Job In Pune
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
6
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Prashant Mumbarkar

Bear Bibeault wrote:

Prashant Mumbarkar wrote:So I was wondering what technology/language we can use to bypass Google's algorithm if it is at all possible or at least we can help to rank our website significantly higher in search.


(a) Even if this were possible, does this not strike you at all as unethical?

(b) If it were possible, do you not think that everyone would be doing it? And then what would be the point?



It would like finding a bug in the system. I know it will be really difficult to do but you never know. If someone can challenge Google then she/he has to be genius of some kind. And regarding unethicality , we will always have different views like hacking.
9 years ago
Today I was surfing through the net when I found one article which talks about how Google makes frequent update to its search algorithm and how different sites get affected because of it.

So I was wondering what technology/language we can use to bypass Google's algorithm if it is at all possible or at least we can help to rank our website significantly higher in search.

One more question I have in mind and would like to know what Ranchers think about it is over the period of time has Google improved it's search algorithm's quality as far as user experience is concerned or not?
9 years ago

Jesper de Jong wrote:Remember the rule that hashCode() and equals() have to follow:

If two objects A and B are equal (calling A.equals(B) and B.equals(A) returns true), then their hash codes must be the same (A.hashCode() == B.hashCode()).

(If the equals() and hashCode() methods of the class of A and B don't follow that rule, then they are implemented incorrectly).

Note that the rule only works one way: it does not mean that if A and B are not equal, their hash codes must be different - they can still be the same.

Now, think about what it means. It means that if you have two objects A and B, and you compare their hash codes, and you find that their hash codes are different, then you can be sure that A and B are not equal. (Because if they are equal, their hash codes must be the same). So, HashMap doesn't always have to call equals() to know that two objects are different - when it sees that the hash codes are different, it already knows the objects are different, and it doesn't need to call equals().



I completely agree with you...


Then as per that logic if A & B are having same hascodes then it should check for their equals method to see if they are matching or not. And this is what I expect in second case of my problem .But in result if you see it has stopped at hashcodes even though hashcodes are same ( King and Dean are of same length) .I think as per rule it should have gone to equals to do the check further & then it should have come with output null as (King!=Dean).
9 years ago
Thanks Campbell for your comment


now I have this correct version of equals method.

I agree that earlier equals method was not correct but I beg to differ you on unpredictability of display statements in it. My view is if it's method then no matter what it returns we can include display statements to see how actual flow is happening.

Now coming back to question I have for below code



Now output is

I am in hashSam
I am in equal Sam
D1
I am in hashDean
D2

Hence my question remains open : why is it not using equals method in second case & if it had then the output of search would have been null,rite?

9 years ago

Matthew Brown wrote:The last one you are looking up with exactly the same key as it was added - the same object. So even the non-overridden versions of equals() will return true and hashCode() will return the same value.


Thanks Matthew.
Now I have this doubt.

I used display statement in equals to see if this code is executed or not.



now in the same code earlier I made change like this



Output is like this:

I am in hash Dean
D2

My question is why didn't it execute equal method? .Had it been executed ,then the output would have been null not D1 because Dean !=Roy5. Any thought on this please?
9 years ago
Oops ...Apology for typo..

now output is D1 D2 null M2

but last one it should produce null rite? ( As Man has not overrode equals & hashCode methods)
9 years ago
I am trying run below code






I was expecting output like D1 D2 null null (of course in different lines) as Man has not overrode equal & hashCode method

but output is like null D2 null M2 . Now I have no clue about this. Any idea how this works?
9 years ago

Rob Spoor wrote:
Don't ever do that unless you are certain that you won't get overflow. Suppose this.moofValue is Integer MIN_VALUE and otherMoof.moofValue is 1. The result will be Integer.MAX_VALUE, not a negative value. If you ever need to compare two ints, use Integer.compare(x, y). Likewise for Long, Float and Double. For byte, char and short (where overflow won't happen) you can choose between simple subtraction and using the static compare method (the static methods use simple subtraction).




for first return output is [-2147483648 Apple, -10 Facebook, 1 Google, 10 Twitter, 2147483647 Amazon] Expected
for second return output is [1 Google, 10 Twitter, 2147483647 Amazon, -2147483648 Apple, -10 Facebook] Not Expected
For third return output is [-2147483648 Apple, -10 Facebook, 1 Google, 10 Twitter, 2147483647 Amazon] Expected

This shows that simple subtraction is indeed risky affair.
Though one thing I didn't understand is why overflow will not happen for bye, short & char? What's the reason ?
9 years ago
@ Tony : Sure. I will do.

@Piet:

Now I got what you were trying to say. Thanks for showing different possibility.
9 years ago
full code is :


9 years ago
The reason for overriding compareTo method is I want to sort ArrayList of Moof objects by using Collections.Sort(List list) method.
9 years ago

Piet Souris wrote:correct!

but, with Henry:

3) ... // how would you determine which of two int's is the bigger one?

Greetz,
Piet



I think comapareTo is doing the same or I didn't understand the question.
9 years ago
hmm.... got it now.

I forgot the basic rule which K&B has said to burn it in head: Everything in Java is Object except primitive !

Thanks Henry & Piet for reminding it.

Two ways to fix:

1)private Integer moofValue;
OR
2)return ((Integer)moofValue).compareTo(d.getMoofValue());

9 years ago
I am trying to compile below code:


I thought about it but no luck. Can anyone help me please?
9 years ago