Re: truncating and rounding

[Jerry Stuckle]

On 10/2/2017 8:00 PM, Stefan Ram wrote:
> A participant of my C++ course asked why
>
> int i = 6.8;
>
> truncates and does not round.
>
> For me, as a programmer, the answer is: It is simpler and
> one needs it more often than rounding.
>
> But in everyday life in Germany, rounding is the usual
> approach when reducing the number of places after the
> digital point.
>
> So how can one explain to non-programmers why truncation is
> the default behavior in C++?
>
> (Is it possible than processors have instructions to
> truncate, but not to round? And if so, why?)
>

All languages truncate unless you take specific actions to do otherwise.

--
==================
Remove the "x" from my email address
Jerry Stuckle
jstu...@attglobal.net
==================

[David Brown]

On 03/10/17 02:00, Stefan Ram wrote:
> A participant of my C++ course asked why
>
> int i = 6.8;
>
> truncates and does not round.
>
> For me, as a programmer, the answer is: It is simpler and
> one needs it more often than rounding.
>
> But in everyday life in Germany, rounding is the usual
> approach when reducing the number of places after the
> digital point.

It is C++ programming, not everyday life. A "string" in everyday life
is entirely different from a "string" in programming.

>
> So how can one explain to non-programmers why truncation is
> the default behavior in C++?

Take a bottle of wine and some glasses, then fill the glasses to the
top. How many full glasses of wine do you have? Is the bar customer
going to be happy with 0.8 of a glass? There are lots of real-world
situations where 6.8 is just 6 with a bit left over.

[fir]

W dniu wtorek, 3 października 2017 02:43:12 UTC+2 użytkownik Jerry Stuckle napisał:
> On 10/2/2017 8:00 PM, Stefan Ram wrote:
> > A participant of my C++ course asked why
> >
> > int i = 6.8;
> >
> > truncates and does not round.
> >
> > For me, as a programmer, the answer is: It is simpler and
> > one needs it more often than rounding.
> >
> > But in everyday life in Germany, rounding is the usual
> > approach when reducing the number of places after the
> > digital point.
> >
> > So how can one explain to non-programmers why truncation is
> > the default behavior in C++?
> >
> > (Is it possible than processors have instructions to
> > truncate, but not to round? And if so, why?)
> >
>

this seems not so easy question

more weirdly c does not only truncates but it truncates to zero on both plus and minus which my just make additional errors

some may also consider preserverance of

(int) a-b == (int) a - (int) b


othervise i think the reason is maybe that f2i cast is probably only thinked as a final cast not expected to be used in mixed calculations (same as round should be not expected and as a final cast cut is more useful)

hovever if so the rules to promote to float should be maybe more aggresive and in facyt in normal c it seems they are maybe not so agresive and it brings a
problem of needing to put additional parentheses often (i dont exactly remember them and if that what i just wrote (as a hipothesis) is tru, but maybe)

[fir]

consider for example

int a = 1;
int b= 2;
float c = 1.2;

float d = a/b*c;

or

float d = (3+ a/b)*c;

how it should work? (here and all of that cases of mixed expresions) should a/b be promoted to float by default or not?

[fir]

note here in such mixed sepressiion probably only div is probalematic,
on one side c does it good - it is it allows integer arithmetic in such expressions
on other side it generates problems
as coder must explicitely care for all such divs

side question, if

int a = 5;
int b = 7;

is

float c = float(a)/ b;

different (faster?) then

float c = a/(float)b;

or
float c = float(a)/(float)b;

?

[Paavo Helde]

On 3.10.2017 12:30, fir wrote:
> consider for example
>
> int a = 1;
> int b= 2;
> float c = 1.2;
>
> float d = a/b*c;
>
> or
>
> float d = (3+ a/b)*c;
>
> how it should work? (here and all of that cases of mixed expresions) should a/b be promoted to float by default or not?

I think fir is up to something here and one of the reasons of the
current behavior might indeed be to have some consistency regarding
integer division, so that int(8.0/3.0) would give the same result as
int(8.0)/int(3.0).

Whether the result of 8/3 should be an integer or a floating-point
number is another topic, greatly studied in Python2/Python3 wars if I
have understood correctly.

Cheers
Paavo

[Jorgen Grahn]

On Tue, 2017-10-03, David Brown wrote:
...

> Take a bottle of wine and some glasses, then fill the glasses to the
> top. How many full glasses of wine do you have? Is the bar customer
> going to be happy with 0.8 of a glass?

