Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #17644 > unrolled thread

hashCode

Back to article view | Back to comp.lang.java.programmer

Contents

  hashCode "bob smith" <bob.smith@1:261/38.remove-t9h-this> - 2012-08-10 18:39 +0000
    Re: hashCode "Arne Vajhøj" <arne.vajhøj@1:261/38.remove-t9h-this> - 2012-08-10 18:39 +0000
      Re: hashCode "markspace" <markspace@1:261/38.remove-t9h-this> - 2012-08-10 18:39 +0000
        Re: hashCode "Arne Vajhøj" <arne.vajhøj@1:261/38.remove-t9h-this> - 2012-08-10 18:39 +0000
          Re: hashCode "rossum" <rossum@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
    Re: hashCode "Eric Sosman" <eric.sosman@1:261/38.remove-t9h-this> - 2012-08-10 18:39 +0000
      Re: hashCode "bob smith" <bob.smith@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
        Re: hashCode "Lew" <lew@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
          Re: hashCode "Arne Vajhøj" <arne.vajhøj@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
            Re: hashCode "Lew" <lew@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
              Re: hashCode "Arne Vajhøj" <������
høj@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
                Re: hashCode "Arne Vajhøj" <������
høj@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
                  Re: hashCode "Eric Sosman" <eric.sosman@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
                    Re: hashCode "Arne Vajhøj" <������
høj@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
        Re: hashCode "Eric Sosman" <eric.sosman@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
          Re: hashCode "Lew" <lew@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
            Re: hashCode "Arne Vajhøj" <������
høj@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
        Re: hashCode "Arne Vajhøj" <arne.vajhøj@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
          Re: hashCode "Robert Klemme" <robert.klemme@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
            Re: hashCode "Arne Vajhøj" <arne.vajhøj@1:261/38.remove-nlb-this> - 2012-08-13 18:36 +0000
              Re: hashCode "Robert Klemme" <robert.klemme@1:261/38.remove-nlb-this> - 2012-08-13 18:36 +0000
                Re: hashCode "Arne Vajhøj" <arne.vajhøj@1:261/38.remove-fzq-this> - 2012-08-20 18:58 +0000
                Re: hashCode "Arne Vajhøj" <arne.vajhøj@1:261/38.remove-fzq-this> - 2012-08-20 18:58 +0000
        Re: hashCode "Patricia Shanahan" <patricia.shanahan@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
        Re: hashCode "Joshua Cranmer" <joshua.cranmer@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
          Re: hashCode "Patricia Shanahan" <patricia.shanahan@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
            Re: hashCode "Eric Sosman" <eric.sosman@1:261/38.remove-6fd-this> - 2012-08-12 20:00 +0000
              Re: hashCode "Patricia Shanahan" <patricia.shanahan@1:261/38.remove-6fd-this> - 2012-08-12 20:00 +0000
            Re: hashCode "Arne Vajhøj" <������
høj@1:261/38.remove-nlb-this> - 2012-08-13 18:36 +0000
          Re: hashCode "Jan Burse" <jan.burse@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
    Re: hashCode "Roedy Green" <roedy.green@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
      Re: hashCode "Lew" <lew@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
        Re: hashCode "Roedy Green" <roedy.green@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
          Re: hashCode "Joerg Meier" <joerg.meier@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
            Re: hashCode "Mike Winter" <mike.winter@1:261/38.remove-ya-this> - 2012-08-11 19:19 +0000
          Re: hashCode "Peter Duniho" <peter.duniho@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
          Re: hashCode "Jan Burse" <jan.burse@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
          Re: hashCode "Arne Vajhøj" <arne.vajhøj@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
        Re: hashCode "rossum" <rossum@1:261/38.remove-ya-this> - 2012-08-11 19:19 +0000
      Re: hashCode "Arne Vajhøj" <arne.vajhøj@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
        Re: hashCode "Eric Sosman" <eric.sosman@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
          Re: hashCode "Arne Vajhøj" <arne.vajhøj@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
    Re: hashCode "Jan Burse" <jan.burse@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
      Re: hashCode "Jan Burse" <jan.burse@1:261/38.remove-pjg-this> - 2012-08-11 18:17 +0000
      Re: hashCode "Lew" <lew@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
        Re: hashCode "Lew" <lew@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
        Re: hashCode "Arne Vajhøj" <������
