Optimize FOR-NEXT with Single Precision work?

[Mike Luther]

Suggestion(s) please?

For the first time in my Basic work, I have hit a situation where I
need a FOR/NEXT loop that has to increment on Single Precicion numbers.
I need to scan a binary key field in a Julian Date file in which I
don't get to choose that this field is other than a Single Precision
variable. Duhh, what to do?

The worst case I would be able to use would be to start at a lowest
level for a Single Precision variable and ask the key to give me the
next upward record in the pile until we reach the upper limit for the
search, obviously a Single Precision number as well.

OK, as far as I know, PB can use Single Precision numbers in the logic
for the FOR/NEXT loop. But that's not, as I recall, the fastest and
best way to work with FOR/NEXT loops. We use integers to do this, or
at least that's the 'long and short' of this argument, grin!

Now .. This is all sorta silly anyway here in that a Julian Date is
going to be an integer anyway, as far as I know! Why couldn't this
field be a long instead? But if faced with the fact I can't change
this, now, how can I optimize the process?

Start with the INCREASING date case please as we think this through.
In that this is, at this point, an INCREASING scan, is there some way
I can write the loop so that I do the test for a match with a Single
Precision variable, yet increment the loop with an integer? Or, is
the way to do this with a WHILE-WEND technique and would that suffer
from the same inefficiency in the 'loop' there too as well? That as
it is handling floating point numbers too?

Now, before we finalize the suggestion, consider also the DECREASING
date process as well. In handling professional management templates
one really is more concerned, perhaps, on what happened at the latest
date and then a few before that, instead of what all the Dog dragged
in on the way to termination day!



The Julilan Date routines I have for everything I've ever done are
all coded into these Single Precision results. In looking at that,
I think the reason is that calculating them for leap year and so on
which was based on what focused on a solution that fell out of the
Single Precision techniques. That, all so long and far back that
this issue of not returning the final result as a Long Integer wasn't
obvious to me many years ago in the world of M/S PB7 before PB, sigh.

I've never had a comparator need for things like this until now.
We all have heard about painting one's self into a corner. Do I now
get to wear the Dunce Hat over this?

Why the concern if PB can handle Single Precision in FOR/NEXT loops?
Sadly, we are spoiled by the wonder of PowerBASIC here, folks. I've
thought about. 'What if you have to port this to "C" or Java for any
reason, Son?' My heart begins to beat a little faster with that thought
and maybe there is a way to code this in a more complex way now, but
one which would port easier later if The Force isn't with me!


Thanks ..


------------------
Mike Luther
[email protected]

[This message has been edited by Mike Luther (edited September 17, 2003).]

[Michael Mattias]

if the field is four bytes (single precision size), you can treat it as a long (also four bytes) using a union.

union f
 l as long
 s as single
end union
dim f1 as f, f2 as f

for f1.l = 1 to bignumber&
   f2.s = single value from key
   if f2.l = f1.l then
       match found
   end if
next

but if you are just looking for a "hit" on a single precision number against some table of valid values you might do better loading the data to an array and adapting..
binary search of an array february 14 2000, july 15 2003

that's nominally windows code - don't use the dos i don't trust it anymore - but there's nothing terribly windows-specific about it.

mcm

[Mike Luther]

Thanks MIchael ..

I've learned a lot from you .. and I realize that answering these posts
and those of others you have responded which I've followed takes real
effort. I appreciate the contributions you make.



------------------
Mike Luther
[email protected]