HP3000-L Archives

April 2000, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Denys Beauchemin <[log in to unmask]>
Reply To:
Date:
Fri, 28 Apr 2000 10:35:30 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (86 lines)
I must disagree with you, numeric fields as search items definitely have their
place in IMAGE.  It is all a question of knowing when to use them.  As stated
earlier in the thread, there is a veritable plethora of articles and white
papers which have been written on the subject.

Here is a simple rule for the use of numeric keys.

If you can totally control the numeric key values that would be used as a key
in a master dataset, then by all means investigate the possibility of using
this key as a numeric key.  You may be able to have a data set with all
primaries, giving you 100% utilization if needed and the fastest access
possible.

If you cannot guarantee total control of the numeric key values or the keys are
alphanumeric, then forget about using a numeric key.

Kind regards,

Denys. . .

Denys Beauchemin
HICOMP
(800) 323-8863  (281) 288-7438         Fax: (281) 355-6879
denys at hicomp.com                             www.hicomp.com


-----Original Message-----
From:   Grunwald, Wyell C. [SMTP:[log in to unmask]]
Sent:   Friday, April 28, 2000 8:15 AM
To:     [log in to unmask]
Subject:        FW: Image hashing.

This is why you should not use numeric fields as search fields in IMAGE.

> -----Original Message-----
> From: Jerry Fochtman [SMTP:[log in to unmask]]
> Sent: Friday, April 28, 2000 8:54 AM
> To:   [log in to unmask]
> Subject:      Re: Image hashing.
>
> Previously I said:
>
> At 07:15 AM 4/28/2000 -0500, Jerry Fochtman wrote:
>  >IMAGE uses the 'right most' 32 bits if the size of the binary key field
> is
>  >4 bytes or greater.  If the key field is 2 bytes, these bytes are placed
> in
>  >the right 2 bytes of the calculation field and the left 2 bytes set to
> zero.
>  >The reason whole numbers in real type key items greater than 4 bytes in
> size
>  >(eg. E4, R4 or larger) generates lots of secondaries is because the
> mantisa
>  >portion of the field (right most bytes) tends to be a consistent (zero)
> and
>  >when used in the modulo calculation, derives the same address value.
>
> Sorry, but I had overlooked that its not simply real values > 4 bytes, but
> essentially all real values that can cause this type of problem.  This is
> because the use of the exponential technique to represent the value in
> powers
> of 2 does not lend itself to the possibility of deriving an even
> distribution
> over the area represented by the capacity. (Gosh its been a long time
> since
> I've dealt with number theory, statistical theory, etc...!)
>
>
>
> /jf
>                                _\\///_
>                               (' o-o ')
> ___________________________ooOo_(
> )_OOoo____________________________________
>
>                           Thursday, April 20th
>
>             Today in 1949 - Cortisone was discovered.
>
> ___________________________________Oooo___________________________________
> __
>                              oooO  (    )
>                             (    )  )  /
>                              \  (   (_/
>                               \_)

ATOM RSS1 RSS2