Post by sarossell on Dec 2, 2019 12:57:22 GMT -5
So, I was poking around on the Net late last night and I came across this blog entry from Carl dated September 19, 2019 entitled "Fractals in one page of code - Redux" at microcomputing.blogspot.com/2019/09/fractals-in-one-page-of-code-redux.html.
The blog entry included some code for a Mandelbrot set, and I'm always interested in stuff like that. I was also intrigued because the entry indicated that the code was specifically written for Liberty Basic 5. Cool!
So, I ran the code in LB5-350 and it ran fine. Very neat.
In the code, I noticed that the window handle didn't have a PRINT statement, so I decided to see how the code would run in LB 4. It didn't No surprises there. It's readily apparent that LB 5 isn't your Grandpa's LB 4. So, as a learning exercise, I took it upon myself to rewrite the code in LB 4 syntax.
BOY! Was I in over my head. I am not an experienced programmer. My career focused on Technical Writing, so my wheelhouse includes recognizing which language code is written in and weather the format looks correct; indenting, semi-colons, etc.
I did eventually get the code to work in LB 4...sort of. I found a handful of interesting challenges along the way I thought I'd share.
Now, of course, I realize LB 5 is still in alpha. I'm not nit-pickin'. These are just observations from an inexperienced programmer that, at the very least, might come in handy when writing the help files to point out how NOT to do things as a newbie.
Okay, so first thing, as I mentioned, LB doesn't need a PRINT command with window #handles.
LB 5:
#gr down()
LB 4:
print #gr, "down"
Second, LB 5 lets you do calculations within #handle commands while LB 4 insists on a cleaner, single variable (or just a literal string).
LB 5:
if c <> 0 then #gr set(x, y) : #gr set(x, 191-y)
LB 4:
huh$ = "set " + str$(x) + " " + str$(191-y)
dam$ = "set " + str$(x) + " " + str$(y)
if c <> 0 then print #gr, dam$ : print #gr, huh$
But then things started getting interesting...
LB 5 seems to calculate things differently depending on where the math occurs.
This (the original code):
c = i/2
#gr color(word$(color$, c + 1))
Does not work the same as this (the altered code):
c = (i/2)+1
#gr color(word$(color$, c))
{I altered the code because I noticed that the variable could be fractional (e.g., 2.5). And the word$ command needs an integer value...well, it does in LB 4 anyway.}
If you look in the image, you'll see that that the original version of the code produces a black horizon on the left while the altered code produces a solid red horizon.
"Well, duh. You altered the code, genius."
Granted, but the alteration should not be functionally different. But it is.
This becomes more readily apparent when you try the code in LB 4. The original code crashes because the variable feeds the word$ command a fractional value. If you force an integer value, it works.
Okay, so "c = (i/2) + 1" in LB5 seems to be forcing an integer value when it is used in the window #handle command, but if you wait and add the 1 later inside the command, it uses the calculated fractional value. Weird.
And finally, there's the image quality. Again, I realize we're in Alpha here. Also, I'm running LB 4 in Windows XP in Parallels on a Mac while running LB 5 native on the same Mac. So any of that could be the cause of this issue. But if you look at the comparison of the two images, you'll see that the LB 5 render is much more pixelated, while the LB4 image appears much smoother.
So, final observations? Well, Liberty Basic rocks, of course. Mr. Carl Gundel is a genius. And LB 5 is gonna be awe-SOME!
Hey! Thanks for readin' all this crap. Sorry for the lengthy message - Technical Writer; occupational hazard.
Many thanks!
-Scott :@)
Oh! And I had to change the number 20 to 19 in the LB 4 code, so it would stop looking for an eleventh color in the word$ list due to the calculation of c.