Calculating the High and Low of it all

[SMcNeill]

HL = DataBaseValue
        If HL < Low Then Low = (_Round(HL * 100000)) / 100000
        If HL > High Then High = (_Round(HL * 100000)) / 100000


And *before* your DO-LOOP where you check those values, initialize the high/low variables.

LOW = *max variable value*
HIGH = *min variable value*

So for an unsigned byte, LOW = 255: HIGH = 0.  For an unsigned integer, LOW = 65535: HIGH = 0.

This way *any* database value will be less than LOW, setting it to the database limit, while the same is true with the HIGH.

[Dimster]

Pete - I reside at the North Pole and generally wear a red suit. If the Fellas show up I'll have a little help to deal with them.

Boy, once again, some great info on dealing with High and Low. I have found an issue with zero (0). All the data being compared is (or supposed to be) in a 5 digit decimal. ( ie .33333, .21907, .87778 etc) Somewhere along the line that rounding is kicking out a zero which seems to be messing up the results. So much data to go thru I haven't found the culprit yet.

[bplus]

I would get rid of _Round and look at numbers as strings.
https://qb64phoenix.com/forum/showthread...62#pid4162

[SMcNeill]

Pete - I reside at the North Pole and generally wear a red suit. If the Fellas show up I'll have a little help to deal with them.

Boy, once again, some great info on dealing with High and Low. I have found an issue with zero (0). All the data being compared is (or supposed to be) in a 5 digit decimal. ( ie .33333, .21907, .87778 etc) Somewhere along the line that rounding is kicking out a zero which seems to be messing up the results. So much data to go thru I haven't found the culprit yet.

Honestly, I wouldn't round at all.  Data out should equal data  in, in my opinion.

[Pete]

Watch your back on Dec 25th. If your milk comes with cookies called biscottis, you might just wish you brought your elf gang along for the ride!

Dim,

Make sure the code you are using assigns a value to "low" or what's happening is low, by default, will always be zero. The else statement, in my example, handles that condition. If that's not the case and the _round statement is causing it to be zero, try removing it, but if you do, the number format will likely be reported in scientific notation.

If you want to convert to string comparisons, and have all positive numbers that are ALL 5-digits, just do something like one of these two examples...

Code: (Select All)

FOR i = 1 TO 10
    READ DataBaseValue
    HL$ = LTRIM$(STR$(DataBaseValue))
    IF HL$ < low$ OR i = 1 THEN low$ = HL$
    IF HL$ > high$ OR i = 1 THEN high$ = HL$
NEXT
PRINT "DEMO 1: Low = "; low$; "  High = "; high$
PRINT

RESTORE
FOR i = 1 TO 10
    READ DataBaseValue
    HL$ = LTRIM$(STR$(DataBaseValue))
    IF VAL(HL$) < VAL(low$) OR i = 1 THEN low$ = HL$
    IF VAL(HL$) > VAL(high$) OR i = 1 THEN high$ = HL$
NEXT
PRINT "DEMO 2: Low = "; low$; "  High = "; high$

DATA .23675,.47623,.15345,.02365,.93456,.45637,.83423,.69374,.73214,.09399

Now if you have anything in your database that is more or less than 5-digits, negative decimals, or decimal numbers greater than 1, then the string comparison is no longer simple, and you would either have to use the second demo and test to see if the VAL() conversion holds up, or modify the first example to include a string comparison sub-routine, about 40 lines, to make accurate greater less than comparisons.

Pete

[Dimster]

Yes, you guys are right ... the _round has to go