høj@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
          Re: hashCode "Lew" <lew@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
      Re: hashCode "Jan Burse" <jan.burse@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
        Re: hashCode "Jan Burse" <jan.burse@1:261/38.remove-m2z-this> - 2012-08-12 18:58 +0000
        Re: hashCode "Lew" <lew@1:261/38.remove-6fd-this> - 2012-08-12 20:00 +0000
          Re: hashCode "Arne Vajhøj" <������
høj@1:261/38.remove-nlb-this> - 2012-08-13 18:36 +0000

Page 3 of 3 — ← Prev page 1 2 [3]

#17705

  To: Arne Vajhøj
From: Eric Sosman <esosman@ieee-dot-org.invalid>

On 8/10/2012 7:25 PM, Arne Vajhoj wrote:
> On 8/10/2012 3:17 PM, Roedy Green wrote:
>> On Fri, 10 Aug 2012 08:47:12 -0700 (PDT), bob smith
>> <bob@coolfone.comze.com> wrote, quoted or indirectly quoted someone
>> who said :
>>
>>>     @Override
>>>     public int hashCode() {
>>>         return 1;
>>>     }
>>
>> that's about the worst possible hashCode function.
>
> Yes, but the posted asked "Is it always technically correct to ..."
> not whether is was "best possible".

     He also asked whether it would "be potentially better."

--
Eric Sosman
esosman@ieee-dot-org.invalid

--- BBBS/Li6 v4.10 Dada-1
 * Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#17708

  To: Eric Sosman
From: Arne Vajhoj <arne@vajhoej.dk>

On 8/11/2012 8:00 AM, Eric Sosman wrote:
> On 8/10/2012 7:25 PM, Arne Vajhoj wrote:
>> On 8/10/2012 3:17 PM, Roedy Green wrote:
>>> On Fri, 10 Aug 2012 08:47:12 -0700 (PDT), bob smith
>>> <bob@coolfone.comze.com> wrote, quoted or indirectly quoted someone
>>> who said :
>>>
>>>>     @Override
>>>>     public int hashCode() {
>>>>         return 1;
>>>>     }
>>>
>>> that's about the worst possible hashCode function.
>>
>> Yes, but the posted asked "Is it always technically correct to ..."
>> not whether is was "best possible".
>
>      He also asked whether it would "be potentially better."

"better to use Object hashCode" which again should bring the correctness 
question before the performance question.

Arne

--- BBBS/Li6 v4.10 Dada-1
 * Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#17706

  To: bob smith
From: Jan Burse <janburse@fastmail.fm>

bob smith schrieb:
> Is it always technically correct to override the hashCode function like so:
>
>       @Override
>       public int hashCode() {
>               return 1;
>       }
>
> Would it be potentially better if that was Object's implementation?
>

Maybe it would make sense to spell out what the contract for hashCode() is. 
Well the contract is simply, the following invariant should hold:

    /* invariant that should hold */
    if a.equals(b) then a.hashCode()==b.hashCode()

It should be noted that this does not imply:

    /* not implied and thus not required by the invariant */
    if a.hashCode()==b.hashCode() then a.equals(b)

It is also quite unlikely that a hashCode() would satisfy the later, although 
the closer it comes to the later, the better it works for HashMap, etc..

The default objects implementation of hashCode() matches the default objects 
impementation of equals(). The default objcts implementation of equals() is ==. 
And the default objects implementation of hashCode() is 
System.identityHashCode().

The System identity hash code is stored in the object and generated by the 
system. It does not change during GC although the internal object address might 
change during GC. It is only 32bit although internal object addresses might by 
64bit with a corresponding JVM.

