Velocity Reviews > ceil() and int values

# ceil() and int values

Test
Guest
Posts: n/a

 10-13-2013
I need to get a ceil value from two integers

When I use as follows:
int i5,i2;
i5=5;i2=2;
i=ceil(i5/i2);
I get 2 for obvious reasons.

However when I use as follows:
int i5,i2;
i5=5;i2=2;
i=ceil((double)i5/i2);
I get 3 but from past experience I doubt some compilers will return 2.

Safest way to get 3 appears to be lengthy
int i5,i2;
i5=5;i2=2;
i=ceil((double)((double)i5/(double)i2));

What is the "cleanest" but most compatible way? My program in this instance
always uses integers greater than zero and less than 128. Is there another
(speedier?) way other than using ceil()?

Eric Sosman
Guest
Posts: n/a

 10-13-2013
On 10/13/2013 4:31 AM, Test wrote:
> I need to get a ceil value from two integers
>
> When I use as follows:
> int i5,i2;
> i5=5;i2=2;
> i=ceil(i5/i2);
> I get 2 for obvious reasons.
>
> However when I use as follows:
> int i5,i2;
> i5=5;i2=2;
> i=ceil((double)i5/i2);
> I get 3 but from past experience I doubt some compilers will return 2.
>
> Safest way to get 3 appears to be lengthy
> int i5,i2;
> i5=5;i2=2;
> i=ceil((double)((double)i5/(double)i2));
>
> What is the "cleanest" but most compatible way? My program in this instance
> always uses integers greater than zero and less than 128. Is there another
> (speedier?) way other than using ceil()?

i = (i5 + i2 - 1) / i2;

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)d

Malcolm McLean
Guest
Posts: n/a

 10-13-2013
On Sunday, October 13, 2013 10:24:14 AM UTC+1, (E-Mail Removed) wrote:
> On Sun, 13 Oct 2013 11:31:57 +0300, Test <test@.nil.invalid.com>
>

> >Safest way to get 3 appears to be lengthy

>
> > int i5,i2;
> > i5=5;i2=2;
> > i=ceil((double)((double)i5/(double)i2));
> >

>
> >What is the "cleanest" but most compatible way? My program in this instance
> >always uses integers greater than zero and less than 128. Is there another
> >(speedier?) way other than using ceil()?

>

int x = i5/i2;
if(x * i2 < i5)
x++;

it may or may not be faster, often floating point is pipelined separately
to integer calculations, so it's very difficult to say whether removing a
floating point operation will speed up code or not.

James Kuyper
Guest
Posts: n/a

 10-13-2013
On 10/13/2013 05:24 AM, Robert Wessel wrote:
> On Sun, 13 Oct 2013 11:31:57 +0300, Test <test@.nil.invalid.com>
> wrote:
>
>> I need to get a ceil value from two integers
>>
>> When I use as follows:
>> int i5,i2;
>> i5=5;i2=2;
>> i=ceil(i5/i2);
>> I get 2 for obvious reasons.
>>
>> However when I use as follows:
>> int i5,i2;
>> i5=5;i2=2;
>> i=ceil((double)i5/i2);
>> I get 3 but from past experience I doubt some compilers will return 2.

>
>
> Baring a broken compiler, 3 is the only possible result. Casting i5
> to a double will then force i2 to a matching promotion, so that the
> (double) division can occur. So the result *must* be 2.5, and
> ceil(2.5) must be 3.0. Nor should there be any question of how that
> converts back to an int.

While I would agree with you that any compiler which produces any value
other than 3 is broken, such a compiler could still be fully conforming:

"The accuracy of the floating-point operations (+, -, *, /) and of the
library functions in <math.h> and <complex.h> that return floating-point
results is implementation defined, as is the accuracy of the conversion
between floating-point internal representations and string
representations performed by the library functions in <stdio.h>,
<stdlib.h>, and <wchar.h>. The implementation may state that the
accuracy is unknown." (5.2.2.4.2p6).

Division is one of those operations, and ceil() is one of those
functions, so there are two different opportunities for arbitrarily bad
accuracy to be fully conforming, so long as the implementation documents
the fact that it is that bad.

If the implementation chooses to pre-#define __STDC_IEC_559__, the
requirements are much stricter, and a conforming implementation must
produce 3.
--
James Kuyper

Seebs
Guest
Posts: n/a

 10-15-2013
