Ashingda 27,
Only had a bit of look at the snippet and seems the first comparisons to low/high are redundant, so Low and HIGH could be set the either R,G or B initially. Beyond that, we're just comparing the others to that point.
r = 100
g = 200
b = 50
// ------------------
// Original logic
// ------------------
Low = 255
High = 0
if r < Low then Low = r
if r > High then High = r
if g < Low then Low = g
if g > High then High = g
if b < Low then Low = b
if b > High then High = b
print low
print high
// ------------------
// Shuffle #1
// ------------------
// use the R value to set the low and high ranges
Low = r
High = r
// since low and high are now the same, check if G is lower, if so, then it can't be also be higher.
if g < Low
Low = g
else
if g>high then High = g
endif
if b < Low then Low = b
if b > High then High = b
print low
print high
// ------------------
// Shuffle #2
// ------------------
// use the R value to set the low and high ranges
Low = r
High = r
// check the G and B values for the lowest of the 2
if G<B
// run the compares on the low & highest markers
if G<low then low=G
if B>high then High=B
else
// run the compares on the low & highest markers
if B<low then low=B
if G>high then High=G
endif
print low
print high
sync
waitkey
In speed terms.. i dunno..shuffle #2 has less operations so it should be quicker, but that doesn't necessarily make it so, as such things are often compiler biased. It's temping to go the boolean expression approach also (as others have already shown), but I have my doubts how well that'd work in Dbpro.
If this type logic is going to be something that's to be called heavily, then it'd best to in line the logic into the main routine, rather than wrap it up into a function.
