Rounding up in perl

[sln]

(e-mail address removed) wrote:

(e-mail address removed) wrote:



It says it should not be used for rounding, for TWO reasons.
Thats two references to ROUNDING you say it doesen't use.

sln

Or... it's that it could be used for rounding, but that it's not a
good idea, as you could have unexpected results.
[snip]
And just what is that?

sln

It might appear to be working fine and give you the desired/expected
results, but by the nature of it, and as you're warned about in the
docs you quoted yourself, it is not a good idea and probably won't
work
how you expect it to. I don't know what else to say?

It is certainty for you, you won't and can't depend on Perl intrinsic
functions. Because for you, they work intermittentely and with
unexpected results.

I wish you luck.

sln

I didn't create it, I didn't write the documentation about it. While
I'm sure one could work with said function to do rounding, it's not
intended to round and suffers from side effects.

[snip]

Ah, just what is the intention of int()? And what are the 'side' effects?

sln

 

[sln]

That is because int() does not *have* a process of rounding.

int() does not do rounding.

This is the last comment I am going to make on this
subject.

The documentation is misleading. This truncating towards 0 is
bull. There is no such thing. Truncating is truncating, period.

It may look like truncating but its not so.

int() rounds DOWN when a positive number and rounds UP when a
negative number. It can't be interpreted in any other fashion.

End of discussion !!


sln

 

[Tim Greer]

(e-mail address removed) wrote:

(e-mail address removed) wrote:



It says it should not be used for rounding, for TWO reasons.
Thats two references to ROUNDING you say it doesen't use.

sln

Or... it's that it could be used for rounding, but that it's not a
good idea, as you could have unexpected results.
[snip]
And just what is that?

sln

It might appear to be working fine and give you the desired/expected
results, but by the nature of it, and as you're warned about in the
docs you quoted yourself, it is not a good idea and probably won't
work
how you expect it to. I don't know what else to say?

It is certainty for you, you won't and can't depend on Perl
intrinsic functions. Because for you, they work intermittentely and
with unexpected results.

I wish you luck.

sln

I didn't create it, I didn't write the documentation about it. While
I'm sure one could work with said function to do rounding, it's not
intended to round and suffers from side effects.

[snip]

Ah, just what is the intention of int()? And what are the 'side'
effects?

sln

Just what it says (Returns the integer portion of EXPR):

int EXPR
int Returns the integer portion of EXPR. If EXPR is omitted,
uses $_. You should not use this function for rounding: one because
it truncates towards 0, and two because machine representations
of floating point numbers can sometimes produce counterintu-
itive results. For example, "int(-6.725/0.025)" produces -268
rather than the correct -269; that’s because it’s really more
like -268.99999999999994315658 instead. Usually, the
"sprintf", "printf", or the "POSIX::floor" and "POSIX::ceil"
functions will serve you better than will int()

I repeat, I didn't say you couldn't use it for rounding, but it's not
the best function for it, unless you are okay with results you probably
don't want now and then (which to me, says it's a bad idea -- which the
docs tell you as well). By all means, if you want to use it for
rounding, go for it (and good luck with that).

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Tim Greer

I didn't create it, I didn't write the documentation about it.

So do it.

While I'm sure one could work with said function to do rounding,

int() rounds. Period.

it's not intended to round

It is.

and suffers from side effects.

There is no side effects.

[But we had this discussion many times. Perl docs are abyssmal...]

Hope this helps,
Ilya

 

[Tim Greer]

[A complimentary Cc of this posting was sent to
Tim Greer

I didn't create it, I didn't write the documentation about it.

So do it.

Do what? Go back in time and create it or go back in time and write the
documention?

int() rounds. Period.

Just not as well as other methods.

It is.

Just not accurately in every circumstance (where its own documentation
recommends against using it)

There is no side effects.

According to the documentation it does.

[But we had this discussion many times. Perl docs are abyssmal...]

So rewrite the docs.

 

[Tim Greer]

Ilya Zakharevich wrote:


<Snip>

PS: I never said int() *won't* round (or can't be used to round). I
even said it could be, but there are better methods.

 

[Tim Greer]

