Velocity Reviews > Accessing array elements via floating point formats.

# Accessing array elements via floating point formats.

Andrew Reilly
Guest
Posts: n/a

 12-13-2010
On Sat, 11 Dec 2010 17:02:49 -0800, Andy \"Krazy\" Glew wrote:

> Terje mentiobned elsewhere in this string texture mapping - which is
> really an interpolation table using regular sample points.
>
> I have been wondering more and more about trying to make this into a
> more general purpose feature.

Indexing into an interpolation table or texture, linear interpolation
between two values, bitfield extraction or insertion (i.e., sub-word
addressing): there are quite a few useful things that could be done with
fractional addresses.

FWIW, regarding the OP's article: Matlab historically did everything (at
the user level) with double precision floats, including array indexes, as
does the "chicken" dialect of scheme. 52-bit integers that are
compatible with floating point numbers are fairly useful, if not
necessarily ideal.

Cheers,

--
Andrew

George Neuner
Guest
Posts: n/a

 12-13-2010
On Sat, 11 Dec 2010 17:02:49 -0800, "Andy \"Krazy\" Glew"
<(E-Mail Removed)-arch.net> wrote:

>On 12/11/2010 4:37 PM, George Neuner wrote:
>> On Sat, 11 Dec 2010 15:09:39 -0800, "Andy \"Krazy\" Glew"
>> <(E-Mail Removed)-arch.net> wrote:
>>
>>> By the way, there *ARE* instructions that can be used to access memory
>>> with addresses originally calculated in floating point.
>>>
>>> In C, you can do:
>>>
>>> float x = rand();
>>> int a[66];
>>> a[1] = a[ (unsigned)(x * 66) ];
>>>
>>> But if you note a possible buffer overflow here, well, that's another
>>> reason against FP addresses.
>>>
>>> Anyway... you *can* create addresses in FP: they just get converted to
>>> int, via compiler added instructions, before the memory reference.
>>>
>>> You would be well justified by saying that these instruction sequences
>>> are clunky, and often really, Really, REALLY slow. However, if they
>>> were used more often, they would probably be made faster.

>>
>> These kinds of FP->int sequences are used routinely for indexing into
>> interpolation tables. And there are a *LOT* of people who would be
>> happier if it could be done faster.
>>
>> George

>
>Terje mentiobned elsewhere in this string texture mapping - which is
>really an interpolation table using regular sample points.
>
>I have been wondering more and more about trying to make this into a
>more general purpose feature.
>
>The regular spatial sampling I think is a problem. Is it?

For table access the index value has to be (or be made) integral. I
suppose that some stride values could result in pathologically bad
cache behavior ... but if you're referring to something else then I'm
afraid I don't follow.
[There is, of course, the general FP issues with rounding and with
fixed size formats being unable to represent all values in the
interval.]

But the point of table lookup in any algorithm is to have part of the
answer precomputed. If the entire calculation can be done
sufficiently quickly, precomputing becomes unnecessary.

George

Malcolm McLean
Guest
Posts: n/a

 12-13-2010
On Dec 13, 6:55*am, George Neuner <(E-Mail Removed)> wrote:
>
> But the point of table lookup in any algorithm is to have part of the
> answer precomputed. *If the entire calculation can be done
> sufficiently quickly, precomputing becomes unnecessary.
>

Suppose we have a table of 100 values representing sine wave. We have
theta in a floating point.

By taking theta/2PI * 100 we can create an index into the sine table.
However this calculation isn't inherently integeral.
If we linearly interpolate between floor(theta/PI *100) and ceil(theta/
2PI * 100) we can get slightly more accurate results. If the hardware
does it automatically for us, we can get the results very quickly.

Noob
Guest
Posts: n/a

 12-13-2010
Andy "Krazy" Glew wrote:

> In C, you can do:
>
> float x = rand();

The rand() function returns a pseudo-random integer between 0 and RAND_MAX.

> int a[66];

OK.

> a[1] = a[ (unsigned)(x * 66) ];

Wait... What?!

> But if you note a possible buffer overflow here, well, that's another
> reason against FP addresses.

/Possible/ buffer overflow?
The buffer overflow is almost guaranteed, unless rand returned 0.
There's only 1 in RAND_MAX chances that the assignment reduces to
a[1] = a[0];

Skybuck Flying
Guest
Posts: n/a

 12-13-2010
Apperently sombody on google completely misunderstood how the fractional
part would be used to access individual bits. He's not in my outlook express
folder so he problably a troll.

None the less it's easy to see how people could missunderstand what the
fractional part does in this case so I will explain further.

The fractional part does not mean anything when it's between the brackets
therefore it can be used to give it a nother meaning.

Example:

vArray[ vIndex.8 ] = 1;

This would access the memory element at vIndex and set bit 8 to 1

Another example:

vArray[ vIndex.3 ] = 1;

This would access memory element at vIndex and set bit 3 to 1

Another example:

vArray[ 10.1 ] = 1;

