pow(2, 1/2) != pow(2, 0.5) problem

[Michel Rouzic]

I obtain an unwanted behavior from the pow() function :

when performing pow(2, 0.5), i obtain 1.414214
when performing pow(2, 1/2), i obtain 1.000000
when performing a=0.5; pow(2, a), i obtain 1.414214
when performing a=1/2; pow(2, a), i obtain 1.000000

how come??? and how can i do a pow(x, y) so my y is the fraction of two
other variables? (cuz for now it acts as if that fraction of two
variables in y was truncated)

[Richard Bos]

"Michel Rouzic" <Mi********@yahoo.fr> wrote:

I obtain an unwanted behavior from the pow() function :

when performing pow(2, 0.5), i obtain 1.414214
when performing pow(2, 1/2), i obtain 1.000000

Your problem is not with pow(); it is with integer maths. How much is
1/2, again? And 1.0/2?

Richard

[Michel Rouzic]

Richard Bos wrote:

"Michel Rouzic" <Mi********@yahoo.fr> wrote:

I obtain an unwanted behavior from the pow() function :

when performing pow(2, 0.5), i obtain 1.414214
when performing pow(2, 1/2), i obtain 1.000000

Your problem is not with pow(); it is with integer maths. How much is
1/2, again? And 1.0/2?

Richard

so i gotta add .0 at the end of all my numbers in order to make it work?

[Jean-Claude Arbaut]

Le 15/06/2005 12:50, dans
11**********************@f14g2000cwb.googlegroups. com, «*Michel Rouzic*»
<Mi********@yahoo.fr> a écrit*:

Richard Bos wrote:

"Michel Rouzic" <Mi********@yahoo.fr> wrote:

I obtain an unwanted behavior from the pow() function :

when performing pow(2, 0.5), i obtain 1.414214
when performing pow(2, 1/2), i obtain 1.000000

Your problem is not with pow(); it is with integer maths. How much is
1/2, again? And 1.0/2?

Richard

so i gotta add .0 at the end of all my numbers in order to make it work?

It's a good habit I would say... Otherwise one day you will forget, and
write 1/2 again, but in a place it will very difficult to find.

[David Resnick]

Michel Rouzic wrote:

Richard Bos wrote:

"Michel Rouzic" <Mi********@yahoo.fr> wrote:

I obtain an unwanted behavior from the pow() function :

when performing pow(2, 0.5), i obtain 1.414214
when performing pow(2, 1/2), i obtain 1.000000

Your problem is not with pow(); it is with integer maths. How much is
1/2, again? And 1.0/2?

Richard

so i gotta add .0 at the end of all my numbers in order to make it work?

You "gotta" do no such thing. You just need to understand how
these things work. Arithmetic is based on the types of the operands.
If you divide an integer by an integer, you get an integer result.
If you divide an integer by a double, the integer is promoted to a
double
and the result is a double. Hence, you could do any of these:

1.0/2
(double)1/2
1/2.0
1/(double)2
1.0/2.0 /* Probably the clearest, but all work */

Don't do this though:
(double)(1/2)
The cast would be applied too late...

If any of the above is wrong, no doubt I'll be corrected :)

-David

[Michel Rouzic]

David Resnick wrote:

Michel Rouzic wrote:

Richard Bos wrote:

"Michel Rouzic" <Mi********@yahoo.fr> wrote:

> I obtain an unwanted behavior from the pow() function :
>
> when performing pow(2, 0.5), i obtain 1.414214
> when performing pow(2, 1/2), i obtain 1.000000

Your problem is not with pow(); it is with integer maths. How much is
1/2, again? And 1.0/2?

Richard

so i gotta add .0 at the end of all my numbers in order to make it work?

You "gotta" do no such thing. You just need to understand how
these things work. Arithmetic is based on the types of the operands.
If you divide an integer by an integer, you get an integer result.
If you divide an integer by a double, the integer is promoted to a
double
and the result is a double. Hence, you could do any of these:

1.0/2
(double)1/2
1/2.0
1/(double)2
1.0/2.0 /* Probably the clearest, but all work */

Don't do this though:
(double)(1/2)
The cast would be applied too late...

If any of the above is wrong, no doubt I'll be corrected :)

-David

oh ok, i never know whether i get a float or int result, i mean, in my
case i had to do 1.0/(int variable).

how would i do if i wanted to divide two integers as if they were
floats without using some variable to transtype? just being curious

[David Resnick]

>Michel Rouzic wrote:

David Resnick wrote:
and the result is a double. Hence, you could do any of these:

1.0/2
(double)1/2
1/2.0
1/(double)2
1.0/2.0 /* Probably the clearest, but all work */

Don't do this though:
(double)(1/2)
The cast would be applied too late...

If any of the above is wrong, no doubt I'll be corrected :)

-David
oh ok, i never know whether i get a float or int result, i mean, in my
case i had to do 1.0/(int variable).

The result you get is based on the type. If you have constants,
things of the form "1" are integer constants, and things of the
form "1.0" are double constants. If you do an operation on two
integers, the result is an integer. If you do an operation on
a double and an integer, the result is a double. For other
types (and unsigned vs signed stuff), consult the standard
or a text to see how promotions work.
how would i do if i wanted to divide two integers as if they were
floats without using some variable to transtype? just being curious

