I guess the subtle difference is that, strictly speaking, min and max of 
Floating Point types would be ±Inf.

> On 27 Feb 2015, at 21:46, Andreas Noack <[email protected]> wrote:
> 
> Thats right and I realized that right after I posted. I'd be fine with using 
> min and max for types but probably some would oppose that.
> 
> 2015-02-27 15:42 GMT-05:00 Jutho Haegeman <[email protected] 
> <mailto:[email protected]>>:
> I am not opposed to that but the same could be said for typemin and typemax.
> 
> Verstuurd vanaf mijn iPhone
> 
> Op 27-feb.-2015 om 21:27 heeft Andreas Noack <[email protected] 
> <mailto:[email protected]>> het volgende geschreven:
> 
>> I think it is fine that the type of the argument determines the behavior 
>> here. Having "type" in the name would be a bit like having 
>> `fabs(x::Float64)`.
>> 
>> 2015-02-27 15:21 GMT-05:00 Jutho <[email protected] 
>> <mailto:[email protected]>>:
>> But I wouldn't overload real; real is for the real value of a value, not for 
>> the real type. Maybe something like realtype , or typereal if we want to go 
>> with the other type... functions.
>> 
>> Op vrijdag 27 februari 2015 21:18:34 UTC+1 schreef Andreas Noack:
>> I'd like to have something like this.
>> 
>> 2015-02-27 15:02 GMT-05:00 Jutho <[email protected] <>>:
>> 
>> Or in this particular case, maybe their should be some functionality like 
>> that in Base, or at least in Base.LinAlg, where is often necessary to mix 
>> complex variables and real variables of the same type used to build to 
>> complex variables.
>> 
>> Op donderdag 26 februari 2015 08:10:35 UTC+1 schreef Sheehan Olver:
>> Maybe a better alternative is to create an internal function with the same 
>> name: 
>> 
>>         real(v…)=Base.real(v…) 
>>         real{T<:Real}(::Type{Complex{T}})=T 
>>         real{T<:Real}(::Type{T})=T 
>> 
>> This will avoid the override leaking from the package. 
>> 
>> 
>> 
>> 
>> > On 26 Feb 2015, at 6:07 pm, Sheehan Olver <[email protected] <>> wrote: 
>> > 
>> > I think this is a case where I know the answer but pretending I don’t :) 
>> > 
>> > 
>> > 
>> >> On 26 Feb 2015, at 6:06 pm, Ivar Nesje <[email protected] <>> wrote: 
>> >> 
>> >> We have seen quite a few instances where Base functions were extended 
>> >> with methods without restriction to non-Base types, and it caused 
>> >> problems when Julia was updated. 
>> >> 
>> >> Is randomly breaking in new versions of Julia your style? 
>> > 
>> 
>> 
>> 
> 

Reply via email to