Paradox Community

Items in pnews.paradox-programming

Subject:Re: Locate Issue
Date:Sat, 5 Dec 2020 15:14:44 +0000
From:Michael Kennedy <Info@KennedySoftware.ie>
Newsgroups:pnews.paradox-programming
Steve,

A classic issue!

You/we treat the nnn.3, or nnn.5, etc, values as "powers of ten", but 
internally, these values are held as Floating-point, "powers-of-two" 
(IEEE, with low or high precision).

For almost all fractions (apart from a few very simple ones), most 
values in either of these representations has only an "approx" value in 
the other. For example, our "12.3" might be held internally as 
12.29999999123, or as 12.30000000123, but, visually, and for our 
convenience, might still appear on screens as 12.3 - unless we show the 
value to 8/10/12/15 decimal places, or unless we decode the actual Fl-Pt 
bits in the field (in the table record).

So, for example, if you're doing a search for 12.3, then:

   - If the search function is converting that 12.3 to Fl-point (say, 
12.300000222), and then checking it against all the Fl-Pt values on 
file, and the exact same conversion is used, you should get exact matches.

   - If the search function is converting the Fl-pt values on file to 
'decimal', it'll retrieve the value from the file, convert it to decimal 
(say, 12.300000222), and these will never exactly match the '12.3' that 
you've keyed.

As the others have said, you must avoid N fields if you're relying on 
exact matching of fractional parts, or your searching must be changed to 
accept "approx" matches - eg, if you type 12.3, then treat anything 
between, say, 12.29990000 and 12.30009999as as an 'exact' match.

Clear as mud?!

   - Mike


On 02/12/2020 05:30, Kevin Zawicki wrote:
> Build your own locate...
> 
> 
> maybe get the desired value (194314.3)
> then you know it is in the 194314 "series"
> 
> filter or query out to tcursor >194314 and less than 194315 to avoid a full
> scan
> 
> then loop and test each value rounding to 1 place...
> or  string to string (using substr)
> 
> then sync the tcursor or locate on anther field if possible
> 
> 
> you need to avoid rounding
> 
> 
> 
> 
> Mark Bannister <markRemove@THISinjection-moldings.com> wrote:
>> This is correct.  You should store this as alpha if you want this
>> functionality or break it into two fields.
>> Changing to alpha would be the easiest I would think.
>>
>>
>> On 12/1/2020 2:53 PM, Peter wrote:
>>> I'll bet it is a rounding problem. Try viewing the number that Pdox is
> 
>>> searching.
>>>
>>> I had a huge problem working with decimals, I ended having to create an
> 
>>> undefined field that awas formatted to 15 decimal places. I copy the
>>> number to that field and then read it, then everything behaves as expected.
>>>
>>> Peter
>>>
>>> On 12/1/2020 10:50 AM, Steve Levet wrote:
>>>> I have a table with numeric tracking for orders. The Ordernum field is
> 
>>>> N and
>>>> is the primary key. When orders are released which are not complete
>>>> any backordered
>>>> items are copied to a new record and the Ordernum is incremented by 0.1.
>>>> As an example I have an Ordernum of 194314.0, 194314.1, 194314.2,
>>>> 194314.3
>>>> and 194314.4. When I click locate and enter the .0, .1 or .2 number
>>>> the record
>>>> is found. However, any number above .2, eg 194314.3 or 194314.4 cannot
> be
>>>> found unless I select advanced pattern match. Any idea on why and how
> 
>>>> this
>>>> can be corrected so that I can find the Ordernums above .2?
>>>>
>>>> Thanks.
>>>>
>>>> Steve
>>>>
>>
>> -- 
>> Mark Bannister
>> 256-509-2052
>>
> 


Copyright © 2004 thedbcommunity.com