This would access array element 10 and set bit 1 to 1

Therefore the dot operator loses it's meaning when it's inside the brackets.

That should be enough of a clarification.

One last clarification:

vArray[ 3.141592653 ]

Would either be bit 141592653 or invalid.

Personally I would like it if the bit index could also work beyond say
8,16,32, or 64...

So personally I would like it if it could be used to access any bit from any
base.

That would be very cool.

Bye,
Skybuck.

Skybuck Flying
Guest
Posts: n/a

 12-13-2010
Perhaps the notation could even be expanded to allow something like:

vArray[ vElementIndex.vBitIndex ]

Both could also be floating point numbers

However the last specifier vBitIndex cannot be extended any further.

if vElementIndex is a record then the dot operator will be given preference
to the field specifier... if it's a floating point or an integer than the
dot operator will be turned into a bit index specifier.

Bye,
Skybuck.

Skybuck Flying
Guest
Posts: n/a

 12-13-2010
> Apperently sombody on google completely misunderstood how the fractional
> part would be used to access individual bits. He's not in my outlook
> express folder so he problably a troll.

Concerning the potential troll... I cannot find his posting anymore... but
it doesn't matter... at least I clearified it a bit how I saw it

The nice thing is it doesn't matter how the floating point format works...
because we human beings can design the language to fit whatever we want...
so we don't have to use the fractional part for anything... and can give the
source code notation a different meaning.

Bye,
Skybuck.

luser- -droog
Guest
Posts: n/a

 12-13-2010
On Dec 13, 9:40*am, "Skybuck Flying" <(E-Mail Removed)>
wrote:
> Perhaps the notation could even be expanded to allow something like:
>
> vArray[ vElementIndex.vBitIndex ]
>
> Both could also be floating point numbers
>
> However the last specifier vBitIndex cannot be extended any further.
>
> if vElementIndex is a record then the dot operator will be given preference
> to the field specifier... if it's a floating point or an integer than the
> dot operator will be turned into a bit index specifier.
>
> Bye,
> * Skybuck.

I begin to see what you're getting at, but this all sounds much
more like C++. You don't need to futz with the types and index
operators to access bits.

And I really think you should pick one group to hold the discussion.
There's some old scientific addage about needless multiplication
which I think would apply if I could only remember it.

hopcode
Guest
Posts: n/a

 12-13-2010
Il 13.12.2010 10:09, Malcolm McLean ha scritto:
> On Dec 13, 6:55 am, George Neuner<(E-Mail Removed)> wrote:
>>
>> But the point of table lookup in any algorithm is to have part of the
>> answer precomputed. If the entire calculation can be done
>> sufficiently quickly, precomputing becomes unnecessary.
>>

> Suppose we have a table of 100 values representing sine wave. We have
> theta in a floating point.
>
> By taking theta/2PI * 100 we can create an index into the sine table.
> However this calculation isn't inherently integeral.
> If we linearly interpolate between floor(theta/PI *100) and ceil(theta/
> 2PI * 100) we can get slightly more accurate results. If the hardware
> does it automatically for us, we can get the results very quickly.
>
>
>
>

Wow, that's quite unknown to me the whole! I'll guess
it is a good way to draw abstract mathe near to a practical use,
because of the "naturality" of fp values.
Could someone among you provide asm/C reference sample source code to
study ?

BTW, i was wondering about the fractional part such as a method
to reindex colliding hash values.

Regards,

--

..::mrk::.
x64 Assembly Lab
http://sites.google.com/site/x64lab

Skybuck Flying
Guest
Posts: n/a

 12-14-2010

"Andy "Krazy" Glew" <(E-Mail Removed)-arch.net> wrote in message
news:(E-Mail Removed) ...
> On 12/13/2010 7:50 AM, Skybuck Flying wrote:
>>> Apperently sombody on google completely misunderstood how the fractional
>>> part would be used to access individual bits. He's not in my outlook
>>> express folder so he problably a troll.

>>
>> Concerning the potential troll... I cannot find his posting anymore...
>> but
>> it doesn't matter... at least I clearified it a bit how I saw it
>>
>> The nice thing is it doesn't matter how the floating point format
>> works...
>> because we human beings can design the language to fit whatever we
>> want...
>> so we don't have to use the fractional part for anything... and can give
>> the
>> source code notation a different meaning.
>>
>> Bye,
>> Skybuck.
>>
>>

>
> But, what about decimal versus binary floating point?

What about it ?

Screw decimals... computers work with binary !

Bye,
Skybuck.

 Thread Tools

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is OffTrackbacks are On Pingbacks are On Refbacks are Off Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post Saraswati lakki ASP .Net 0 01-06-2012 06:39 AM teeshift Ruby 2 12-01-2006 01:16 AM H aka N VHDL 15 03-02-2006 02:26 PM riya1012@gmail.com C Programming 4 02-22-2006 05:56 PM Motaz Saad Java 7 11-05-2005 05:33 PM

Advertisments