Implement fix()

[ViralBShah]

We have floor(), ceil(), and round(), but no fix().

[ViralBShah]

Also, perhaps for completeness, we should have floor and ceil apply to Int as well.

[JeffBezanson]

We have this in math_libm but it's called trunc.
BTW, do we need rint and nearbyint? Having them just seems confusing.

[JeffBezanson]

Ah, round rounds away from zero in halfway cases and rint rounds towards zero. It's impossible to remember these things. If we're going to keep all of them we should rename them.

[ViralBShah]

We should use matlab names where possible, but libm provides a couple more, where we can use libm names.

[StefanKarpinski]

I think that in some of these cases we can improve on Matlab's naming. In this case, this should probably be an option to round.

[ViralBShah]

What do you mean by "improve on Matlab's naming"? There are at least 5 rounding behaviours I can think of, some of which are provided by matlab. I would prefer to use matlab names wherever matlab implements this, and other meaningful names where matlab doesn't have anything.

1. Round towards zero
2. Round towards -Inf
3. Round towards +Inf
4. Round to nearest integer
5. Truncate

-viral

On Jul 20, 2011, at 7:23 PM, StefanKarpinski wrote:

I think that in some of these cases we can improve on Matlab's naming. In this case, this should probably be an option to round.

Reply to this email directly or view it on GitHub:
#137 (comment)

[StefanKarpinski]

trunc = 1 = 5
floor = 2
ceil = 3
round = 4

In Matlab, trunc is called fix, but in libm it's called trunc. I think libm wins here — it's a better name and libm and C are more ubiquitous and fundamental than Matlab. The libm round function rounds away from zero regardless of rounding mode, whereas rint respects the current rounding mode, and nearbyint is the same as rint but "except that nearbyint is guaranteed never to set floating point flags or trigger floating point exceptions", which results in it being much more performant (according to the man page). Since we don't have any support for rounding modes at the moment, I suggest that we just stick with the four basic functions above for now. Once we add support for rounding modes, we can think through these other issues.

[StefanKarpinski]

One source of confusion is truncate versus trunc, the former is actually just another name for converting to the like-sized integer value:

j/float.j:
30:truncate(x::Float32) = convert(Int32, x)
31:truncate(x::Float64) = convert(Int64, x)

which is identical to what the int function does for floating point values:

j/float.j:
33:int(x::Float32) = int32(x)
34:int(x::Float64) = int64(x)

I think we should get rid of truncate and just use int for that. In general, we should probably make various core functions as type-stable as possible and then rely on promotion or explicit conversion for altering types — promotion when its necessary to find the implementation of an operation and conversion otherwise.

[JeffBezanson]

OK, get rid of truncate.

By type-stable do you mean making rounding functions Float-->Float and using e.g. int(round(a)) to get actual integers?

[ViralBShah]

I think for our audience, the matlab name wins. Of course, one can have aliases, but then you just have more name pollution.

-viral

On Jul 20, 2011, at 8:58 PM, StefanKarpinski wrote:

trunc = 1 = 5
floor = 2
ceil = 3
round = 4

In Matlab, trunc is called fix, but in libm it's called trunc. I think libm wins here — it's a better name and libm and C are more ubiquitous and fundamental than Matlab. The libm round function rounds away from zero regardless of rounding mode, whereas rint respects the current rounding mode, and nearbyint is the same as rint but "except that nearbyint is guaranteed never to set floating point flags or trigger floating point exceptions", which results in it being much more performant (according to the man page). Since we don't have any support for rounding modes at the moment, I suggest that we just stick with the four basic functions above for now. Once we add support for rounding modes, we can think through these other issues.

Reply to this email directly or view it on GitHub:
#137 (comment)

[StefanKarpinski]

I think for our audience, the matlab name wins. Of course, one can have aliases, but then you just have more name pollution.

There's no other programming language that calls this fix. It's a dumb name. Especially confusing once we introduce support for fixed point arithmetic. Let's nip this one in the bud and just change it now to a better name.

By type-stable do you mean making rounding functions Float-->Float and using e.g. int(round(a)) to get actual integers?

Yes, exactly. Seems after working with it for a while to be the right way to go. I've already done some work on making functions like sign and signbit type stable — although for signbit it's questionable. It should maybe actually return a boolean indicating whether the sign bit is set or not. The sign function, however, should IMO definitely return -1, 0, +1 of the same type as the argument. Fortunately, for unsigned integer arguments, -1 isn't a possible return value so you can actually do this and preserve the type of the input.

[JeffBezanson]

Yes, to me fix sounds like it converts to fixed point.
"Truncating" a real number is a term that exists in math. What does "fix" refer to? All I can find is that "fix" is also used in visual basic and MS access.

[ViralBShah]

Yes, fix() does sound like fixed point.

Matlab has a toolbox for fixed point arithmetic, and I wonder what names they use there.

As for sign, I thought that even 0 always has a sign in IEEE754, so the answer should just be -1 or +1, although matlab sign does return 0 for 0 input. I am not sure what benefit we get from signbit.

What about sign for complex numbers?

-viral

On Jul 20, 2011, at 9:52 PM, StefanKarpinski wrote:

I think for our audience, the matlab name wins. Of course, one can have aliases, but then you just have more name pollution.

There's no other programming language that calls this fix. It's a dumb name. Especially confusing once we introduce support for fixed point arithmetic. Let's nip this one in the bud and just change it now to a better name.

By type-stable do you mean making rounding functions Float-->Float and using e.g. int(round(a)) to get actual integers?

Yes, exactly. Seems after working with it for a while to be the right way to go. I've already done some work on making functions like sign and signbit type stable — although for signbit it's questionable. It should maybe actually return a boolean indicating whether the sign bit is set or not. The sign function, however, should IMO definitely return -1, 0, +1 of the same type as the argument. Fortunately, for unsigned integer arguments, -1 isn't a possible return value so you can actually do this and preserve the type of the input.

Reply to this email directly or view it on GitHub:
#137 (comment)

[JeffBezanson]

julia> a=2*randn(2000,2000);
julia> @time rint(a)
elapsed time: 0.06712198257446289 sec
julia> @time nearbyint(a)
elapsed time: 0.58696413040161133 sec
julia> @time floor(a)
elapsed time: 0.06458902359008789 sec
julia> @time ceil(a)
elapsed time: 0.0748140811920166 sec
julia> @time trunc(a)
elapsed time: 0.06000494956970215 sec
julia> @time round(a)
elapsed time: 0.04764389991760254 sec
julia> @time int64(a)
elapsed time: 0.03995800018310547 sec
julia> @time int32(a)
elapsed time: 0.02451205253601074 sec

Looks like nearbyint is a problem. trunc is also slower than converting to integer.

[StefanKarpinski]

trunc probably has to do some extra work to handle NaN and Inf correctly. We should have a full suite of round, trunc, ceil and floor that are all {T<:Float}(T-->T). We should definitely get rid of nearbyint.