Oh, the forgotten joys of porting ancient FORTRAN code to SDL.

"go to 10"   (ouch.)

I feel like I'm 12 years old using a school TRS-80 again.


It will be a minor miracle if I can get this to work in the next week.

Post a reply to this message

Attachments:
Download 'hyper_2f1_fortran.txt' (27 KB)

On 2024-06-22 20:37 (-4), Bald Eagle wrote:
> 
> Oh, the forgotten joys of porting ancient FORTRAN code to SDL.
> 
> "go to 10"   (ouch.)
> 
> I feel like I'm 12 years old using a school TRS-80 again.
> 
> 
> It will be a minor miracle if I can get this to work in the next week.

Hey, at least it's not Fortran IV.

Although, DO WHILE was already part of the Fortran standard when this
code was written, so I'm a little surprised to see GO TO in there.

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:

> Hey, at least it's not Fortran IV.

I don't recall seeing any of that - what year was that?

The last thing I tried to convert was Fortran90,  This, I believe is Fortran77.

> Although, DO WHILE was already part of the Fortran standard when this
> code was written, so I'm a little surprised to see GO TO in there.

Update:
Although we've played a bit recently with some complex number math with regard
to the Apollonian gasket, I needed quite a few more functions to do everything
required for this algorithm.  So I now have 19 macros to do +, -, *, /, ^, =, as
well as mixed complex / real operations, and stuff like conjugate, abs, log,
sqrt, and argument.

The macro runs from lines 517 to 1044, and although Fortran had inbuilt complex
number handling back in 1977, we don't have that in POV-Ray (yet).  So I had to
go through and replace all of the simple / naive operators with a few extra
lines of code calling the aforementioned complex number macros.

I still have to pick through to make sure my indenting is correct (all of the
#end directives ought to be intact, though not properly indent-aligned) and then
code my way out of the handful of GO TO statements.

Then I'll probably "just" need to clean up some floating mixed-number type
operations and whatever else trips the parser.

Then I can see if it does anything proper and useful.


I do believe that all of this somehow started with some of the mathematical
greats trying to compute the perimeter of an ellipse.  Which gave us elliptic
integrals, and then elliptic functions, and then hypergeometric functions....

- BE

Post a reply to this message

2nd update:

I hacked my way through the 500+ lines of code, and left a trail of debugging
statements and "fixes".

zw is a complex variable that gets used but never assigned a value.   :|
Psi is a function that gets called, but the return value is never used.
Converting all of the #locals to #declares in the entire file doesn't alter any
global variables when Psi is called.
The argument to a certain Gamma function always winds up being negative, and
Gamma doesn't take negative arguments.

I tracked my values and finally restricted everything to +/- 10, and got 3
radial lines - - - that I recognized when implementing a "cheap" little gamma
approximation.

https://cplusplus.com/forum/general/255896/#msg1120994

So, having absorbed more know-how and with the necessary macros in hand, I
slightly altered it to take a complex Z argument, and got the same pattern.
Then I added a lot more points, and got my triangles!
Mostly.

The shapes are triangular, but they have that weird wiggle.

Anyway, it's a heck of a lot farther than I thought I'd make it for a weekend of
coding.

- BE

Post a reply to this message

Attachments:
Download 'hypergeometric conformal mapping.png' (165 KB)

Preview of image 'hypergeometric conformal mapping.png'

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> 2nd update:
> ...
> The shapes are triangular, but they have that weird wiggle.

maybe it's just me, but I think the "wiggle" makes all the difference.  (think
"serendipity" </grin>)


regards, jr.

Post a reply to this message