I showed you 5 ways. What is your queston here? If you
mean a way to interprete 1/2 as division of two floats,
well, you can't. They are integers, and how the division
works is governed by the C standard. You need to cast or do
1.0/2 etc.

Do you mean how to divide a/b with a and b interpreted as doubles?
int a=1;
int b=2;
You just need to cast one of them, as in
double c = (double)a/b;

-David

[pete]

Michel Rouzic wrote:

oh ok, i never know whether i get a float or int result, i mean, in my
case i had to do 1.0/(int variable).
Actually, 1.0 is of type double.
how would i do if i wanted to divide two integers as if they were
floats without using some variable to transtype? just being curious

printf("%f\n", (double)1 / 2);

--
pete

[akarl]

Michel Rouzic wrote:

I obtain an unwanted behavior from the pow() function :

when performing pow(2, 0.5), i obtain 1.414214
when performing pow(2, 1/2), i obtain 1.000000
when performing a=0.5; pow(2, a), i obtain 1.414214
when performing a=1/2; pow(2, a), i obtain 1.000000

how come??? and how can i do a pow(x, y) so my y is the fraction of two
other variables? (cuz for now it acts as if that fraction of two
variables in y was truncated)

In C, `/' is sometimes used to denote division and sometimes not. If at
least one of the operands is a floating point number you will get the
expected result, but if both operands are integers you will get the
quotient of the division. This is one example of how C uses a familiar
symbol and makes it do something unexpected (the assignment operator is
another example). At least some languages got it right (e.g. Oberon) and
use for instance `:=' for assignment and `DIV' for the quotient of
division of integers.

Furthermore, when familiar symbols have a classical interpretation and a
"C" interpretation, how do we unambiguously express things like `x = y'
and `1/2' in source code comments?
-- August

[pete]

akarl wrote:

Furthermore, when familiar symbols have a classical
interpretation and a
"C" interpretation,
how do we unambiguously express things like `x = y'
and `1/2' in source code comments?

/*
** You're allowed to use English in source code comments
** and you can say things like "one half"
*/

--
pete

[Michel Rouzic]

pete wrote:

Michel Rouzic wrote:

oh ok, i never know whether i get a float or int result, i mean, in my
case i had to do 1.0/(int variable).

Actually, 1.0 is of type double.

how would i do if i wanted to divide two integers as if they were
floats without using some variable to transtype? just being curious

printf("%f\n", (double)1 / 2);

--
pete

thank you, i had never heard of that (double) thing before what you
want to transtype before.

[Martin Ambuhl]

Michel Rouzic wrote:

I obtain an unwanted behavior from the pow() function :

when performing pow(2, 0.5), i obtain 1.414214
when performing pow(2, 1/2), i obtain 1.000000
1/2 = 0
pow(2, 1/2) = pow(2, 0) = 1
pow (2, 1./2) = pow(2, 1/2.) = pow(2, 0.5)
when performing a=0.5; pow(2, a), i obtain 1.414214
when performing a=1/2; pow(2, a), i obtain 1.000000
1/2 = 0
see above.
how come???
When you do arithmetic on integers, the arithmetic is done on integers.
What a surprize.
and how can i do a pow(x, y) so my y is the fraction of two
other variables?

This question is not related to the above.
in pow(2, 1/2) the power is the integer quotient of two integral
constants and has nothing to do with variables.

#include <math.h>
int main(void)
{
double a = 1, b = 2, x = 2, y, z;
y = a / b; /* "my y is the fraction of two other variables" */
z = pow(x, y);
return 0;
}

[pete]

Michel Rouzic wrote:

pete wrote:

Michel Rouzic wrote:

oh ok, i never know whether i get a float or int result, i mean, in my
case i had to do 1.0/(int variable).

Actually, 1.0 is of type double.

how would i do if i wanted to divide two integers as if they were
floats without using some variable
to transtype? just being curious

printf("%f\n", (double)1 / 2);

--
pete

thank you, i had never heard of that (double) thing before what you
want to transtype before.

It's a cast.
A cast converts the type and value of an expression to another.

--
pete

[Walter Roberson]

In article <N8*********************@newsc.telia.net>,
akarl <fu********@comhem.se> wrote:
:In C, `/' is sometimes used to denote division and sometimes not. If at
:least one of the operands is a floating point number you will get the
:expected result, but if both operands are integers you will get the
:quotient of the division. This is one example of how C uses a familiar
:symbol and makes it do something unexpected (the assignment operator is
:another example). At least some languages got it right (e.g. Oberon) and
:use for instance `:=' for assignment and `DIV' for the quotient of
:division of integers.

:Furthermore, when familiar symbols have a classical interpretation and a
:"C" interpretation,

The Oberon Report indicates that / is "quotient" and DIV is
"integer quotient". You indicated that in C if both operands are
integers that you will get the "quotient" -- the same word used by
Oberon but with different meaning. What you wrote is thus inconsistant
with Oberon, so if Oberon "got it right" then either:
a) you "got it wrong" or;
b) you must admit that words and symbols are inherently ambiguous
and contextual.