[A complimentary Cc of this posting was sent to
Tim Greer

I didn't create it, I didn't write the documentation about it.

So do it.

While I'm sure one could work with said function to do rounding,

int() rounds. Period.

it's not intended to round

It is.

and suffers from side effects.

There is no side effects.

[But we had this discussion many times. Perl docs are abyssmal...]

Hope this helps,
Ilya

Actually, I'm a little surprised that you'd respond like that, so
forgive the additional reply. int() truncates, and just because you can
use it to round, doesn't mean that is its intended purpose. You insist
it's a function intended to round and not truncate? The probelms with
using int to round (in the manner outlined in this thread anyway) are
outlined in the documentation and verified by tests. So, has this
changed from a truncate function to a round function at some point?

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Tim Greer

Do what? Go back in time and create it or go back in time and write the
documention?

Write correct documentation...

Just not as well as other methods.

Exactly as well as any other rounding methed.

Just not accurately in every circumstance

int() gives a precise answer. By definition, a precise (and correct
;-) answer can't be "non-accurate".

(where its own documentation recommends against using it)

Documentation is absolutely wrong.

According to the documentation it does.

Nevertheless.

Hope this helps,
Ilya

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
Tim Greer

Actually, I'm a little surprised that you'd respond like that, so
forgive the additional reply. int() truncates, and just because you can
use it to round, doesn't mean that is its intended purpose. You insist
it's a function intended to round and not truncate?

If you want to go back in time, and repeat all these arguments again:

truncation is of 5 different (more or less commonly used) modes of rounding.

Hope this helps,
Ilya

 

[Tim Greer]

[A complimentary Cc of this posting was sent to

There's no need for the complimentary Cc. I read it here, I don't need
to read it in email as well. Thanks.

Tim Greer



Write correct documentation...

You're welcome to write the correct documentation yourself, since you
disagree with it.

Exactly as well as any other rounding methed.

Except it doesn't round up as a value to an integer as well as sprintf,
and the fact that truncation isn't "exactly" rounding.

int() gives a precise answer. By definition, a precise (and correct
;-) answer can't be "non-accurate".

See the documentation. If you disagree with it, submit something that's
correct. Argue semantics all you like, it truncates, it doesn't round.
I suppose if you think that's the same effect, I can't help.

Documentation is absolutely wrong.

Why not submit something that's correct?

Nevertheless.

Nevertheless, someone I actually used to respect for their contributions
has resorted to acting like this and aligning their logic with a poster
that doesn't know what the /x modifer if for. Food for thought (not
that I expect it to matter).

 

[Tim Greer]

[A complimentary Cc of this posting was sent to
Tim Greer

Actually, I'm a little surprised that you'd respond like that, so
forgive the additional reply. int() truncates, and just because you
can
use it to round, doesn't mean that is its intended purpose. You
insist it's a function intended to round and not truncate?

Again, no reason for the "complimentary Cc". Thanks.

If you want to go back in time, and repeat all these arguments again:

I wasn't involved in any of those previous arguments, I have no interest
in that. I prefer to discuss the topic, rather than argue about it
(though sometimes one seem inevitable when people feel the need to make
sarcastic or snide remarks).

truncation is of 5 different (more or less commonly used) modes of
rounding.

More or less truncates, rather than rounds, but if that's good enough
for you, I won't debate how you feel about it. I said in my first
response in this thread that it can certainly round. To be honest, I
have better things to do in life than argue with someone I'll never
meet, on a newsgroup about what a function actually technically does or
not.

Experts and non experts all agree and disagree on this particular topic
with the int() function in Perl. I seriously doubt debating it will
get anywhere. I simply said that it truncates, it doesn't round (it
can get rounding results though). If you wish to disprove the
documentation and update it, I know I'd appreciate it, and I'm sure
others would as well.

Hope this helps,

Not really, but I appreciate the attempt. Still, I'd prefer not to
argue about it (I genuinely do not care, and the debate about this is
well documented), so I'll leave it here. Much respect.

 

[Eric Pozharski]

[A complimentary Cc of this posting was sent to
Tim Greer

Actually, I'm a little surprised that you'd respond like that, so
forgive the additional reply. int() truncates, and just because you
can
use it to round, doesn't mean that is its intended purpose. You
insist it's a function intended to round and not truncate?

Again, no reason for the "complimentary Cc". Thanks.

Consider looking in header of any his message. There're precise
instructions how to avoid CC. (and then we'll see the next episode of
this show.)

*CUT*

 

[Peter J. Holzer]

Again, no reason for the "complimentary Cc". Thanks.


I wasn't involved in any of those previous arguments,

http://www.merriam-webster.com/dictionary/argument:

| Main entry: ar·gu·ment
| Pronunciation: \ˈär-gyə-mənt\
| Function: noun
| Etymology: Middle English, from Anglo-French, from Latin argumentum, from arguere
| Date: 14th century
|
| 1 obsolete : an outward sign : indication
| 2 a: a reason given in proof or rebuttal
| b: discourse intended to persuade
| 3 a: the act or process of arguing : argumentation
| b: a coherent series of statements leading from a premise to a conclusion
| c: quarrel , disagreement
| 4: an abstract or summary especially of a literary work <an argument preceded the poem>
| 5: the subject matter especially of a literary work
| 6 a: one of the independent variables upon whose value that of a function depends
| b: a substantive (as the direct object of a transitive verb) that is required by a predicate in grammar
| c: amplitude 4

Ilya meant meaning 2a.

I have no interest in that. I prefer to discuss the topic, rather
than argue about it

You cannot discuss something without using arguments.

More or less truncates, rather than rounds, but if that's good enough
for you, I won't debate how you feel about it. I said in my first
response in this thread that it can certainly round. To be honest, I
have better things to do in life than argue with someone I'll never
meet, on a newsgroup about what a function actually technically does or
not.

Experts and non experts all agree and disagree on this particular topic
with the int() function in Perl. I seriously doubt debating it will
get anywhere. I simply said that it truncates, it doesn't round (it
can get rounding results though).

As Ilya said, truncating is one of several modes of rounding. To say "it
truncates, it doesn't round" makes about as much sense as to say "it's a
dog, not an animal".

The most commonly used rounding functions are:

round to minus infinity (floor)
round to plus infinity (ceil)
round to zero (int)
round away from zero
round to even
round to odd
round to nearest (sprintf)

Where the last one needs an additional tie-breaking function (because
for n+0.5 (n ∈ ℤ), there are two nearest integers: n and n+1). Commonly
used in this case are round away from zero (i.e, 2.5 is rounded to 3,
3.5 to 4, -3.5 to -4), which is the way you learn in school, and round
to even (2.5 is rounded to 2, 3.5 is rounded to 4), which is used in
numerical applications.

In colloquial speech "rounding" almost always means "round to nearest".
The advice against using int "for rounding" must be understood in this
context. It's not that int doesn't round, or that isn't dependable, it
just usually isn't the rounding function you want. (Neither is ceil or
floor, btw, when you want to round to nearest).

