Subject:
|
Re: 8-bit floating-point number representations?
|
Newsgroups:
|
lugnet.off-topic.geek
|
Date:
|
Sun, 7 Jan 2001 20:13:16 GMT
|
Viewed:
|
144 times
|
| |
|
|
Todd Lehman wrote:
> External tables could be any of:
>
> a) All 1's -- i.e., no effect (in implementation, this would probably simply
> bypass the actual multiply) -- table lookup disabled.
> b) Current article scores based on member feedback.
> c) Predicted article scores based on collaborative filtering.
> d) How close an article is to the top of its thread (might be 1.0's and 0.5's
> or any values 0.0 to 1.0).
> e) Some user-defined, user-specific function based on who posted an article,
> potentially useful for killfile-style filtering.
> etc. • <snip>
> Heck, if the integer range were restricted to [0,15], it could even be a
> 4-bit fixed-point number that gets looked up in an itty-bitty 64-byte table
> of 16 32-bit floating-point numbers or a 128-byte table of 16 64-bit
> floating-point numbers. As a bonus, that would also chop the size of the
> large memory-mapped file in half without sacrificing too much (I would hope)
> precision.
>
> My gut instincts tell me that a 16-level significance factor would be plenty
> for these purposes inside of a search.
Aah, with your external tables, 0 to 15 would work well. You don't even
need to scale it really since the output of your algorithm is just the
relative ranking of articles. It would be easy to generate a 0-15 rating
for the article ratings. For the "closeness to top of thread" you could
chose 15 for thread tops, and either decrement 1 for each post away from
the top, or go faster, or put it on some kind of curve. I don't have
Pentium II timings, but on a 486, loading a float into a co-processor
register is much faster than loading an integer, and it may be
advantageous to just directly multiply, which says that a 16 element
lookup table should be quite effective for either 4 bit or 16 bit
quantities, but overall, you should just try out bit twiddling and
lookups.
Frank
|
|
Message is in Reply To:
 | | Re: 8-bit floating-point number representations?
|
| (...) Well, basically, whatever is fast and flexible -- whatever that turns out to be. It might even turn out that a fixed-point representation is flexible enough and maybe even faster since it would involve only a single floating- point multiply by (...) (23 years ago, 7-Jan-01, to lugnet.off-topic.geek)
|
8 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
