floating point problems?

[Gernot Frisch]

Hi,

does repeatingly doing this:

float num = GetRandomFloat( );
for(;;)
{
float random = GetRandomFloat( );
num*=random;
num/=random;
}

Will num stay the same?
What can I do to make it stay the same (FixFloat(&rand om) e.g?)

--
-Gernot
int main(int argc, char** argv) {printf
("%silto%c%cf%c gl%ssic%ccom%c" , "ma", 58, 'g', 64, "ba", 46, 10);}

_______________ _______________ __________
Looking for a good game? Do it yourself!
GLBasic - you can do

https://www.GLBasic.com

[Jacek Dziedzic]

Re: floating point problems?

Gernot Frisch wrote:[color=blue]
> Hi,
>
> does repeatingly doing this:
>
> float num = GetRandomFloat( );
> for(;;)
> {
> float random = GetRandomFloat( );
> num*=random;
> num/=random;
> }[/color]

What about when num*random > maximum float?
Also, random == 0.0 gives you a floating division by zero.

And num will not stay the same because of precision losses.

- J.

[Gernot Frisch]

Re: floating point problems?


"Jacek Dziedzic" <jacek__NOSPAM_ _@janowo.net> schrieb im Newsbeitrag
news:cncfbu$p8n $1@korweta.task .gda.pl...[color=blue]
> Gernot Frisch wrote:[color=green]
>> Hi,
>>
>> does repeatingly doing this:
>>
>> float num = GetRandomFloat( );
>> for(;;)
>> {
>> float random = GetRandomFloat( );
>> num*=random;
>> num/=random;
>> }[/color]
>
> What about when num*random > maximum float?
> Also, random == 0.0 gives you a floating division by zero.[/color]

Taken care of that.
[color=blue]
> And num will not stay the same because of precision losses.[/color]

That's my question: Is there any way to make "random", so that
precision losses it not of any interest?

[Jacek Dziedzic]

Re: floating point problems?

Gernot Frisch wrote:[color=blue]
> "Jacek Dziedzic" <jacek__NOSPAM_ _@janowo.net> schrieb im Newsbeitrag
> news:cncfbu$p8n $1@korweta.task .gda.pl...
>[color=green]
>>Gernot Frisch wrote:
>>[color=darkred]
>>>Hi,
>>>
>>>does repeatingly doing this:
>>>
>>>float num = GetRandomFloat( );
>>>for(;;)
>>>{
>>> float random = GetRandomFloat( );
>>> num*=random;
>>> num/=random;
>>>}[/color]
>>
>> What about when num*random > maximum float?
>> Also, random == 0.0 gives you a floating division by zero.[/color]
>
>
> Taken care of that.
>
>[color=green]
>> And num will not stay the same because of precision losses.[/color]
>
>
> That's my question: Is there any way to make "random", so that
> precision losses it not of any interest?[/color]

What I don't understand is why you insist on first multiplying
num by random, only to divide it by random a moment later? It's
not clear for me what you are trying to do. Do you simply want
to generate random float numbers within a certain range? It seems
not, because supposedly GetRandomFloat( ) does this for you.
So what are you trying to achieve?

- J.

[John Harrison]

Re: floating point problems?


"Gernot Frisch" <Me@Privacy.net > wrote in message
news:2vu153F2o6 jvsU1@uni-berlin.de...[color=blue]
>
> "Jacek Dziedzic" <jacek__NOSPAM_ _@janowo.net> schrieb im Newsbeitrag
> news:cncfbu$p8n $1@korweta.task .gda.pl...[color=green]
>> Gernot Frisch wrote:[color=darkred]
>>> Hi,
>>>
>>> does repeatingly doing this:
>>>
>>> float num = GetRandomFloat( );
>>> for(;;)
>>> {
>>> float random = GetRandomFloat( );
>>> num*=random;
>>> num/=random;
>>> }[/color]
>>
>> What about when num*random > maximum float?
>> Also, random == 0.0 gives you a floating division by zero.[/color]
>
> Taken care of that.
>[color=green]
>> And num will not stay the same because of precision losses.[/color]
>
> That's my question: Is there any way to make "random", so that precision
> losses it not of any interest?[/color]

Yes

float num = GetRandomFloat( );
for(;;)
{
float random = GetRandomFloat( );
float save_num = num;
num*=random;
num = save_num;
}

Likely to be more efficient too, and clearer code.

john

[Karl Heinz Buchegger]

Re: floating point problems?

