From: Uno on
http://i43.tinypic.com/15qog09.jpg

I make a living in the US southwest ostensibly working with my hands.
I'm installing an engineered floor for my friend Matt. I can do this
because by trade I'm a journeyman carpenter.

I use fortran shamelessly in the calculations that arise in this
context. The above screenshot is what Torrie the floor guy drew up when
Matt's insurer determined that a plumbing leak had forked up his carpet.
It's pretty close to correct.

So Torrie ordered 28 cases of flooring, which have 24 sq ft each. My
bid for labor was based on this. I'm just gonna start showing the
fortran now and apologize for lack of transitions.

$ gfortran -Wall -Wextra m1.f90 -o out
$ ./out
wood supply is 672.00000
living 258.86633
dining 177.88020
hall 28.285591
sunroom 53.108505
strip 23.138889

total1 is 541.27954
office 146.99132
foyer 44.358074
total2 is 732.62891
$ cat m1.f90
implicit integer (a-e)

sqft = 144

cases = 28
footage = 24
supply = cases * footage
print *, "wood supply is ", supply

hor = 208.25
vert = 179
r1 = hor * vert / sqft
print *, "living ", r1

hor = 208.25
vert = 123
r2 = hor * vert / sqft
print *, "dining ", r2

hor = 85.75
vert = 47.5
r3 = hor * vert / sqft
print *, "hall ", r3

hor = 79.25
vert = 96.5
r4 = hor * vert / sqft
print *, "sunroom ", r4

hor = 208.25
vert = 16
r5 = hor * vert / sqft
print *, "strip ", r5

total1 = r1+r2+r3+r4+r5

print *, " "
print *, "total1 is ", total1

hor = 118.25
vert = 179
r6 = hor * vert / sqft
print *, "office ", r6

hor = 40.75
vert = 156.75
r7 = hor * vert / sqft
print *, "foyer ", r7

total2 = total1+r6+r7
print *, "total2 is ", total2

end program
! gfortran -Wall -Wextra m1.f90 -o out
$

q1) Does anything above look wrong?

q2) The above calculation is obviously quick and dirty. It's quick
because fortran is blindlingly fast. It's dirty because it involves
spraying out corners with a compressor, so my eyes can easily err.

Given that the above is to calculate sqare footage in the diagram
referenced, does the above calculation look reasonable?

Living large and loving easy,
--
Uno

From: Richard Maine on
Uno <merrilljensen(a)q.com> wrote:
....
> implicit integer (a-e)
....
> q1) Does anything above look wrong?

Well, one thing that strikes me as "wrong" (with the quotes because it
is not actually an error, but rather a stylistic choice) is the use of
implicit typing.

While I have been known to make exceptions in the face of pleas of
hardship, I have a general policy of declining to help debug code that
uses implicit typing. It makes the work of debugging substantially
harder, as well as substantially increasing the number of bugs typically
present. I figure that if I spend the extra effort to debug the messes
that sometimes result, I am acting as an "enabler" in the sense of (from
Merriam Webster online)

"one who enables another to persist in self-destructive behavior (as
substance abuse) by providing excuses or by making it possible to
avoid the consequences of such behavior"

Some people have been known to argue that implicit typing simplifies
things for them enough to make up for any increased debugging problems.
That position seems incompatible with asking for debugging help.

In this case, I stopped reading the code after seeing the IMPLICIT
statement.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: Uno on
Richard Maine wrote:
> Uno <merrilljensen(a)q.com> wrote:
> ...
>> implicit integer (a-e)
> ...
>> q1) Does anything above look wrong?
>
> Well, one thing that strikes me as "wrong" (with the quotes because it
> is not actually an error, but rather a stylistic choice) is the use of
> implicit typing.
>
> While I have been known to make exceptions in the face of pleas of
> hardship, I have a general policy of declining to help debug code that
> uses implicit typing. It makes the work of debugging substantially
> harder, as well as substantially increasing the number of bugs typically
> present. I figure that if I spend the extra effort to debug the messes
> that sometimes result, I am acting as an "enabler" in the sense of (from
> Merriam Webster online)
>
> "one who enables another to persist in self-destructive behavior (as
> substance abuse) by providing excuses or by making it possible to
> avoid the consequences of such behavior"
>
> Some people have been known to argue that implicit typing simplifies
> things for them enough to make up for any increased debugging problems.
> That position seems incompatible with asking for debugging help.
>
> In this case, I stopped reading the code after seeing the IMPLICIT
> statement.
>

