+- QB64 Phoenix Edition (https://qb64phoenix.com/forum)
+-- Forum: QB64 Rising (https://qb64phoenix.com/forum/forumdisplay.php?fid=1)
+--- Forum: Code and Stuff (https://qb64phoenix.com/forum/forumdisplay.php?fid=3)
+---- Forum: Help Me! (https://qb64phoenix.com/forum/forumdisplay.php?fid=10)
+---- Thread: Calculating the High and Low of it all (/showthread.php?tid=984)
Pages:
1
2
RE: Calculating the High and Low of it all - SMcNeill - 10-19-2022
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.
RE: Calculating the High and Low of it all - Dimster - 10-19-2022
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.
RE: Calculating the High and Low of it all - bplus - 10-19-2022
I would get rid of _Round and look at numbers as strings.
https://qb64phoenix.com/forum/showthread.php?tid=644&pid=4162#pid4162
RE: Calculating the High and Low of it all - SMcNeill - 10-19-2022
(10-19-2022, 01:29 PM)Dimster Wrote: 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.
RE: Calculating the High and Low of it all - Pete - 10-19-2022
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,.09399Now 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
RE: Calculating the High and Low of it all - Dimster - 10-19-2022
Yes, you guys are right ... the _round has to go