http://www.oberon.ethz.ch/oreport.html#Expressions
If you are going to talk about "classical" interpretations
and "familiar symbols", then Oberon does *not* "get it right".
The "classical" meaning of / (solidus), dating back hundreds of
years, is as a seperator between shilling and pence in writing currency.
The use of solidus as meaning division only goes back a little over
a hundred years according to OED. The use of the solidus as
integer division in C (1972) is directly taken from the same use
in Kerninghan's B (1970) -- predating the decimalization of
UK coinage in 1971. Thus if you want to argue that C should have
adopted "classical" usages, then the use of the solidus should
indicate values in which the first portion is weighted 20 times the
second portion.

But you shouldn't even blame Kerninghan's "B" language. The use
of the solidus for integer division goes at least as far back
as the original FORTRAN specification in 1954. I refer you to
"D. FIXED POINT EXPRESSIONS" in
http://community.computerhistory.org...eport-1954.pdf

C's use of the solidus was thus "the familiar symbol" *to programmers*.
And if you read the history of C, you will note that Kerninghan and
Ritchie were not -intending- to write a language to be widely adopted
by the general public -- they weren't -intending- to write an
replacement for (say) Algol 68.
--
Beware of bugs in the above code; I have only proved it correct,
not tried it. -- Donald Knuth

[Lawrence Kirby]

On Wed, 15 Jun 2005 13:35:41 +0000, akarl wrote:

Michel Rouzic wrote:

I obtain an unwanted behavior from the pow() function :

when performing pow(2, 0.5), i obtain 1.414214
when performing pow(2, 1/2), i obtain 1.000000
when performing a=0.5; pow(2, a), i obtain 1.414214
when performing a=1/2; pow(2, a), i obtain 1.000000

how come??? and how can i do a pow(x, y) so my y is the fraction of two
other variables? (cuz for now it acts as if that fraction of two
variables in y was truncated)
In C, `/' is sometimes used to denote division and sometimes not.

When used as an operator in C / always denotes division.
If at
least one of the operands is a floating point number you will get the
expected result,
That depends on what you expect. Expectations on this sort of thing do
vary. For example some people (based on previous experience in the
newsgroup) expect 1.0/10.0 to give a result of one tenth. On most
implementations out there they would be wrong.
but if both operands are integers you will get the
quotient of the division.
And for many people that is the expected result. :-)
This is one example of how C uses a familiar
symbol and makes it do something unexpected (the assignment operator is
another example).
As far as I know / is recognised in mathematics for operations on integer
domains, so C isn't doing anything abnormal here.
At least some languages got it right (e.g. Oberon) and
use for instance `:=' for assignment and `DIV' for the quotient of
division of integers.
I agree that C would have been better off using := for assignment
and = for comparison, but it isn't a big deal. However / seems more
natural for division. Unless you also want create differrent operators for
integer addition, subtraction and multiplication.
Furthermore, when familiar symbols have a classical interpretation and a
"C" interpretation, how do we unambiguously express things like `x = y'
and `1/2' in source code comments?

If you mean x == y then write that, it is unambiguous. In general if there
is a C interpretation that is likely to be taken unless the context
indicates clearly otherwise.

Lawrence

[Jean-Claude Arbaut]

Le 15/06/2005 20:35, dans pa****************************@netactive.co.uk,
«*Lawrence Kirby*» <lk****@netactive.co.uk> a écrit*:

For example some people (based on previous experience in the
newsgroup) expect 1.0/10.0 to give a result of one tenth. On most
implementations out there they would be wrong.

Could you explain ? If it's just the "0.1 is not representable"
problem, forget my question :-)

[Mark McIntyre]

On Wed, 15 Jun 2005 20:23:25 +0200, in comp.lang.c , Jean-Claude
Arbaut <je****************@laposte.net> wrote:

Le 15/06/2005 20:35, dans pa****************************@netactive.co.uk,
«*Lawrence Kirby*» <lk****@netactive.co.uk> a écrit*:

For example some people (based on previous experience in the
newsgroup) expect 1.0/10.0 to give a result of one tenth. On most
implementations out there they would be wrong.

Could you explain ? If it's just the "0.1 is not representable"
problem, forget my question :-)

Thats the answer.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[akarl]

Walter Roberson wrote:

In article <N8*********************@newsc.telia.net>,
akarl <fu********@comhem.se> wrote:
:In C, `/' is sometimes used to denote division and sometimes not. If at
:least one of the operands is a floating point number you will get the
:expected result, but if both operands are integers you will get the
:quotient of the division. This is one example of how C uses a familiar
:symbol and makes it do something unexpected (the assignment operator is
:another example). At least some languages got it right (e.g. Oberon) and
:use for instance `:=' for assignment and `DIV' for the quotient of
:division of integers.

:Furthermore, when familiar symbols have a classical interpretation and a
:"C" interpretation,

