Lazarus programming- kid/ hobbyist accessible

Facebook If you like this page, please tell others by clicking the icon! (Or via the social media platform you like… see top edge of page)

Playing with Lazarus, the wonderful free, open-source, multi-platform IDE with a resemblance to Delphi as it was before Bill Gates and the financial "wizard" at Borland destroyed the company! THIS page started 21 Jun 20, for now only a shameless plug for Help with enjoying Lazarus

Great editor shortcuts summary…

… at https://www.freepascal.org/docs-html/current/user/userse32.html

("Freepascal" is the home of the open-source group behind the Pascal behind Lazarus.)

I know and love ctrl-Y… delete the current line.

If I could remember to use ctrl-K-L… select all of the current line, I'm sure I'd grow to love it.

It harks back to the days of Turbo Pascal, for my fellow sentimentalists!

Can you believe that I had a 1990 Turbo Pascal MANUAL… Ink-on-paper… about 10" of shelf space… sitting on a shelf eight steps from where I was sat writing this? "Selecting" was a much more tedious business in those pre-Windows (for Borland Pascal) days! But ctrl-k-(+something, like L) was how you "did things" to selected material. Selected material was called a "block" in those far off days.

New trick with rems for debugging

Ever put something like…

for bCountFillArrays:=0 to 4 do begin
     showmessage(bMyArray[iCounter]);
     end;

… into some code, to help you see what was going on?

I do, all the time. And I hate deleting things I might want again later.

So I would use …

(*for bCountFillArrays:=0 to 4 do begin
     showmessage(bMyArray[iCounter]);
     end;
*)

Except, if I were clever, I'd do this..

//(*for bCountFillArrays:=0 to 4 do begin
     showmessage(bMyArray[iCounter]);
     end;
//*)

That little fragment of code can be reactivated simply by removing the "//" in front of the "(*", can't it?!