Gernot Frisch wrote:[color=blue]
>
> "Jacek Dziedzic" <jacek__NOSPAM_ _@janowo.net> schrieb im Newsbeitrag
> news:cncfbu$p8n $1@korweta.task .gda.pl...[color=green]
> > Gernot Frisch wrote:[color=darkred]
> >> Hi,
> >>
> >> does repeatingly doing this:
> >>
> >> float num = GetRandomFloat( );
> >> for(;;)
> >> {
> >> float random = GetRandomFloat( );
> >> num*=random;
> >> num/=random;
> >> }[/color]
> >
> > What about when num*random > maximum float?
> > Also, random == 0.0 gives you a floating division by zero.[/color]
>
> Taken care of that.
>[color=green]
> > And num will not stay the same because of precision losses.[/color]
>
> That's my question: Is there any way to make "random", so that
> precision losses it not of any interest?[/color]

If your question is: Is there a way to get the benefits
of floating point arithmetic while avoiding the precission loss
then the answer is: no.

The reason is simple: A genious once proved that there is an infinite
amount of rational numbers between 0 and 1. You can't represent an infinite
amount of numbers with a finite amount of bits.
So the problem with floating point numbers is system imanent and there is
nothing you can do about it. Live with it.

--
Karl Heinz Buchegger
kbuchegg@gascad .at

[Lionel B]

Re: floating point problems?

Gernot Frisch wrote:[color=blue]
> Hi,
>
> does repeatingly doing this:
>
> float num = GetRandomFloat( );
> for(;;)
> {
> float random = GetRandomFloat( );[/color]

[color=blue]
> num*=random;
> num/=random;[/color]

What on earth is this supposed to achieve?
[color=blue]
> }
>
> Will num stay the same?[/color]

No, because of loss of precision.
[color=blue]
> What can I do to make it stay the same (FixFloat(&rand om) e.g?)[/color]
Omit the lines:

num*=random;
num/=random;


--
Lionel B

[Karl Heinz Buchegger]

Re: floating point problems?

Gernot Frisch wrote:[color=blue]
>
> "Jacek Dziedzic" <jacek__NOSPAM_ _@janowo.net> schrieb im Newsbeitrag
> news:cncfbu$p8n $1@korweta.task .gda.pl...[color=green]
> > Gernot Frisch wrote:[color=darkred]
> >> Hi,
> >>
> >> does repeatingly doing this:
> >>
> >> float num = GetRandomFloat( );
> >> for(;;)
> >> {
> >> float random = GetRandomFloat( );
> >> num*=random;
> >> num/=random;
> >> }[/color]
> >
> > What about when num*random > maximum float?
> > Also, random == 0.0 gives you a floating division by zero.[/color]
>
> Taken care of that.
>[color=green]
> > And num will not stay the same because of precision losses.[/color]
>
> That's my question: Is there any way to make "random", so that
> precision losses it not of any interest?[/color]

Make it double instead of float?

Seriously: Until you know exactly what you do AND you know what
is awaiting you AND you are willing and have the knowledge to fight
that beast AND there is not a very, very, very good reason: forget
that data type float exists and use double instead.

The 'floating point problem' is still there with double, but it
is much smaller. Small enough that with a little bit of care it
can be ignored in practice (except for comparisons, of corse).

--
Karl Heinz Buchegger
kbuchegg@gascad .at

[Gernot Frisch]

Re: floating point problems?

