ceil/floor/round/trunc

[Matthias Schabel]

If implicit conversion between float and int is disallowed, shouldn't these functions return integers?

[Harlan Harris]

No -- there's a distinction between round (etc.) and iround (etc.). The latter does as you suggest. The former are more general than just rounding to a nearby integer. Their second and third digits allow rounding to different decimal places, and in different bases. See base/floatfuncs.jl and test/numbers.jl for details.

On Tue, Nov 13, 2012 at 3:57 PM, Matthias Schabel <matt...@schabels.com> wrote:

If implicit conversion between float and int is disallowed, shouldn't these functions return integers?

--

[Jeffrey Sarnoff]

Julia has integer returning version of ceil, floor, round, trunc called iceil, ifloor, iround, itrunc.
Julia's divide (a/b), when applied to ints, returns a floating_point value.
Julia has div(a,b) and fld(a,b), a floored variant of div, both return an int value.

for example, division with integers -7 and 4

a = int(-7)
b = int( 4)
a_divide_b = a/b        # -1.75
a_div_b    = div(a,b)   # -1
a_fld_b      = fld(a,b) # -2

[Matthias Schabel]

Thanks...this also reminds me of another question I came up with :

Why does

int(3.) 

give the expected answer but 

Int64(3.)

give an error. I would expect the constructors for these types to behave in a consistent manner.

Matthias

--
 
 
 

[Mike Nolta]

On Tue, Nov 13, 2012 at 4:34 PM, Matthias Schabel <matt...@schabels.com> wrote:
> Thanks...this also reminds me of another question I came up with :
>
> Why does
>
> int(3.)
>
> give the expected answer but
>
> Int64(3.)
>
> give an error. I would expect the constructors for these types to behave in
> a consistent manner.

Hmm, works for me. Which version are you using?

-Mike

>
> Matthias
>
>
>
> Julia has integer returning version of ceil, floor, round, trunc called
> iceil, ifloor, iround, itrunc.
> Julia's divide (a/b), when applied to ints, returns a floating_point value.
> Julia has div(a,b) and fld(a,b), a floored variant of div, both return an
> int value.
>
> for example, division with integers -7 and 4
>
> a = int(-7)
> b = int( 4)
> a_divide_b = a/b # -1.75
> a_div_b = div(a,b) # -1
> a_fld_b = fld(a,b) # -2
>
> On Tuesday, November 13, 2012 3:57:38 PM UTC-5, Matthias Schabel wrote:
>>
>> If implicit conversion between float and int is disallowed, shouldn't
>> these functions return integers?
>
>
> --
>
>
>
>
>

> --
>
>
>

[Stefan Karpinski]

Note the capitalization:

julia> Int64(3.)

type error: apply: expected Function, got Type{Int64}

julia> int64(3.)

3

I still think we should probably make the former work, but it would require allowing abstract types to be called like functions which Jeff is understandably reluctant to do.

--

[Stefan Karpinski]

To clarify, making Int64 work doesn't require making abstract types callable – it requires making bits types callable; but we'd probably also want abstract types to be callable.

[Matthias Schabel]

Why the reluctance to make this change? Time and effort or other issue?

--
 
 
 

[Stefan Karpinski]

That and every additional language feature adds complications to the system. We tend not to add features until it becomes painfully clear that they're a good idea.

--