The Oberon Report indicates that / is "quotient" and DIV is
"integer quotient". You indicated that in C if both operands are
integers that you will get the "quotient" -- the same word used by
Oberon but with different meaning. What you wrote is thus inconsistant
with Oberon, so if Oberon "got it right" then either:
a) you "got it wrong" or;
b) you must admit that words and symbols are inherently ambiguous
and contextual.
In the March 1995 edition of "The Programming Language Oberon-2",
section 8.2.2, `/' is called "real quotient". Hence there is no
inconsistency or ambiguity.
(http://control.ee.ethz.ch/edu/ciat1-...on2.Report.pdf)

According to page 6 in "Abstract Algebra" (second edition) by J. A.
Beachy & W. D. Blair:

<cite>
In familiar terms, the division algorithm states that dividing an
integer a by a positive integer b gives a quotient q and a non-negative
remainder r, such that r is less than b. You might write this as

a / b = q + r / b

</cite>
If you are going to talk about "classical" interpretations
and "familiar symbols", then Oberon does *not* "get it right".
The "classical" meaning of / (solidus), dating back hundreds of
years, is as a seperator between shilling and pence in writing currency.
The use of solidus as meaning division only goes back a little over
a hundred years according to OED. The use of the solidus as
integer division in C (1972) is directly taken from the same use
in Kerninghan's B (1970) -- predating the decimalization of
UK coinage in 1971. Thus if you want to argue that C should have
adopted "classical" usages, then the use of the solidus should
indicate values in which the first portion is weighted 20 times the
second portion.
Come on! `/' as a currency separator is neither widely known, nor of
current interest in a programming language.
But you shouldn't even blame Kerninghan's "B" language. The use
of the solidus for integer division goes at least as far back
as the original FORTRAN specification in 1954. I refer you to
"D. FIXED POINT EXPRESSIONS" in
http://community.computerhistory.org...eport-1954.pdf

C's use of the solidus was thus "the familiar symbol" *to programmers*.
And if you read the history of C, you will note that Kerninghan and
Ritchie were not -intending- to write a language to be widely adopted
by the general public -- they weren't -intending- to write an
replacement for (say) Algol 68.

Ok, this makes some sense.
-- August

[James McIninch]

<posted & mailed>

1 and 2 are integers.
So by integer division 1/2 = 0.
2 to the 0 power is 1.

C is correct.

Michel Rouzic wrote:

I obtain an unwanted behavior from the pow() function :

when performing pow(2, 0.5), i obtain 1.414214
when performing pow(2, 1/2), i obtain 1.000000
when performing a=0.5; pow(2, a), i obtain 1.414214
when performing a=1/2; pow(2, a), i obtain 1.000000

how come??? and how can i do a pow(x, y) so my y is the fraction of two
other variables? (cuz for now it acts as if that fraction of two
variables in y was truncated)

--
Remove '.nospam' from e-mail address to reply by e-mail

[akarl]

Lawrence Kirby wrote:

When used as an operator in C / always denotes division.
No. Tell someone on the street that 1/2 equals 0.

If at
least one of the operands is a floating point number you will get the
expected result,

That depends on what you expect. Expectations on this sort of thing do
vary. For example some people (based on previous experience in the
newsgroup) expect 1.0/10.0 to give a result of one tenth. On most
implementations out there they would be wrong.

The inexact nature of floating point numbers is a different issue.

but if both operands are integers you will get the
quotient of the division.

And for many people that is the expected result. :-)

No, at least not according to the terminology used in "Abstract Algebra"
(see my previous post).

This is one example of how C uses a familiar
symbol and makes it do something unexpected (the assignment operator is
another example).

As far as I know / is recognised in mathematics for operations on integer
domains, so C isn't doing anything abnormal here.

Yes, but then it results in a quotient *and* a remainder. Note that it
was confusing enough to the original poster.

At least some languages got it right (e.g. Oberon) and
use for instance `:=' for assignment and `DIV' for the quotient of
division of integers.

I agree that C would have been better off using := for assignment
and = for comparison, but it isn't a big deal. However / seems more
natural for division.

It is, if it gives a floating point result. On the other hand, if for
instance 1/2 = 0 it's not division, it's something else.
Unless you also want create differrent operators for
integer addition, subtraction and multiplication.

Why would you want to do that?
-- August

[Old Wolf]

Walter Roberson wrote:

If you are going to talk about "classical" interpretations
and "familiar symbols", then Oberon does *not* "get it right".
The "classical" meaning of / (solidus), dating back hundreds of
years, is as a seperator between shilling and pence in writing currency.
The use of solidus as meaning division only goes back a little over
a hundred years according to OED. The use of the solidus as
integer division in C (1972) is directly taken from the same use
in Kerninghan's B (1970) -- predating the decimalization of
UK coinage in 1971.

On pen and paper (or stylus and tablet), you would write a fraction
as:
1
-
2
or
1
/
2

I'd always assumed that "1 / 2" was the natural result of converting
the latter writing style into a form suitable for typing on a computer,
and as such, you could say that using '/' for division goes back
hundreds of years.

Of course, I wouldn't presume to disagree with OED :)

[Michel Rouzic]

C is correct.

I dont doubt it :)

[Richard Bos]

