- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

An interesting issue has arisen in my workplace. I cannot discuss it for ethical reasons, but I was wondering if someone - could give me a solution for the problem

The program should print teh square root of all odd numbers from 1 to n to two decimal places.

I am interested in the structure of the solution not the solution

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

Isn't the definition of an oxymoron "a normal programmer"?

Jim Dempsey

```
! OddSqrt.f90
!
! The program should print teh square root of all odd numbers from 1 to n to two decimal places...
! Without use of intrinsic math function sqrt.
! Without regard to performance
Program OddSqrt
implicit none
real :: TheSquareRoot
real :: TheValue
integer :: n
integer :: cent
n = 10000 ! to be read in, however for this we will set the value
cent = 1
do TheValue = 1.0, n, 2 ! step odd numbers 1:n
do
TheSquareRoot = real(cent) / 100.0
if(TheSquareRoot * TheSquareRoot >= TheValue) then
print *, TheValue, TheSquareRoot
exit
endif
cent = cent + 1
end do
end do
end program OddSqrt
```

Link Copied

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

What about

```
program psqrt
integer :: i,n = 21
Print '(1x,5F8.2)',(sqrt(real(i)),i=1,n,2)
end program
```

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

Need something a bit more obscure. How about this using newtons method:

implicit none

real*8 x,xold

integer n,i, iter

xold = 1

x = 1

n = 10000

do i = 1,n,2

iter = 0

do while(abs(xold-x).ge..005)

iter = iter + 1

xold = x

x = .5*(xold+i/xold)

end do

write(*,'(i6,f8.2,i6)') i,x,iter

x = x + .01

end do

read(*,*) i

Starts out taking 4 iteration to get square root of 2. Quickly gets down to 2, and finally only needs 1.

The difference between sqrt(n) and sqrt(n+2) is pretty small for larger values of n

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

The original problem required an input of n from the user?

The real issue is how many different way will a group of normal programmers code such a problem and how much similarity will be normal

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

Normal?

*“The only glory most of us have to hope for is the glory of being normal.”*

**Katherine Fullerton Gerould**

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

Isn't the definition of an oxymoron "a normal programmer"?

Jim Dempsey

```
! OddSqrt.f90
!
! The program should print teh square root of all odd numbers from 1 to n to two decimal places...
! Without use of intrinsic math function sqrt.
! Without regard to performance
Program OddSqrt
implicit none
real :: TheSquareRoot
real :: TheValue
integer :: n
integer :: cent
n = 10000 ! to be read in, however for this we will set the value
cent = 1
do TheValue = 1.0, n, 2 ! step odd numbers 1:n
do
TheSquareRoot = real(cent) / 100.0
if(TheSquareRoot * TheSquareRoot >= TheValue) then
print *, TheValue, TheSquareRoot
exit
endif
cent = cent + 1
end do
end do
end program OddSqrt
```

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

"Normal programmer". Hope that's me, I was a double major in math/computer science and have

spent the last 40 or so years doing mathematical modelling.

This whole thing reminds me of an assignment in one of my programming classes

Write the most efficient possible program to compute squares of integers from 1 to n.

My approach relied on that great old formula that everyone knows:

(n+1)^2 = n^2 + 2n + 1

so if you already know n and n^2, you just have to add 2n + 1 to get the next square.

And it's actually better to do 2n instead of n+n because multiplying an integer by 2 is a special case

handled as a bit shift operation.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

Criptogram,

John's description of the problem leaves plenty of leeway in the solution(s). To paraphrase: produce a table of square roots of odd numbers to 2 decimal places of the numbers 1 to n. Furthermore, to my understanding, his description is seeking to assemble various ways as opposed to a best solution.

Your description is but one, and could be the basis of a program you could provide. I caution that using n^2 + 2n + 1, any error introduced in any sequence of the series will be additive for each subsequent sequence in that series. Without corrective steps, that method would diverge in the direction of the first error.

FWIW my offered "solution" produces the closest value at the truncated value of the true square root. IOW closer numbers below are not considered. (a modified version would +0.005 to the expression).

Jim Dempsey

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

As Jim noted, the underlying problem is what is the probability given a specific language that two people will produce the SAME code.

So for a do loop what are the chances we use i as the counter and n as the end number - I bet it is really high.

mecej4 was really close to my test case.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

Do we use the same things in programming because of our teachers or human desire for tightness of code

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

>>*the underlying problem is what is the probability given a specific language that two people will produce the SAME code.*

That statement is one of those loaded interview questions where when you ask the interviewee for an accounting position "What is the value of two plus two", and where the sought answer is "whatever you want.".

