No announcement yet.

Optimize FOR-NEXT with Single Precision work?

  • Filter
  • Time
  • Show
Clear All
new posts

  • Optimize FOR-NEXT with Single Precision work?

    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).]
    Mike Luther
    [email protected]

  • #2
    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
    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.


    Michael Mattias
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]


    • #3
      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]
      Mike Luther
      [email protected]