Cube root results in integer only...

[christophe...@googlemail.com]

Hi newsgroup,

I'm using a fortran compiler within Aspen Plus 2006.5 - sorry but I
don't really know which Fortran this software uses...

When I try to receive a cube root from this statement:

PI = ACOS(-1)
MM = PI ** (1./3.)

I always get MM = 1 instead of the result I wanted (1.46459...)

Does anyone know why this might be the reason? It seems like the
statement is somehow truncated, as for a real number such as 1.6995
the result is also shown as 1, whereas for 2.5865 it is shown as 2
etc...

Thanks a lot and best regards,

Christopher

[e p chandler]

> I'm using a fortran compiler within Aspen Plus 2006.5 - sorry but I
> don't really know which Fortran this software uses...
>
> When I try to receive a cube root from this statement:
>
> PI = ACOS(-1)
> MM = PI ** (1./3.)
>
> I always get MM = 1 instead of the result I wanted (1.46459...)
>
> Does anyone know why this might be the reason? It seems like the
> statement is somehow truncated, as for a real number such as 1.6995
> the result is also shown as 1, whereas for 2.5865 it is shown as 2
> etc...

Implicit typing? Variables starting with the letters I through N are
INTEGER, all others are REAL unless declared to be of some other type.
Assigning REAL to INTEGER truuncates, as does dividing INTEGER by INTEGER.

HTH

- e

[user1]

In addition to Elliot's comment, you also have an incorrect argument type for
the ACOS function. It should be ACOS(-1.0). Some compilers may forgive this
mistake, others not.

[christophe...@googlemail.com]

Hi HTH,

Thanks a lot for your reply - this has made it. Of course I didnt know
about this rule - but you learn something new every day :)

All the best,

Chris

[christophe...@googlemail.com]

Hi,

> In addition to Elliot's comment, you also have an incorrect argument type for
> the ACOS function. It should be ACOS(-1.0). Some compilers may forgive this
> mistake, others not.

Thanks, I changed that as well - although it has been accepted. The
Aspen Fortran compiler seems to be a bit choosy on what it accepts or
not...

All the best,

Chris

[Michael Prager]

christophe...@googlemail.com wrote:

>The
> Aspen Fortran compiler seems to be a bit choosy on what it accepts or
> not...

Chris-- Choosy compilers are considered desirable by many
Fortran users. By warning about loose usage, a strict compiler
can prevent unintended consequences, i.e., the wrong answer for
the intended problem. The downside is the need for clarity and
consistency by the programmer in areas he may not have
considered. --Mike

--
Mike Prager, NOAA, Beaufort, NC
Address spam-trapped; remove color to reply.
* Opinions expressed are personal and not represented otherwise.
* Any use of tradenames does not constitute a NOAA endorsement.

[e p chandler]

On Nov 19, 8:43 am, Michael Prager <Mike.Prager.ind...@noaa.gov>
wrote:

The OP's lack of concern for variable typing suggested to me that he
might be using a Fortran like language instead of Fortran. Apparently
his system interprets Fortran as part of a general process modeling
package, so it's no wonder if it somewhat "loose".

- e

[IIRC one dormant CLF poster works on a competitive product!]

[Richard Maine]

Michael Prager <Mike.Prag...@noaa.gov> wrote:

> christophe...@googlemail.com wrote:
>
> >The
> > Aspen Fortran compiler seems to be a bit choosy on what it accepts or
> > not...
>
> Chris-- Choosy compilers are considered desirable by many
> Fortran users. By warning about loose usage, a strict compiler
> can prevent unintended consequences, i.e., the wrong answer for
> the intended problem. The downside is the need for clarity and
> consistency by the programmer in areas he may not have
> considered. --Mike

And I would note that, according to the data presented, the compiler
seems the opposite of "choosy", at least in this case. If it was choosy,
it would have rejected the acos(-1). Yes, I would have considered that
desireable, as it would have given the user an error message instead of
just giving him an unexpected answer.

Also, although people pointed out the problem caused by implicit typing
in this case, nobody seems yet to have metioned the suggestion to use
implicit none, which will cause the compiler to give an error message
for implicit typing. Considering that the OP apparently was not aware of
implicit typing, I suspect that he also wasn't aware of implicit none.

A message for the OP to take from all this is that type is very
important in Fortran (as with most programming languages). It is
something that you should consciously think of when coding. If you try
to ignore it, you will make numerous errors. That is a fairly common
source of qustions here.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

[George]

I would use the cube roots of unity to test whether an implementation were
giving me results I like.

Outside of (1.,1.), I don't know what the others are, but I do know that
they're at the intersecition of the unit circle and an equilateral triangle
with a vertex on (1.,1.).

You could figure out where the other solns are on the back of a napkin.
Today, I couldn't do the mental math to figure out what date it was 2 weeks
before next Friday. Tja.

I think the answer's seven, now.
--
George

Every nation in every region now has a decision to make. Either you are
with us, or you are with the terrorists.
George W. Bush

Picture of the Day http://apod.nasa.gov/apod/

[robin]

<christophe...@googlemail.com> wrote in message
news:1e94e33f-569f-415f...@l33g2000pri.googlegroups.com...

> Thanks a lot for your reply - this has made it. Of course I didnt know
> about this rule - but you learn something new every day :)

Consider using the statement IMPLICIT NONE in all your programs.
This will cause undeclared variables (including most mis-spelled ones)
to be flagged as errors.