On 2013-10-13, Test <test@> wrote:
> However when I use as follows:
> int i5,i2;
> i5=5;i2=2;
> i=ceil((double)i5/i2);
> I get 3 but from past experience I doubt some compilers will return 2.

.... I doubt very much that any compiler will yield 2, because I don't
think C's ever worked in a way where this could produce anything but 3.

> What is the "cleanest" but most compatible way? My program in this instance
> always uses integers greater than zero and less than 128. Is there another
> (speedier?) way other than using ceil()?

If they're always smallish positive integers:
i = (i5 + 1) / i2;

-s
--
Copyright 2013, all wrongs reversed. Peter Seebach / (E-Mail Removed)
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
Autism Speaks does not speak for me. http://autisticadvocacy.org/
I am not speaking for my employer, although they do rent some of my opinions.

Noob
Guest
Posts: n/a

 10-15-2013
Seebs wrote:

> If they're always smallish positive integers:
> i = (i5 + 1) / i2;

Close, but no cigar. Eric got it right

Malcolm McLean
Guest
Posts: n/a

 10-15-2013
On Tuesday, October 15, 2013 8:45:44 AM UTC+1, Noob wrote:
> Seebs wrote:
>
>
>
> > If they're always smallish positive integers:

>
> > i = (i5 + 1) / i2;

>
>
>
> Close, but no cigar. Eric got it right
>

His fails on i5 + i2 -1 > INT_MAX, but it's faster solution than mine,
so the one to be preferred.

James Harris
Guest
Posts: n/a

 10-15-2013
"Malcolm McLean" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Tuesday, October 15, 2013 8:45:44 AM UTC+1, Noob wrote:
>> Seebs wrote:
>>
>> > If they're always smallish positive integers:

>>
>> > i = (i5 + 1) / i2;

>>
>> Close, but no cigar. Eric got it right
>>

> His fails on i5 + i2 -1 > INT_MAX, but it's faster solution than mine,
> so the one to be preferred.

I don't understand. Eric's was i = (i5 + i2 - 1) / i2. How can it be faster?
Unless the divisor is a constant both will be dominated by the cost of the
division.

James

James Kuyper
Guest
Posts: n/a

 10-15-2013
On 10/15/2013 07:23 AM, James Harris wrote:
> "Malcolm McLean" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> On Tuesday, October 15, 2013 8:45:44 AM UTC+1, Noob wrote:
>>> Seebs wrote:
>>>
>>>> If they're always smallish positive integers:
>>>
>>>> i = (i5 + 1) / i2;
>>>
>>> Close, but no cigar. Eric got it right
>>>

>> His fails on i5 + i2 -1 > INT_MAX, but it's faster solution than mine,
>> so the one to be preferred.

>
> I don't understand. Eric's was i = (i5 + i2 - 1) / i2. How can it be faster?
> Unless the divisor is a constant both will be dominated by the cost of the
> division.

Malcolm's solution was not the one given above; it was:
> int x = i5/i2;
> if(x * i2 < i5)
> x++;

--
James Kuyper

James Kuyper
Guest
Posts: n/a

 10-15-2013
On 10/15/2013 03:34 AM, Seebs wrote:
> On 2013-10-13, Test <test@> wrote:
>> However when I use as follows:
>> int i5,i2;
>> i5=5;i2=2;
>> i=ceil((double)i5/i2);
>> I get 3 but from past experience I doubt some compilers will return 2.

>
> ... I doubt very much that any compiler will yield 2, because I don't
> think C's ever worked in a way where this could produce anything but 3.
>
>> What is the "cleanest" but most compatible way? My program in this instance
>> always uses integers greater than zero and less than 128. Is there another
>> (speedier?) way other than using ceil()?

>
> If they're always smallish positive integers:
> i = (i5 + 1) / i2;

I suppose that's correct, for a suitable definition of "smallish". The
smallest pair of positive values for which it gives the wrong result is
i5==1, i2==3, for which the correct result is 1, and your formula gives
0. That's a pretty restrictive definition of "smallish".
--
James Kuyper

 Thread Tools

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is OffTrackbacks are On Pingbacks are On Refbacks are Off Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post ptn C Programming 14 10-04-2007 08:16 PM zlotawy VHDL 4 09-15-2007 03:35 PM arun C Programming 8 07-31-2006 05:11 AM Hal Styli C Programming 14 01-20-2004 10:00 PM Schnoffos C Programming 2 06-27-2003 03:13 AM

Advertisments