hp

 

[Peter J. Holzer]

Here is a Perl ceil/floor equivalent. The first code section
seems to correctly implement floor by taking into account that
int() does not use the sign in its process of rounding. The
second code section with floor, although intuitive is not correct.
For a full proof, all the values between 2.0 - 2.9 should be checked.

For a full proof that your implementation is wrong, only a single value
needs to be checked:

The floor of 2.2 is 2.000000
The floor of -2.2 is -2.000000
The ceil of 2.2 is 2.000000
The ceil of -2.2 is -1.000000

hp

 

[Tim Greer]

Consider looking in header of any his message.  There're precise
instructions how to avoid CC.  (and then we'll see the next episode of
this show.)

*CUT*

I wasn't exactly worried about it, but I don't make a habit of reading
people's posting headers for instructions of avoiding emailed CC
replies, especially when I'm replying to their post anyway. I think
adding a custom header in my news client is a little much.

 

[Tim Greer]

As Ilya said, truncating is one of several modes of rounding.

Right. I am well aware of that, and I even said so as well before Ilya
replied.

It's not that int doesn't round, or that
isn't dependable, it just usually isn't the rounding function you
want.

And that is what I said previously, it's not probably want you want,
since it's intent is to truncate (even if that is a method used for
rounding), and I think that it's not as dependable as other solutions,
which I also listed -- which the docs themselves also warn against.

I honestly don't understand the confusion here. Perhaps it was just the
natural flow of the 'argument' that caused the confusion?

 

[Tim Greer]

it's not probably what you want, ^^^^
since its

^^^

Pardon, I hate making typos.

 

[sln]

For a full proof that your implementation is wrong, only a single value
needs to be checked:

The floor of 2.2 is 2.000000
The floor of -2.2 is -2.000000
The ceil of 2.2 is 2.000000
The ceil of -2.2 is -1.000000

hp

Yes, true its wrong, I see why now. I'm working on it now, testing
(+-) 2.0 - 3.0.

(+-) 1.0 appears to work except on whole number boundries. I will hopefully have a
solution shortly. If its too verbose in its operation overhead, then POSIX will have
to do.

I don't think its a big deal though.


sln

 

[Eric Pozharski]

I wasn't exactly worried about it, but I don't make a habit of reading
people's posting headers for instructions of avoiding emailed CC
replies, especially when I'm replying to their post anyway. I think
adding a custom header in my news client is a little much.

A-ha, I've got your point. Then, I admit, I've misunderstood your
remarks about that,.. #@! stupid idea that his CCs are anyway welcome.
That was a bad mood, and let's forget it.

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was NOT [per weedlist] sent to
Tim Greer

Nevertheless, someone I actually used to respect for their contributions
has resorted to acting like this and aligning their logic with a poster
that doesn't know what the /x modifer if for. Food for thought (not
that I expect it to matter).

Yes, do REALLY think about it, please.

I would GLADLY "align" my logic with sln/xee/godzilla/whoever as far
as what they say in a particular moment makes sense. Likewise in the
opposite direction.

Hope this helps,
Ilya