>> float num = GetRandomFloat( );[color=blue][color=green]
>> for(;;)
>> {
>> float random = GetRandomFloat( );[/color]
>
>[color=green]
>> num*=random;
>> num/=random;[/color]
>
> What on earth is this supposed to achieve?[/color]

float scale = GetScalingForCa rtoonOutlines() ;
for(int i=0; i<afewthousandt riangles; ++i)
{
ScaleVertex(pVe rtices[i], scale);
}
glDrawElements( pVertices, afewthousandtri angles);
scale=1.0f/scale;
for(int i=0; i<afewthousandt riangles; ++i)
{
ScaleVertex(pVe rtices[i], scale);
}

The other way would be to have an additional "afewthousandtr iangles"
array of data that I don't really need.

Thx anyway,
-Gernot

[Karl Heinz Buchegger]

Re: floating point problems?

Gernot Frisch wrote:[color=blue]
>[color=green][color=darkred]
> >> float num = GetRandomFloat( );
> >> for(;;)
> >> {
> >> float random = GetRandomFloat( );[/color]
> >
> >[color=darkred]
> >> num*=random;
> >> num/=random;[/color]
> >
> > What on earth is this supposed to achieve?[/color]
>
> float scale = GetScalingForCa rtoonOutlines() ;
> for(int i=0; i<afewthousandt riangles; ++i)
> {
> ScaleVertex(pVe rtices[i], scale);
> }
> glDrawElements( pVertices, afewthousandtri angles);
> scale=1.0f/scale;
> for(int i=0; i<afewthousandt riangles; ++i)
> {
> ScaleVertex(pVe rtices[i], scale);
> }
>
> The other way would be to have an additional "afewthousandtr iangles"
> array of data that I don't really need.[/color]

But you need it (see later).
It always a good idea to reserve memory for temporary results
if you then can avoid modifying the originals.

As for your specific problem. It is alwas a good idea
to know the toolkit you are working with.

glPushMatrix();
glScalef( 1.0 / scale, 1.0 / scale, 1.0 / scale );
glDrawElements( pVertices, afewthousandtri angles );
glPopMatrix();

Does the very same as your mumbo jumbo 2 loop solution.

--
Karl Heinz Buchegger
kbuchegg@gascad .at

[Karl Heinz Buchegger]

Re: floating point problems?

Karl Heinz Buchegger wrote:[color=blue]
>
> Gernot Frisch wrote:[color=green]
> >[color=darkred]
> > >> float num = GetRandomFloat( );
> > >> for(;;)
> > >> {
> > >> float random = GetRandomFloat( );
> > >
> > >
> > >> num*=random;
> > >> num/=random;
> > >
> > > What on earth is this supposed to achieve?[/color]
> >
> > float scale = GetScalingForCa rtoonOutlines() ;
> > for(int i=0; i<afewthousandt riangles; ++i)
> > {
> > ScaleVertex(pVe rtices[i], scale);
> > }
> > glDrawElements( pVertices, afewthousandtri angles);
> > scale=1.0f/scale;
> > for(int i=0; i<afewthousandt riangles; ++i)
> > {
> > ScaleVertex(pVe rtices[i], scale);
> > }
> >
> > The other way would be to have an additional "afewthousandtr iangles"
> > array of data that I don't really need.[/color]
>
> But you need it (see later).
> It always a good idea to reserve memory for temporary results
> if you then can avoid modifying the originals.
>
> As for your specific problem. It is alwas a good idea
> to know the toolkit you are working with.
>
> glPushMatrix();
> glScalef( 1.0 / scale, 1.0 / scale, 1.0 / scale );[/color]

Sorry, obviously must read:

glScalef( scale, scale, scale );

[color=blue]
> glDrawElements( pVertices, afewthousandtri angles );
> glPopMatrix();
>
> Does the very same as your mumbo jumbo 2 loop solution.
>[/color]

--
Karl Heinz Buchegger
kbuchegg@gascad .at

[Gernot Frisch]

Re: floating point problems?

[color=blue]
> glScalef( scale, scale, scale );[color=green]
>> Does the very same as your mumbo jumbo 2 loop solution.[/color][/color]

Unfortunately not, I've got to scale the vetices along their normal
directions, which makes this a bit expensive. I've decided to
implement a temp-buffer for each object now, thank you.

[Karl Heinz Buchegger]

Re: floating point problems?

Gernot Frisch wrote:[color=blue]
>[color=green]
> > glScalef( scale, scale, scale );[color=darkred]
> >> Does the very same as your mumbo jumbo 2 loop solution.[/color][/color]
>
> Unfortunately not, I've got to scale the vetices along their normal
> directions, which makes this a bit expensive. I've decided to
> implement a temp-buffer for each object now, thank you.[/color]

OK. If the center of scale is not identical for all points,
then thats the best solution.

That's one of the great principles in graphics:
Don't accumulate errors!

Eg. you want to rotate something in 0.1 degree steps for
a full circle:

Don't do

for( double alpha = 0; alpha < 360.0; alpha += 0.1 ) {
// apply the angle

But do:

for( int i = 0; i < 3600; ++i )
alpha = i * 0.1;

So why is the second better?
Because in the first loop, the error of the first addition
will be distibuted to the second addition which in turn will
influence the 3-rd addition etc. All in all you are doing 3600
additions and in the end you will have accumulated a lot of error.

"Working with floating point numbers is like moving piles of sand.
Every time you do it, you loose a little sand and pick up a little
dirt"

--
Karl Heinz Buchegger
kbuchegg@gascad .at

[Arijit]

Re: floating point problems?

Karl Heinz Buchegger wrote:[color=blue]
> Gernot Frisch wrote:
>[color=green][color=darkred]
>>> glScalef( scale, scale, scale );
>>>
>>>>Does the very same as your mumbo jumbo 2 loop solution.[/color]
>>
>>Unfortunate ly not, I've got to scale the vetices along their normal
>>directions, which makes this a bit expensive. I've decided to
>>implement a temp-buffer for each object now, thank you.[/color]
>
>
> OK. If the center of scale is not identical for all points,
> then thats the best solution.[/color]

Center of scale ? You mean the origin of the coordinate system, right ?
The origin has no relation to the normal vectors, because the do not
change under translation. The problem I believe is that if you scale
normal vectors, you enable Normalization, which is expensive.

-Arijit

[Jacek Dziedzic]

Re: floating point problems?

Karl Heinz Buchegger wrote:[color=blue]
>
> "Working with floating point numbers is like moving piles of sand.
> Every time you do it, you loose a little sand and pick up a little
> dirt"
>[/color]

Now, that's a nice proverb! :)

- J.