I'd be -- I'd just spill wine on my clothes if the glass was really
full. Especially if it wasn't my first glass.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Chris Vine]

Ideally the result of 8/3 would be stored as a rational if the
remainder is relevant to the calculation and floating point is not
good enough. Many languages have such an "exact" type built in: C and
C++ do not, although there are libraries available, for example
boost::rational for C++ and mpq in GMP for C.

Chris

[Manfred]

On 10/3/2017 2:00 AM, Stefan Ram wrote:
> A participant of my C++ course asked why
>
> int i = 6.8;
>
> truncates and does not round.
>
> For me, as a programmer, the answer is: It is simpler and
> one needs it more often than rounding.
>
> But in everyday life in Germany, rounding is the usual
> approach when reducing the number of places after the
> digital point.
>
> So how can one explain to non-programmers why truncation is
> the default behavior in C++?
>
> (Is it possible than processors have instructions to
> truncate, but not to round? And if so, why?)
>

In the context of C++ the quick and simple answer is that this is the
rule of C, so for compatibility C++ follows the same rule.

More info could probably come from comp.lang.c, anyway what I would
first note is that truncation (and particularly truncation to zero) is a
trivial operation in binary terms, and implementing rounding based on
truncation is also a trivial operation in C code.
In other words, between truncation and rounding, I would also say
truncation is the "lower level" operation of the two, so having it as
the built-in operation in the language makes some sense.
A more relevant reason would be analogy with integer arithmetic, as fir
noted elsethread:
For n and m integers the integer operation n/m results in a truncated
quotient (and a remainder), so considering e.g. 8.2 as 82/10 would
result in 8 using integer division.

[fir]

i must say i dont quite understood what you say i say
(weak english) but probably dont matter

rounding should be also easy in binary for example

1.1010101
1.0101010

.1 is 0.5
.0 is lack of .5


so
1.1xxx is 2
1.0xxx is 1


if so rounding dont seem harder,

imo there are soem cases where truncating asp truncating towards zero in both pluses and minuses works esp bad bad for example 2d perpixel drawing code below (*)
On other cases hovever just truncating topward zero is most practical (as i said in a calculations that mix integers with floats in general truncating and rounding should not appear as there just promotion to floats mostly works so truncating vs rounding shouldnt be even considered in such context as they both fail so bad) In a pack of normal usage case truncation to zero seems most usefull (becouse it works like that , "i care only for integral part")



*
DrawLine(-.99, -.99, .99, .99)

FillRectangle(-.99, -.99, .99, .99)

truncating toward zero will collapse rectangle that spans almost 4 piksels to

FillRectangle(0, 0, 0, 0)

//in general always drawing that crosses x and y axex cuts off just one row and one column of pixels

truncating down:

FillRectangle(-1, -1, 0, 0)

rounding:

FillRectangle(-1, -1, 1, 1)


in such 2d geometry rounding is imo best

[fir]

hovever this last one makes a rectangle that will span 9 piksels, where first makes only one and second makes four,

but that depends when you see centres of the pixels,

if see 0,0 as a centre between 4 pixels
or if see 0,0 as a centre of one pixel - im closer
to see 0,0 as a centre in pixels if so such
-.9 -.9 t0 .9 .9 rectangle lays on all 9 pixels though only one os fully covered 4 are covered in half and 4 are covered in 1/4, but nine are touched

in ce there is round() function afair - i remember in old pentium 4 there was drasrical eeficiency problem related to this as you would need to switch rounding mode of fpu to round butr on ssse i rememver there are special mnemonics that dont need to swich and that means one could use bith truncate and round with not much worry afair

[fir]

one could also add hat the difference is that c casting is 'conservative' (cuts of all the fractional points) where in 2d graphics drawing is expected to be 'greedy' (even slightly taouched pixel is expected be set)

[Manfred]

On 10/3/2017 8:50 PM, fir wrote:
>> A more relevant reason would be analogy with integer arithmetic, as fir
>> noted elsethread:
>> For n and m integers the integer operation n/m results in a truncated
>> quotient (and a remainder), so considering e.g. 8.2 as 82/10 would
>> result in 8 using integer division.
> i must say i dont quite understood what you say i say
> (weak english) but probably dont matter

You first referred to the relation with arithmetic operations in this
thread.
The difference is that you mentioned mixed float/integer operations,
while I made a more basic point.