akarl <fu********@comhem.se> wrote:

Lawrence Kirby wrote:

When used as an operator in C / always denotes division.

No. Tell someone on the street that 1/2 equals 0.

Tell someone on the street that % means "modulus".

Tell someone on the street that ! means "not".

Tell someone on the street that "switch" means "make a choice".

Tell someone on the street that "#" means "a preprocessor directive will
follow", and they're likely to say "a pre-WHAT? Di-WHAT?", and in the
rare case that they're both USAnian and intelligent enough to know the
word "directive", they might well say "Directive? Say, you're not one of
them unamerican pink-livered commie traitors, are you?"

What someone on the street understands is completely irrelevant to the
design of programming languages.

And for many people that is the expected result. :-)

No, at least not according to the terminology used in "Abstract Algebra"

So? According to the terminology used in biology, division is something
cells do. That is about as relevant.

Richard

[Walter Roberson]

In article <W1*********************@newsc.telia.net>,
akarl <fu********@comhem.se> wrote:

Walter Roberson wrote:

The Oberon Report indicates that / is "quotient" and DIV is
"integer quotient".

In the March 1995 edition of "The Programming Language Oberon-2",
section 8.2.2, `/' is called "real quotient".

Irrelevant. The language referenced was Oberon, not Oberon-2 .
You wouldn't say that C had a particular property when it was
really C++ you were talking about.
--
'The short version of what Walter said is "You have asked a question
which has no useful answer, please reconsider the nature of the
problem you wish to solve".' -- Tony Mantler

[Walter Roberson]

In article <11*********************@g44g2000cwa.googlegroups. com>,
Old Wolf <ol*****@inspire.net.nz> wrote:

On pen and paper (or stylus and tablet), you would write a fraction
as:
1
-
2
That form appears to be fairly old, probably al-Hassar around 1200.
or
1
/
2
That form was introduced around 1718 in small circulation, and
does not appear to have been made common until around 1845 by De Morgan.

http://members.aol.com/jeff570/fractions.html

I'd always assumed that "1 / 2" was the natural result of converting
the latter writing style into a form suitable for typing on a computer,

Apparently the horizontal fraction bar ('vinculum') was hard to
print mechanically.
--
'The short version of what Walter said is "You have asked a question
which has no useful answer, please reconsider the nature of the
problem you wish to solve".' -- Tony Mantler

[akarl]

Richard Bos wrote:

No. Tell someone on the street that 1/2 equals 0.
Tell someone on the street that % means "modulus".

`%' is an infix operator, so at least it can't mean "percentage".
Tell someone on the street that ! means "not".
! is a prefix operator, so it can't be the exclamation mark as used in
ordinary language, e.g. "Stop!".

....and so on...

My point is that `/' is not the ordinary mathematical division operator
when the operators are integers. That's why the original poster was
confused.
What someone on the street understands is completely irrelevant to the
design of programming languages.

Okay, then why not choose the symbols completely at random: `*' for
addition, `+' for division...

And for many people that is the expected result. :-)

No, at least not according to the terminology used in "Abstract Algebra"

So? According to the terminology used in biology, division is something
cells do. That is about as relevant.

We are not talking about the interpretation of the word "division", but
the symbol `/'. If you say that the interpretation of `/' as a
mathematical symbol is irrelevant I'm afraid I can't take you seriously.

[akarl]

Walter Roberson wrote:

In article <W1*********************@newsc.telia.net>,
akarl <fu********@comhem.se> wrote:

Walter Roberson wrote:

The Oberon Report indicates that / is "quotient" and DIV is
"integer quotient".

In the March 1995 edition of "The Programming Language Oberon-2",
section 8.2.2, `/' is called "real quotient".

Irrelevant. The language referenced was Oberon, not Oberon-2 .
You wouldn't say that C had a particular property when it was
really C++ you were talking about.

It doesn't matter. `/' is the same operator in both Oberon and Oberon-2.
Niklaus Wirdt knows exactly what he is doing.

[Jean-Claude Arbaut]

Le 16/06/2005 13:56, dans vN*********************@newsc.telia.net, «*akarl*»
<fu********@comhem.se> a écrit*:

Richard Bos wrote:

No. Tell someone on the street that 1/2 equals 0.
Tell someone on the street that % means "modulus".

`%' is an infix operator, so at least it can't mean "percentage".

Tell someone on the street that ! means "not".

! is a prefix operator, so it can't be the exclamation mark as used in
ordinary language, e.g. "Stop!".

...and so on...
My point is that `/' is not the ordinary mathematical division operator
when the operators are integers. That's why the original poster was
confused.

[...] Okay, then why not choose the symbols completely at random: `*' for
addition, `+' for division...
[...]
We are not talking about the interpretation of the word "division", but
the symbol `/'. If you say that the interpretation of `/' as a
mathematical symbol is irrelevant I'm afraid I can't take you seriously.

It's stupid, the C '/' is always a division, even if it's a one you
don't like. Divide integers and you get an integer, divide doubles
and you get a double. What did you expect, dude ?

And yes, 1/2 equals 0. You know what a quotient is, don't you ?
Even kids know that.