(Of course, if I would just learn to use watches and breakpoints, I wouldn't need such clumsy things!!)

ARGH!

JUST ONCE, I used a system function.. and it FAILED me. And I was so trusting that I assumed the mistake was eslewhere in the 5,000 lines concerned…

showmessage(inttohex(ColorToRGB($123456),6)+'XXX'+inttohex($ABCDEF,6));

"Should" give 563412XXXABCDEF… Lazarus "colors" are BBGGRR, interally.

And "ColorToRBG" is SUPPOSED to give you a string representing a color, in RGB… but it DOESN'T… as demonstated above!!

Scaling… you'll need it again and again…

Bear with me… we'll get to what this has to do with programming in a moment…

Remember 5th grade? Did you learn the algebra for "solving for x"? wojder what you'd ever use that for?

Everyday (for some people!) example: 3 cups of pool bleach powder is enough for 10,000 gallons, how much do you need for a 20,000 gallon pool. If you need algebra for that, how much is right for a 20,000 gallon pool? (If you need algebra for that, you can stop reading now… if you got that far!). Not so easy: How much, exactly, for a 16,800 gallon pool? Yes! Of course, "about" 5 cups… but.. exactly?

These problems always have four parts: Two numbers that got together in one situation, two that go together in a different situation. In this case, call them KnownGoodMixBleach and KnownGoodMixWater and WantedSituationBleach and WantedSituationWater.

You will know the numbers for three of them, and algebra will give you the fourth.

In our example….

KnownGoodMixBleach (KnoGoodB)=3
KnownGoodMixWater(KnoGoodW)=10,000
WantedSituationBleach(WantB)=?
WantedSituationWater(WantW)=15,800

Arrange those in pairs on two sides of an equals sign. On each side, put one above the other, with a line between them, to say "divided by".

On the left side the pair where you do NOT have both numbers. Put the one you don't know on top.

On the right the pair where you have BOTH numbers. The one that corresponds to the one you don't know goes on top here, too.

That's the general rule. In our example, that would be…

KnoGoodB         ?
--------   =  -------    
KnoGoodW       WantW

Replace the things in letters… the "variables", in algebra's terminology… with numbers…

    3             ?
--------   =  --------    
 10,000        15,800

Do the bit of arithemetic that you can…

                 ?
 0.0003   =  --------    
              15,800

Now for the "big trick"….

You can get rid of the "divided by 16,800" on the right if you // ** multiply**// the 0.0003 on the left by… 16,800!

0.0003 x 15800= 4.74

So!…

4.74 = ?

… you'd need 4.74 cups of bleach.

Note that I did an estimate before I started.

The answer I got with my algebra is close to what my estimate was, so I can hope that I didn't make too big an error in my algebra.


What has this got to do with programming?…

Scaling20625-1100-tut.png

I was working on a program for drawing a graph. It was of several weather data. (See FarWatchWatcher).

I knew the upper horizontal green line (Marked "100" under column heading "A") represented 100% relative humidity.

I wanted to know what the lower straight horizontal green line represented ("?1") and what the bottom edge of the graph ("?3")represented.

To get the answsers to those questions…

Getting the answers to those questions is all done by the simple "know 3, work out the fourth" trick shown above. But you have to go through several steps…

First, note…

In "A" we have labels for various things on the graph. In DFB we have "Distances from Bottom", in mm when the graph is displayed with IrfanView, with 300% enlargement… on my monitor, anyway!…

"100" in A is 102.5 mm from the bottom of the graph.

"?4" in A is 33.5 mm from the bottom of the graph.

The numbers in "S" are what the raw sensor readings were which produced the lines referenced.

"100" in "A" (the relative humidity, as a % ("per cent"… "parts per hundred") came from a faked sensor, which always returned "999"… parts per thousand, aka "percent times 10".

"?4" in "A" came from readings of 530. That sensor happens to report in parts per thousand.

We have enough to work out what relative humidity is shown by the cyan line at "?4"!

The formula, by the rules above, is…

  100         ?4
--------  =  -----    
 102.5        33.5

… and applying the algorithm given the answer is that that line represents 32.7%… which we know is wrong. I hope you didn't catch my mistake before now, and struggle needlessly? How do we know the answer is wrong??

How do we know it is wrong?? As I told you: The sensor REPORTS IN % x 10. ?4 MUST represent 53.0.

Where did we go wrong, then??

We used distances from the bottom of the graph. These "get the fourth from 3 knowns" problems can only be solved that way if all the numbers are from a common 0.

For example: To use "4thFrm3", as I'll call it from now on, to calculate degrees Celcius from degrees Fahrenheit, we need to make an adjustment to one or the other first.

I'll adjust the Fahrenheit, because I Just Know that 32 °F is 0 °C.

Each time I head for the 4thFrm3 rule to convert F to C, I start by taking 32 off of the F tture, so that the two numbers I'm dealing with are from a common zero. I also need to know that 100 °C is 212 °F. Let's say I want 97 °F in Celcius degrees. (I chose that because I happen to know that healthy humans are about 98 °F/37 °C, so I will be able to spot an answer that comes from a flawed algorithm. (The mistake I made earlier was actually a mistake, I didn't to that just to show you how you might go wrong.)

          100(°C)                             ?
----------------------------------------  =  -------    
 212-32(°F after you take off the 32)       97-32

That comes to 36.1.. which worried me slightly, so I went off to Wikipedia. They say that healthy humans arw 36.5–37.5 °C, and they say that is 97.7–99.5 °F. So "my" human in C is about right, "my" F is a little low.. so it no longer alarms me that I get a "low" "normal human in C", if I work from my "normal human in F".

This isn't JUST a rambling digression. It… and the next little bit!… illustrates how you should always be checking what you get by "method A" with a "method B".

Having got as far as I have… what's one more "check" I should do? There's nothing more to look up or calculate.

Yes! If, by my calculation 98defF is 36.1 °C, does that "fit" with the limits indicated in Wikipedia's "36.5–37.5 °C / 97.7–99.5 °F"? Yes! My starting point, 97 °F, is slightly below Wikipedia's range, as is, as it should be, our numbers in °C. Hurrah!

right! Back to the scaling of the graph…

THERN ARE PEOBEMS IN THE REST AT THE MOMENT!! 25 Jun 2020, 16:07..((UK)…. but I'm working on it!!…

We asked the wrong first question.

We should have asked: "When the graph is draw at this scale, how "high" is 1% of relative humidity, in mm?

We get that from the distance BETWEEN ?4 and "100".. because ?4 represents 53%… which we know because the sensor returns values in % x 10.

?4 to "100" is 69 mm (102.5-33.5) and represents 47 percentage points (100-53).

So, using 4thFrm3..

  69         (How high 1% is)
--------  =  -----    
 47        1

.. which gives: 1.4680 mm on the graph, as drawn when I took those measurements, represents 1 % point.

From that we can get most of the other things we wanted…

The bottom edge of the graph (?3) (at, by definition, "0"mm DfB) is 33.5 mm below ?4. We just "worked out" (realized!) that ?4 represents 53%. so the degrees between ?4 and ?3, as a %, is…


1 (Diff, in %, ?4-?3)
-- = -
1.4680 33.5
[[/code]]
.. so the bottom edge of the graph must represent 49.18%.

The not-so-very-much-brighter than average readers among you will have notice intuitively that the answer was simply 33.5 x 1.468. I suspected there was an easy way, but after hours of struggling with this… and with collecting the data, preparing the images, getting the code laid out nicely… my brain is mush. Notice that even when your brain is mush 4thFrm3 will get you there!

Something I haven't mentioned…

I haven't said it explicitly, but I would guess you already "know" this: The graph line "wraps around" to the top, if you go off the bottom of the page.

So ?2 comes from a reading of less than 49.2%… this answer just from looking at the graph.

We already knew that ** in this case**! We knew it is at 47.6 from the raw numbers from the sensors. They are always available, but are never particularly easy to access.

As a check.. and you know by now that I think checking is important.. do we get the "right number" for ?2 using numbers from the graph?

The top of the graph, after a wrap, represents 49.2%. (49.19999, if you like.)

Because it is "wrapped", ?2 is, in effect, 15mm xxxx mm below the bottom edge of the graph. (That's how far it is below the top of the graph, which seemed the logical way to measure it, when I made the graphic 2 hours ago.)

But we don't know how high the graph is, which would have been helpful. Nevermind.

Remember that with 4thFrm3, we need everything to work from the same zero? In what follows, "100", where the line is 102.5 above the bottom of the graph, and where we show "100%", wil be our "0".

?4 is 69mm (102.5-33.5) below "100".

?4 represents 53%. 53% is 47% below 100.

?2 is effectively 48.5mm (102.5+33.5+15) below f4.

We said that 1.4680 mm on the graph represents 1 % point.

So, we start to calculate the % represented by ?2's level with.. []

[[/code]]
47.0 n
-- = -
33.5 151.0
[[/code]]

n tells us how far below 100% the level represented by ?2 is. It comes to 68.0

.. so ?2 must represent 32% (100-68.0).

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License