Returning a constant, any constant c not only 1, would be technically correct 
correct for the default implementation of the class object. Since it trivially 
satisfies the invariant:

     if a.equals(b) then c==c

is trivially true, since c==c is true. But it is not better. Since you would 
get very degenerated HashMaps, etc..

You need to override the hashhCode() when there is danger that the invariant is 
not anymore satisified. This is not the case when equals() is not overridden. 
So overriding hashCode() just for fun when equals() is not overriden, usually 
doesn't make sense. It will probably only slow down the hashCode() calculation. 
So the following:

     hashCode() = sum attr_i * c^i

Is not necessary. But it would be a possible way to go when equals() were 
overriden in the following way:

    equals(other) = and_i attr_i.equals(other.attr_i)

The above happens when you turn your object into a container of other objects 
irrespective of the own object identity. But beware if the container contains 
itself somewhere. This is why we find in the code for Hashtable the following 
complication:

     public synchronized int hashCode() {
     /*
      * This code detects the recursion caused by computing the hash code
      * of a self-referential hash table and prevents the stack overflow
      * that would otherwise result.  This allows certain 1.1-era
      * applets with self-referential hash tables to work.  This code
      * abuses the loadFactor field to do double-duty as a hashCode
      * in progress flag, so as not to worsen the space performance.
      * A negative load factor indicates that hash code computation is
      * in progress.
      */

Interestingly it will return a constant for the object when it detects a loop. 
Maybe one could do better... Dunno

Bye

--- BBBS/Li6 v4.10 Dada-1
 * Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#17707

  To: Jan Burse
From: Jan Burse <janburse@fastmail.fm>

Jan Burse schrieb:
> during GC. It is only 32bit although internal object
> addresses might by 64bit with a corresponding JVM.

Typically even less bits, since the same space is used for some object flags.

--- BBBS/Li6 v4.10 Dada-1
 * Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#17742

  To: Jan Burse
From: Lew <noone@lewscanon.com>

Jan Burse wrote:
> Maybe it would make sense to spell out what the contract
> for hashCode() is. Well the contract is simply, the
> following invariant should hold:
>
>     /* invariant that should hold */
>     if a.equals(b) then a.hashCode()==b.hashCode()

True, but if you read the specification for 'hashCode()' fully, that is not the 
entire contract, only the compiler-enforceable part of it.

The entire specification requires that as much as feasible, the 'Object' 
implementation distinguish distinct instances, and that the method generally 
support 'HashMap', which promises O(1) 'get()' and 'put()' with a "proper" 
(i.e., compliant) 'hashCode()'.

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

--- BBBS/Li6 v4.10 Dada-1
 * Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#17743

  To: Lew
From: Lew <noone@lewscanon.com>

Lew wrote:
> Jan Burse wrote:
>> Maybe it would make sense to spell out what the contract
>> for hashCode() is. Well the contract is simply, the
>> following invariant should hold:
>>
>>     /* invariant that should hold */
>>     if a.equals(b) then a.hashCode()==b.hashCode()
>
> True, but if you read the specification for 'hashCode()' fully, that is not
> the entire contract, only the compiler-enforceable part of it.

Oooops!

I made a mistake.

Not even that is compiler-enforceable.

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

--- BBBS/Li6 v4.10 Dada-1
 * Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#17747

  To: Lew
From: =?UTF-8?B?QXJuZSBWYWpow7hq?= <arne@vajhoej.dk>

On 8/11/2012 7:34 PM, Lew wrote:
> Jan Burse wrote:
>> Maybe it would make sense to spell out what the contract
>> for hashCode() is. Well the contract is simply, the
>> following invariant should hold:
>>
>>     /* invariant that should hold */
>>     if a.equals(b) then a.hashCode()==b.hashCode()
>
> True, but if you read the specification for 'hashCode()' fully, that is
> not the entire contract, only the compiler-enforceable part of it.
>
> The entire specification requires that as much as feasible, the 'Object'
> implementation distinguish distinct instances, and that the method
> generally support 'HashMap', which promises O(1) 'get()' and 'put()'
> with a "proper" (i.e., compliant) 'hashCode()'.

Two wrong statements.

It says that the method is defined to support HashMap

And HashMap does not guarantee O(1) with a correct hashCode - it guarantee that 
for one that return good distributed values.

Arne

--- BBBS/Li6 v4.10 Dada-1
 * Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#17753

  To: =?UTF-8?B?QXJuZSBWYWpow7hq?=
From: Lew <noone@lewscanon.com>

Arne Vajh-,j wrote:
> Lew wrote:
>> Jan Burse wrote:
>>> Maybe it would make sense to spell out what the contract
>>> for hashCode() is. Well the contract is simply, the
>>> following invariant should hold:
>>>
>>>     /* invariant that should hold */
>>>     if a.equals(b) then a.hashCode()==b.hashCode()
>>
>> True, but if you read the specification for 'hashCode()' fully, that is
>> not the entire contract, only the compiler-enforceable part of it.
>>
>> The entire specification requires that as much as feasible, the 'Object'
>> implementation distinguish distinct instances, and that the method
>> generally support 'HashMap', which promises O(1) 'get()' and 'put()'
>> with a "proper" (i.e., compliant) 'hashCode()'.
>
> Two wrong statements.
>
> It says that the method is defined to support HashMap
>
> And HashMap does not guarantee O(1) with a correct
> hashCode - it guarantee that for one that return
> good distributed values.

Granted.

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

--- BBBS/Li6 v4.10 Dada-1
 * Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#17754

  To: Jan Burse
From: Jan Burse <janburse@fastmail.fm>

Jan Burse schrieb:
> Maybe it would make sense to spell out what the contract
> for hashCode() is.

Those who are interested can read the original text. It is found here:

http://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#hashCode%28%29

---------------------------------------------------------------

        "If two objects are equal according to the equals(Object)
        method, then calling the hashCode method on each of the
        two objects must produce the same integer result."

That is:

    /* invariant that should hold */
    if a.equals(b) then a.hashCode()==b.hashCode()

----------------------------------------------------------------

        "It is not required that if two objects are unequal according
        to the equals(java.lang.Object) method, then calling the
        hashCode method on each of the two objects must produce
        distinct integer results. However, the programmer should be
        aware that producing distinct integer results for unequal
        objects may improve the performance of hash tables."

That is:

    /* not implied and thus not required by the invariant */
    if a.hashCode()==b.hashCode() then a.equals(b)

It is also quite unlikely that a hashCode() would satisfy the later, although 
the closer it comes to the later, the better it works for HashMap, etc..

----------------------------------------------------------------

There is no reference to Comparable and the compareTo. If I am not using 
HashMap or HashSet in my application, and still override equals, I do not need 
to implement hashCode(). I could for example use TreeMap or TreeSet and 
implement the Comparable interface. There is a reference to equals() back from 
Comparable though.

http://docs.oracle.com/javase/6/docs/api/java/lang/Comparable.html

Bye

--- BBBS/Li6 v4.10 Dada-1
 * Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#17755

  To: Jan Burse
From: Jan Burse <janburse@fastmail.fm>

Jan Burse schrieb:
>     /* not implied and thus not required by the invariant */
>     if a.hashCode()==b.hashCode() then a.equals(b)
This is logically equivalent to what is formulated in the Javadoc by the so 
called contraposition:

        if !a.equals(b) then a.hashCode()!=b.hashCode()

http://en.wikipedia.org/wiki/Contraposition

--- BBBS/Li6 v4.10 Dada-1
 * Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#17763

  To: Jan Burse
From: Lew <noone@lewscanon.com>

Jan Burse wrote:
> There is no reference to Comparable and the compareTo. If I am not

True.

> using HashMap or HashSet in my application, and still override
> equals, I do not need to implement hashCode(). I could for example

True.

> use TreeMap or TreeSet and implement the Comparable interface. There
> is a reference to equals() back from Comparable though.

This requires a detailed knowledge of the implementation of the particular
'Map' or 'Set'. If its searches do not employ hash codes, then you do not need
to implement 'hashCode()' for value-equal types.

In the general case one prefers to underspecify the mechanics, that is, allow a 
client of the type to deploy either 'equals()'-based or hash-based algorithms, 
by ensuring the methods are consistent with each other per Joshua Bloch and 
other notables.

> http://docs.oracle.com/javase/6/docs/api/java/lang/Comparable.html

Even for cases where one predicts the use will not require one or another of 
the consistency practices, it is harmless to enforce them.

There are four methods a type might use to represent equality or identity and 
deviations therefrom: 'equals()' of course, and 'hashCode()', 'compareTo()', 
and 'toString()'. There may be external 'Comparator's on that type.

All these methods on or of a type, where they exist, should be consistent, 
absent an overwhelming and sound reason not to be.

The default case from 'Object' is that 'equals()' implements ==, 'hashCode()' 
returns something sort of like an address of the instance which is nearly 
always unique within a given JVM run, 'toString()' returns a decorated string 
version of the hash code, and 'compareTo()' doesn't exist.

To express value equality in a type, one must override 'equals()'. The rest are 
optional in Arne's strictest and most correct use of that notion. It is also 
harmless to keep the rest consistent and nearly always (as in you might 
encounter one instance per career otherwise) useful.

One generally chooses 'TreeMap' for its sorting capability, not its reliance on 
'equals()' vs. 'hashCode()' to achieve that. (Assuming it has such a reliance.) 
Unless there's a compelling argument to rely on 'TreeMap''s undocumented 
non-use of hash codes, why do so?

Yes, I am aware that the 'TreeMap' documentation makes it clear that
'hashCode()' shouldn't be involved. Without promising it isn't. But a
'Comparator' might use hash codes under the hood in a naive attempt to
shortcut a comparison, not knowing that the base type assumes no one would do 
such a thing. Or some later client might need only equality and not order, and 
throw the base type into a 'HashMap' with surprising results.

Should you design anything that violates the consistency rule, then please do 
both Javadoc and code-comment it properly.

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

--- BBBS/Li6 v4.10 Dada-1
 * Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#17813

  To: Lew
From: =?UTF-8?B?QXJuZSBWYWpow7hq?= <arne@vajhoej.dk>

On 8/12/2012 2:27 PM, Lew wrote:
> Even for cases where one predicts the use will not require one or
> another of the consistency practices, it is harmless to enforce them.
>
> There are four methods a type might use to represent equality or
> identity and deviations therefrom: 'equals()' of course, and
> 'hashCode()', 'compareTo()', and 'toString()'. There may be external
> 'Comparator's on that type.
>
> All these methods on or of a type, where they exist, should be
> consistent, absent an overwhelming and sound reason not to be.

> Should you design anything that violates the consistency rule, then
> please do both Javadoc and code-comment it properly.

I agree.

(well toString is not high on my priority list for what needs to behave certain 
ways, but ...)

To make it easier to get them consistent, then I think it would be nice with 
syntactic sugar.

Like:

public class Data {
     @ValueId
     private int iv;
     @ValueId
     private String sv;
     // the rest of the class
}

which would cause the compiler to emit equals and hashCode methods that are 
test of the @ValueId fields are equal and creates a "decent" hash.

public class Data implements Comparable<Data> {
     @ValueId
     private int iv;
     @ValueId
     private String sv;
     // the rest of the class
}

could cause the compiler to output a compareTo as well.

It is invisible code, but we already got that with the default constructor.

And it will help make those methods consistent.

Of course explicit override should still be possible.

Arne

--- BBBS/Li6 v4.10 Dada-1
 * Origin: Prism bbs (1:261/38)
--- Synchronet 3.16a-Win32 NewsLink 1.98
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.java.programmer

csiph-web