The statement above has no basis for what the problem is, nor what the requirements are. John's initial problem was more qualified, but the general statement above is not.

John's field of work includes structural engineering, a subset of which includes computer modeling of bridges. Using the above query, barring plagiarism, the probability for two independently developed highway bridge modeling systems approaches 0.

When a problem statement leaves little to no wiggle room, then the probability may approach 1.

Example problem: *Write a program that produces the next integer value after the integer value N.*

The probability of the same code should be high, or at least 50% when half use (N + 1) and the other half use (1 + N). Though you may have some oddballs using INT(ceiling(N + 0.123)) just to obfuscate things.

Jim Dempsey

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

When a problem statement leaves little to no wiggle room, then the probability may approach 1.

My first problem statement, was correct except you had to input n.

The problem is one of, if you only have say 10 statements in a standard language for a standard problem - then in Fortran say it is a Prime Problem

line 1 is Program Prime ------ how many of us would do that

line 2 is implicit none ---------- how many of us would do that

line 3 integer i, n --------------- how many would do that

line 4 read n --------------- how many would do that

line 5 do loop i from 1 to n --------------- how many would do that

line 6 10 calculation - and printout , return end

So with a few lines, if 250 students wrote the program what is the probability that 2 are the same, except for the input and output description characters.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

@jimdempseyatthecove wrote:John's field of work includes structural engineering, a subset of which includes computer modeling of bridges. Using the above query, barring plagiarism, the probability for two independently developed highway bridge modeling systems approaches 0.

My first-ever customer visit as a DEC employee was to a structural engineering firm in Boston that was evaluating VAX as a replacement for an IBM system. I had been called in because their design program had produced wildly different results for a particular bridge model.

I eventually tracked it down to a loop that would develop a floating-point result, round it, and feed that back to the next iteration. For a particular operation, the result was exactly halfway between two representable values. The IBM system rounded one way, the VAX a different way. (Either one was correct.) It didn't help that the IBM system used the \360 "hex normalization", which meant that calculations could lose between 1 and 3 bits of precision in any operation. The customer eventually accepted my analysis.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

Steve's description of the structural problem is interesting. The current problem is we can measure frequencies very accurately and over a long time, so the statistical analysis reaches to 5 standard deviations, most engineering operates at 1 sometimes 2 sd. We have databases with 5 million records, each record 20 reals.

So the standard theories, developed by say Timonshenko work well at 1 to 2 sd level, for the first harmonic it does not work well at 5 sd across 500 Hz band. Our only choice is to relax the Timoshenko assumptions, and that makes the math really really hard.

So as we have now played with this data since 2007 and increased our knowledge, the only method to match beyond the first frequency is to use Stability Functions developed 2D in 1915, but not in 3D till 1989 and I have not found another implementation of the full 3d beyond the IFORT code I developed from Harrison's 2D code. We can now match the frequency set, so the Stability functions give us a more correct answer, but it still has errors, but they are lower order magnitude. One partial implementation exists in a German software, but it misses the critical element, it is akin to worshiping Yoga Berra as the great guru.

No design engineer in their right mind with a tight budget is going to use Stability Functions, they are to slow, but if we are to match reality we need to develop the code. 3D stability functions need a slow application of load and they can stop converging quickly, so you have to start again with a different parameter set, but we now know if they do not converge in 20 steps then they are likely to not converge and so you stop and try another. it is better to try 50 iterations of 20 steps and one converges than 1000 steps that do not converge. Same resources.

It is really only possible because of Pardiso IFORT and Eigensolver - the new fast one, whose name escapes me but it is from New England.

You could of course use Python and then wait a century.

JMN

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

And the only reason I could get the Stability Functions to work is because of the great people on this forum.

Thank you. I may jokingly call them the Titans, but one sees a long way because you stand on the shoulders of giants.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

While I cannot say that this is an issue with your convergence....

Assume you have your 100,000,000 reals, and you wish to do some sort of operation on them in aggregate. (these reals may compose related properties aX, aY, aZ, bX, bY, bZ, daX, daY, daZ, M, ...).

The SOP is to construct arrays of these properties, then use DO loops to process the data.

At issue with this is your external force(s), e.g. wheels rolling across the bridge do not have uniform magnitude across the bridge (until a quiescent state is achieved).

Operations between elements with large difference in magnitudes will induce large errors. Operations between elements with no/little difference in magnitudes will induce small(er) errors.

The (a) corrective measure is to perform the accumulative calculations from the smallest magnitude(s) to the largest magnitude(s). As to if you sort or bin the accumulations is a trade-off between performance and precision.

Jim Dempsey

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page