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).]
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).]
Comment