Discussing Portable MP3 players is a taboo

I was a user of a cheap MP3 player, which had a major flaw

1. It stopped playing as soon as I plug the USB charging cable into it
2. I lost the track when I unplug the cable and start the device again. It starts from the beginning instead of last position.

Can you imagine the crap? I have rushed through all electronic shops in our city, asking if more high-end players are free of it, can it play while on USB line and remember their last position? All service person answer either "no" or "I do not know".

So, obviously, you move on the internet specialized sites for the consumer electronic advises. Because I have no idea which keywords ask from google and fail. I added the support for accelerated/variable speed playback into my request. And, what do you think? My question is always deleted! This is a taboo question. In consumer-electronics.stackexchange (there was such specialzed site for a while) particularly, they closed under contrived pretext that I have to google myself first. Asking the dick to show me how to google for that, has he made any attempt to google himself to tell me that my request can be found in google in couple of clicks the dick just became more aggressive and got some support from other dicks that own the site and mock you with all kind of nonsense there.

Later, a similar situation occured to me at hardware-advises.stackexchange.com when I asked for a wired USB keybard with touchpad. People are full of shit. They create discussion forums in order to not let you to speak, Q&A to stop the question from being asked in the first place.

Why java Set does not have get() method?

I have mentioned the same simple question in StackOverflow that I asked many years ago in sun.java.form that was one of the reasons to ban be there. I have my considerations.
http://stackoverflow.com/a/9299534/1083704

I had the same question in java forum years ago. They told me that the Set interface is defined. It cannot be changed because it will break the current implementations of Set interface. Then, they started to claim bullshit, like you see here: "Set does not need the get method" and started to drill me that Map must always be used to get elements from a set.
If you use the set only for mathematical operations, like intersection or union, then may be contains() is sufficient. However, Set is defined in collections to store data. I explained for need get() in Set using the relational data model.
In what follows, an SQL table is like a class. The columns define attributes (known as fields in Java) and records represent instances of the class. So that an object is a vector of fields. Some of the fields are primary keys. They define uniqueness of the object. This is what you do for contains() in Java:

class Element {

        public int hashCode() {return sumOfKeyFields()}
        public boolean equals(Object e) {keyField1.equals(e) && keyField2.equals(e) && ..}

I'm not aware of DB internals. But, you specify key fields only once, when define a table. You just annotate key fields with @primary. You do not specify the keys second time, when add a record to the table. You do not separate keys from data, as you do in mapping. SQL tables are sets. They are not maps. Yet, they provide get() in addition to maintaining uniqueness and contains() check.
You see how they say that Set with get would be redundant? It is because their favorite map, which they impose to use in place of set, introduces the redundancy. The call put(obj.getKey(), obj) stores two keys: one for map key and duplicate as part of the object. This is the redundancy. The duplication involves more bloat in the code and wastes memory consumed at Runtime. I do not know about DB internals, but database normalization says that such duplication is bad idea. Redundancy means that it may happen that key in the map does not match the key of the referred object. The contradictions are a prominent mark of redundancy. Edgar F. Codd proposed DB normalization just to get rid of redundancies and their inferred inconsistencies.
So, we have 3 points, why using a map for implementing get in set is bad:

1. redundancy in Runtime storage
2. code bloat
3. data storage normalization

I was banned from Sun forum for pointing this out. This world is dominated by bigots. They do not want to see concepts and how things can be improved. They see only actual world and cannot imagine that design of Collections may be different or is missing something. It is dangerous to remind rationale things to such people. They teach you their blindness and punish if you do not obey.

Duplicate of http://valjok.blogspot.com/2008/05/java-design-map-vs-setgetkey.html

Finally, I have discovered where normalization is specific on the topic: Normalization will never generate two tables with a one-to-one relationship between them. There is no theoretical reason to separate a single entity like this with some fields in a single record of one table and others in a single record of another table

60 arcminutes must equal to 15° rather than 1°

Thesis: I believe that defining 1°= 60 mins is a mistake. Instead, 60 mins must equal to 15°.
Proof: One angular hour = 60 angular minutes = 1° or 1/360 of turnaround. Meantime, a normal clock turnaround is 24 hours. So, 1 hour is 360/24 degrees = 15°. That is the correct value: one hour = 60 angular minutes must equal to 15 degrees, not 1 deg.