[akarl]

Jean-Claude Arbaut wrote:

Le 16/06/2005 13:56, dans vN*********************@newsc.telia.net, « akarl »
<fu********@comhem.se> a écrit :

Richard Bos wrote:

No. Tell someone on the street that 1/2 equals 0.

Tell someone on the street that % means "modulus".
`%' is an infix operator, so at least it can't mean "percentage".

Tell someone on the street that ! means "not".

! is a prefix operator, so it can't be the exclamation mark as used in
ordinary language, e.g. "Stop!".

...and so on...
My point is that `/' is not the ordinary mathematical division operator
when the operators are integers. That's why the original poster was
confused.

[...]

Okay, then why not choose the symbols completely at random: `*' for
addition, `+' for division...

[...]

We are not talking about the interpretation of the word "division", but
the symbol `/'. If you say that the interpretation of `/' as a
mathematical symbol is irrelevant I'm afraid I can't take you seriously.

It's stupid, the C '/' is always a division, even if it's a one you
don't like.

....a one you don't like? Can you clarify that.
Divide integers and you get an integer, divide doubles
and you get a double. What did you expect, dude ?
I expect to get a floating point number. Since the result of dividing
two integers is sometimes an integer (when the remainder is zero) and
sometimes a rational number (when the remainder is non-zero) the only
sensible type of the result of the operation is therefor a floating
point number.
And yes, 1/2 equals 0. You know what a quotient is, don't you ?
Even kids know that.

If you are being ironic, you are very funny. You mix up division of
integers as defined by C and "real" mathematical division:

1 = 0*2 + 1

so the quotient of 1/2 is 0 and the remainder is 1.

[Jean-Claude Arbaut]

Le 16/06/2005 14:28, dans Df*********************@newsc.telia.net, «*akarl*»
<fu********@comhem.se> a écrit*:

Jean-Claude Arbaut wrote:

It's stupid, the C '/' is always a division, even if it's a one you
don't like.

...a one you don't like? Can you clarify that.

You seem to dislike C's notation for division, that's all I say.
In fact, I've never seen "2 DIV 3" in textbooks, but maybe you have ?
I wouldn't even be surprised to see '%' for remainder in textbooks,
as there is no standard notation for that. I saw "2 mod 3", but it's
mereley a new use of an old notation that hasn't the same meaning:

a = b (mod n) <=> a-b = k*n

Divide integers and you get an integer, divide doubles
and you get a double. What did you expect, dude ?

I expect to get a floating point number. Since the result of dividing
two integers is sometimes an integer (when the remainder is zero) and
sometimes a rational number (when the remainder is non-zero) the only
sensible type of the result of the operation is therefor a floating
point number.

And sometimes you want the quotient. C is able to compute both
quotient and FP approximation, you just have to cast operands.

And yes, 1/2 equals 0. You know what a quotient is, don't you ?
Even kids know that.

If you are being ironic, you are very funny. You mix up division of
integers as defined by C and "real" mathematical division:

1 = 0*2 + 1

so the quotient of 1/2 is 0 and the remainder is 1.

And the difference is ?

[davebsr]

> [...snip disagreement about syntax ..]

I hate to interrupt here, but aren't you two arguing about two seperate
things? Isn't akarl talking about how programming languages _should_
be, and others talking about how C _is_?

Either akarl wants to change the way C does things, which is foolish,
or he is saying that there should be a better way - a more usable
programming language. Would anyone here argue that C is the peak of
programming language usability, never to be surpassed? And just as
clearly, isn't it foolish to try and argue that the way C does
something should be changed immediately because it doesn't make sense
to a non-programmer?

--
Perhaps I don't understand...
davebsr

[Jean-Claude Arbaut]

Le 16/06/2005 15:40, dans
11**********************@g44g2000cwa.googlegroups. com, «*davebsr*»
<da*****@gmail.com> a écrit*:

[...snip disagreement about syntax ..]

I hate to interrupt here, but aren't you two arguing about two seperate
things? Isn't akarl talking about how programming languages _should_
be, and others talking about how C _is_?

Either akarl wants to change the way C does things, which is foolish,
or he is saying that there should be a better way - a more usable
programming language. Would anyone here argue that C is the peak of
programming language usability, never to be surpassed? And just as
clearly, isn't it foolish to try and argue that the way C does
something should be changed immediately because it doesn't make sense
to a non-programmer?

--
Perhaps I don't understand...
davebsr

You are completely right

[akarl]

Jean-Claude Arbaut wrote:

You seem to dislike C's notation for division, that's all I say.
Yes, I dislike C's notation for calculating the quotient (excluding the
remainder) of integer division as it means something different in
mathematics.
In fact, I've never seen "2 DIV 3" in textbooks, but maybe you have ?
I wouldn't even be surprised to see '%' for remainder in textbooks,
as there is no standard notation for that. I saw "2 mod 3", but it's
mereley a new use of an old notation that hasn't the same meaning:

a = b (mod n) <=> a-b = k*n
In mathematics we would use the floor brackets around 2/3 to get `2 DIV
3'. As you say, there doesn't seem to be any standard operator for the
remainder of integer division.
And sometimes you want the quotient. C is able to compute both
quotient and FP approximation, you just have to cast operands.

Of course I can get both, but that's not the issue here.

And yes, 1/2 equals 0. You know what a quotient is, don't you ?
Even kids know that.

If you are being ironic, you are very funny. You mix up division of
integers as defined by C and "real" mathematical division:

1 = 0*2 + 1

so the quotient of 1/2 is 0 and the remainder is 1.

And the difference is ?

In C, 1/2 equals 0. In mathematics, 1/2 is not equal to 0.

[Richard Bos]

akarl <fu********@comhem.se> wrote:

Jean-Claude Arbaut wrote:

You seem to dislike C's notation for division, that's all I say.
Yes, I dislike C's notation for calculating the quotient (excluding the
remainder) of integer division as it means something different in
mathematics.

C is not mathematics. C is programming. Get over it.
In C, 1/2 equals 0. In mathematics, 1/2 is not equal to 0.

Exactly. And in layout, 1/2 is one column of text running over the width
of two ordinary columns. And in commerce, 1/2 is a libra and two unciae.
Again: get over it.

Richard

[akarl]

davebsr wrote:

[...snip disagreement about syntax ..]

I hate to interrupt here, but aren't you two arguing about two seperate
things? Isn't akarl talking about how programming languages _should_
be, and others talking about how C _is_?

Either akarl wants to change the way C does things,

No, of course not.
which is foolish, or he is saying that there should be a better way - a
more usable programming language.
Yes.
Would anyone here argue that C is the peak of
programming language usability, never to be surpassed? And just as
clearly, isn't it foolish to try and argue that the way C does
something should be changed immediately because it doesn't make sense
to a non-programmer?

You probably mean "doesn't make sense to non-Fortran/C/C++/Java...
programmers". I think it's important to understand both the good and the
bad design choices of a programming language.

[icub3d]

One thing to remember though, many high schools consider a computer
science class to meet a language requirement. I didn't have to take a
language (German, French, etc.) because I took Computer Science I and
II.

To this day, it's still difficult to get a computer to express or
represent exactly what we mean. Similarly, the C language doesn't
always perform as *everyone* expects it would. Thus the standard was
created. It helps us interpret what int i = 1/2; will do in the C
language, when "what does 1 divided by 2 equal?" will not product the
same result in the English Language.

[Jean-Claude Arbaut]

Le 16/06/2005 15:48, dans Kq*******************@newsb.telia.net, «*akarl*»
<fu********@comhem.se> a écrit*:

In mathematics we would use the floor brackets around 2/3 to get `2 DIV
3'. As you say, there doesn't seem to be any standard operator for the
remainder of integer division.

I find this notation awful: why use an intermediate larger set ? The integer
division has nothing to do with rationnal numbers. It's the solution to
an optimization problem: for a,b > 0 find argmin(b-x*a). A rationnal is
a proportion, intuitively the current notation is absurd. Yet I won't
try to convince mathematicians to change their habits.

/ n \ p
And what about | |, denoted C in french ?
\ p / n

[Chris Croughton]

On 15 Jun 2005 17:30:31 GMT, Walter Roberson
<ro******@ibd.nrc-cnrc.gc.ca> wrote:

The use of solidus as meaning division only goes back a little over
a hundred years according to OED. The use of the solidus as
integer division in C (1972) is directly taken from the same use
in Kerninghan's B (1970) -- predating the decimalization of
UK coinage in 1971. Thus if you want to argue that C should have
adopted "classical" usages, then the use of the solidus should
indicate values in which the first portion is weighted 20 times the
second portion.

12 times, not 20 (3/9d meant 3 shillings and 9 pence, 12 pence to a
shilling, 20 shillings to the pound). I grew up with real (pre-decimal)
currency...

It is also commonly used for dates in the UK and the USA -- 16/6/2005 in
the UK, 6/16/2005 in the USA for todays date (2005-06-16 in ISO 8601).
Which, of course, is just as irrelevant to how it is used in C...

Chris C

[Walter Roberson]

In article <vN*********************@newsc.telia.net>,
akarl <fu********@comhem.se> wrote:

Okay, then why not choose the symbols completely at random: `*' for
addition, `+' for division...

FORTRAN I used the letter X for multiplication.

AXB meant A multiplied by B.
--
Are we *there* yet??

[Jean-Claude Arbaut]

Le 16/06/2005 17:49, dans d8**********@canopus.cc.umanitoba.ca, «*Walter
Roberson*» <ro******@ibd.nrc-cnrc.gc.ca> a écrit*:

In article <vN*********************@newsc.telia.net>,
akarl <fu********@comhem.se> wrote:

Okay, then why not choose the symbols completely at random: `*' for
addition, `+' for division...

FORTRAN I used the letter X for multiplication.

AXB meant A multiplied by B.

Oh yeaaaaaah ! Unbelievable !

[Mark McIntyre]

On Wed, 15 Jun 2005 23:01:48 GMT, in comp.lang.c , akarl
<fu********@comhem.se> wrote:

Lawrence Kirby wrote:

