Also that is just another case of bad naming. According to the order on
Doubles, the minimum is not what the JDK claims. That static should
clearly be called MIN_POS_VALUE or maybe even MINIMUM_POSITIVE_VALUE or
SMALLEST_REPRESENTABLE_POSITIVE_VALUE :-)
BTW: What is the actual use for that field? I honestly don't know what I
would use it for.
Peter
Casper Bang wrote:
> True. Semantics can be a tricky one. For instance, the output of the
> following is surprising to many:
>
> System.out.println( max(0.0, -1.0, -2.0) );
>
> public static double max(double... candidates)
> {
> assert(candidates.length > 0);
> double knownMaxValue = Double.MIN_VALUE;
> for(double candidate : candidates)
> if(candidate > knownMaxValue)
> knownMaxValue = candidate;
> return knownMaxValue;
> }
>
> /Casper
>
> On Nov 14, 10:57 pm, Peter Becker <[email protected]> wrote:
>
>> Brian Leathem wrote:
>>
>>> On Nov 13, 8:38 am, Kevin Wright <[email protected]>
>>> wrote:
>>>
>>>> On Fri, Nov 13, 2009 at 4:34 PM, Alexey <[email protected]> wrote:
>>>>
>>>>> Otherwise, doesn't seem too difficult to write your own such method,
>>>>> no?
>>>>>
>>> It is indeed trivial to write my own method. I could then package
>>> that method along with other such methods in a "toolbox" jar that I
>>> include with all my projects. It just strikes me that in the general
>>> case it's not good if everyone does this, as one will have to learn a
>>> new toolbox API every time one joins a new project. I don't have the
>>> experience of working in many organizations, or on a diverse set of
>>> projects, but are such toolboxes common? Is there much overlap
>>> amongst these toolboxes that people have seen?
>>>
>>> Granted I'm blowing things somewhat out of proportion with just this
>>> one method. I was just curious if anyone else had a "standardized"
>>> way of dealing with this one.
>>>
>> There is a little problem with the idea of a generic maximum function on
>> Comparables: the maximum is not necessarily defined. Let's say we sort
>> people by age: chances are that you will encounter two people with the
>> same age. In mathematical terms that means that they are in the same
>> equivalence class, which means neither of them is considered larger than
>> the other. Declaring one of them the maximum would not be correct and in
>> fact the proposed implementation would not be symmetrical: depending on
>> the order of the parameters you get different results.
>>
>> One way out would be to actually not use the original order, but a more
>> fine-grained one falling back to something like the system hashcode as
>> secondary order, i.e. if the comparator/comparable returns "0", then we
>> compare the references. But that's not really good either since the
>> semantics are then dependent on the references -- we get into problems
>> with multiple references to the same object as well as multiple runs of
>> the program being inconsistent.
>>
>> The only correct solution IMO would be to extend Comparator/Comparable
>> by something that is explicitly antisymmetric, i.e. a total order. That
>> then could have a maximum function that would be well-defined.
>>
>> Peter
>>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