That's a reasonable reaction. The only variable that ended up in the
(a-e) range was 'cases'. It wou .. hold on,

$ gfortran -Wall -Wextra m1.f90 -o out
$ ./out
wood supply is 672.00000
living 258.86633
dining 177.88020
hall 28.285591
sunroom 53.108505
strip 23.138889

total1 is 541.27954
office 146.99132
foyer 44.358074
total2 is 732.62891
$ cat m1.f90
implicit real (a-z)

sqft = 144

cases = 28
footage = 24
supply = cases * footage
print *, "wood supply is ", supply

hor = 208.25
vert = 179
r1 = hor * vert / sqft
print *, "living ", r1

hor = 208.25
vert = 123
r2 = hor * vert / sqft
print *, "dining ", r2

hor = 85.75
vert = 47.5
r3 = hor * vert / sqft
print *, "hall ", r3

hor = 79.25
vert = 96.5
r4 = hor * vert / sqft
print *, "sunroom ", r4

hor = 208.25
vert = 16
r5 = hor * vert / sqft
print *, "strip ", r5

total1 = r1+r2+r3+r4+r5

print *, " "
print *, "total1 is ", total1

hor = 118.25
vert = 179
r6 = hor * vert / sqft
print *, "office ", r6

hor = 40.75
vert = 156.75
r7 = hor * vert / sqft
print *, "foyer ", r7

total2 = total1+r6+r7
print *, "total2 is ", total2

end program
! gfortran -Wall -Wextra m1.f90 -o out
$

Better?
--
Uno
From: user1 on
Uno wrote:
> http://i43.tinypic.com/15qog09.jpg
>
> I make a living in the US southwest ostensibly working with my hands.
> I'm installing an engineered floor for my friend Matt. I can do this
> because by trade I'm a journeyman carpenter.
>

I guess you've grown tired of the Phred Phungus handle.

Why not use a spreadsheet, then go ask in a different group ?
From: Louis Krupp on
Uno wrote:
> Richard Maine wrote:
>> Uno <merrilljensen(a)q.com> wrote:
>> ...
>>> implicit integer (a-e)
>> ...
>>> q1) Does anything above look wrong?
>>
>> Well, one thing that strikes me as "wrong" (with the quotes because it
>> is not actually an error, but rather a stylistic choice) is the use of
>> implicit typing.
>>
>> While I have been known to make exceptions in the face of pleas of
>> hardship, I have a general policy of declining to help debug code that
>> uses implicit typing. It makes the work of debugging substantially
>> harder, as well as substantially increasing the number of bugs typically
>> present. I figure that if I spend the extra effort to debug the messes
>> that sometimes result, I am acting as an "enabler" in the sense of (from
>> Merriam Webster online)
>>
>> "one who enables another to persist in self-destructive behavior (as
>> substance abuse) by providing excuses or by making it possible to
>> avoid the consequences of such behavior"
>>
>> Some people have been known to argue that implicit typing simplifies
>> things for them enough to make up for any increased debugging problems.
>> That position seems incompatible with asking for debugging help.
>>
>> In this case, I stopped reading the code after seeing the IMPLICIT
>> statement.
>>
>
> That's a reasonable reaction. The only variable that ended up in the
> (a-e) range was 'cases'. It wou .. hold on,
<snip>
> implicit real (a-z)
>
> sqft = 144
>
> cases = 28
<snip>
> Better?

No. 'cases' should be integer.

The whole idea behind 'implicit none' is to force you to declare
variables so that if you misspell something, the compiler catches it for
you:

real r1

r1 = 0.0
r1 = rl + 1.0

The compiler will catch the substitution of 'rl' for 'r1' ... unless, of
course, you've also declared 'rl', in which case you've set yourself up
for trouble by declaring two variable names that look almost identical.

Louis