When used as an operator in C / always denotes division.
No. Tell someone on the street that 1/2 equals 0.

Q: "Man in Street, you have one live human. You divide them in two.
How many live humans do you have? "

A "Zero live humans"
The inexact nature of floating point numbers is a different issue.
I think the point was, its all to do with expectations.

On the other hand, if for
instance 1/2 = 0 it's not division, it's something else.

You're incorrect, its perfectly valid division of integers.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Mark McIntyre]

On 16 Jun 2005 07:37:01 GMT, in comp.lang.c ,
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:

I'd always assumed that "1 / 2" was the natural result of converting
the latter writing style into a form suitable for typing on a computer,

Apparently the horizontal fraction bar ('vinculum') was hard to
print mechanically.

Yes indeed, it either took up three rows, or required smaller
typeface, or special extra blocks. Expensive.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Michel Rouzic]

> It is also commonly used for dates in the UK and the USA -- 16/6/2005 in

the UK, 6/16/2005 in the USA for todays date (2005-06-16 in ISO 8601).
Which, of course, is just as irrelevant to how it is used in C...

Chris C

hehe dont worry, its commonly used for dates anywhere in the world,
except maybe on planet ISO 8601

[Anonymous 7843]

In article <11**********************@z14g2000cwz.googlegroups .com>,
Michel Rouzic <Mi********@yahoo.fr> wrote:

hehe dont worry, its commonly used for dates anywhere in the world,
except maybe on planet ISO 8601

And I'm quite miffed that there is no stardate conversion
specifier for strftime.
--
7842++

[Gordon Burditt]

>>hehe dont worry, its commonly used for dates anywhere in the world,

except maybe on planet ISO 8601

And I'm quite miffed that there is no stardate conversion
specifier for strftime.

Is there a known formula for that which all Trekkies will agree on?
There is a problem with the common Unix 32-bit time_t implementation,
which runs out in 2106 (if you make it unsigned) or 2038 (if it's
signed). However, nothing in ANSI C says time_t has to be 32 bits.

Gordon L. Burditt

[Anonymous 7843]

In article <11*************@corp.supernews.com>,
Gordon Burditt <go***********@burditt.org> wrote:

And I'm quite miffed that there is no stardate conversion
specifier for strftime.

Is there a known formula for that which all Trekkies will agree on?

Not really, but there is at least a(n) FAQ:

ftp://ftp.cc.umanitoba.ca/startrek/stardates
http://docs.rage.net/faq/Star-Trek/stardates

I've wandered far enough off topic for now...I will cease and desist.
--
7842++

[Old Wolf]

Gordon Burditt wrote:

hehe dont worry, its commonly used for dates anywhere in the world,
except maybe on planet ISO 8601

And I'm quite miffed that there is no stardate conversion
specifier for strftime.

Is there a known formula for that which all Trekkies will agree on?
There is a problem with the common Unix 32-bit time_t implementation,
which runs out in 2106 (if you make it unsigned) or 2038 (if it's
signed). However, nothing in ANSI C says time_t has to be 32 bits.

Nothing says it has to be an integral type. I've seen
implementations where it is a double, and implementations
where it is a struct.

[Joe Wright]

Gordon Burditt wrote:

hehe dont worry, its commonly used for dates anywhere in the world,
except maybe on planet ISO 8601

And I'm quite miffed that there is no stardate conversion
specifier for strftime.

Is there a known formula for that which all Trekkies will agree on?
There is a problem with the common Unix 32-bit time_t implementation,
which runs out in 2106 (if you make it unsigned) or 2038 (if it's
signed). However, nothing in ANSI C says time_t has to be 32 bits.

Gordon L. Burditt

And nothing to say it must be integral seconds. Why not double? With
53-bit precision and 2 ^ +-1024 range, we should have interesting times
pretty well covered, from millions of years to small fractions of
nanoseconds.

And I'm the first to think about and suggest double for time_t, right?
I'm going to the bar for a fresh drink. Y'all get together and tell me
why it won't work.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Keith Thompson]

"Old Wolf" <ol*****@inspire.net.nz> writes:

Gordon Burditt wrote:

[snip]

There is a problem with the common Unix 32-bit time_t implementation,
which runs out in 2106 (if you make it unsigned) or 2038 (if it's
signed). However, nothing in ANSI C says time_t has to be 32 bits.

Nothing says it has to be an integral type. I've seen
implementations where it is a double, and implementations
where it is a struct.

A struct would be non-conforming. The standard requires time_t and
clock_t to be "arithmetic types capable of representing times".
There's no indication of how times are represented; there needn't even
be a direct or linear relationship between the values of type time_t
and the passage of time.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[John Smith]

Richard Bos wrote:

Tell someone on the street that "#" means "a preprocessor directive will
follow", and they're likely to say "a pre-WHAT? Di-WHAT?", and in the
rare case that they're both USAnian and intelligent enough to know the
word "directive", they might well say "Directive? Say, you're not one of
them unamerican pink-livered commie traitors, are you?"

This sort of bigotry is not helpful. You're only displaying your own
ignorance. And, BTW, the proper term is "Pinko."

-JS