: 	I guess it's because it requires computing three modulus on doubles
: which is very slow (a division + a floor + a difference)*3

  Why not just:

if(val>1) val=1;
else if(val<0) val=0;

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <39d1d67f@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Why not just:
> 
> if(val>1) val=1;
> else if(val<0) val=0;

That makes the plateaus, which are what started this whole thing.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:
: That makes the plateaus, which are what started this whole thing.

  I was responding to someone who explained why clamping is so slow (or
at least I think so).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Warp wrote:
> 
> Chris Huff <chr### [at] maccom> wrote:
> : That makes the plateaus, which are what started this whole thing.
> 
>   I was responding to someone who explained why clamping is so slow (or
> at least I think so).
> 
	No, but I think I see where the confusion comes from. You were thinking
of the values returned by the Noise function (which are something like
-0.01 to 1.01 and are truncated in the way you said) and the values
where Noise can be computed (must be bigger than -10000, and I don't
know the upper limit but there's one). In this case the only solution is
to take advantage of the periodicity of Noise and to bring the values
inside the acceptable range using a modulus (or something similar).


-- 

* Doctor Jekyll had something * mailto:ber### [at] inamecom
* to Hyde...                  * http://www.enst.fr/~jberger
*******************************

Post a reply to this message

> No, but I think I see where the confusion comes from. You were thinking
> of the values returned by the Noise function (which are something like
> -0.01 to 1.01 and are truncated in the way you said)

Actually, the plateaus were much worse than that.  Clamping (as Warp
described) still happens, but it used to be something like [-0.5, 1.5]
clamped down to [0,1].

> and the values
> where Noise can be computed (must be bigger than -10000, and I don't
> know the upper limit but there's one). In this case the only solution is
> to take advantage of the periodicity of Noise and to bring the values
> inside the acceptable range using a modulus (or something similar).

Could this be done using shift operators (is the period a multiple of 2)?

-Nathan

Post a reply to this message

Nathan Kopp wrote:
> 
> Could this be done using shift operators (is the period a multiple of 2)?
> 
	That only works once the double has been changed into a long, but there
might be something I can do there... I'll have to look at it in more
detail.


-- 

* Doctor Jekyll had something * mailto:ber### [at] inamecom
* to Hyde...                  * http://www.enst.fr/~jberger
*******************************

Post a reply to this message

> 
> Nathan Kopp wrote:
> >
> > Could this be done using shift operators (is the period a multiple of 2)?
> >
>         That only works once the double has been changed into a long, but there
> might be something I can do there... I'll have to look at it in more
> detail.
	That did it! The time (with the range fix) is now at 461.67 :) I don't
know why I had decided that it wouldn't work with negative numbers when
I first looked at it. Of course the range is still limited to what a
"long" can contain, but that's pretty big...

	Now I've got an interresting puzzle: knowing that "x_ix" and "x_jx" are
both doubles, why is this:
x_jx = 1 - x_ix;
faster than this:
x_jx = 1.0 - x_ix;
??

	I would understand slower (since there is a conversion to do) or same
speed (if the compiler is smart enough to do the conversion at compile
time), faster??


-- 

* Doctor Jekyll had something * mailto:ber### [at] inamecom
* to Hyde...                  * http://www.enst.fr/~jberger
*******************************

Post a reply to this message

news:39D46C9D.907A461A@enst.fr...
>
> Now I've got an interresting puzzle: knowing that "x_ix" and "x_jx" are
> both doubles, why is this:
> x_jx = 1 - x_ix;
> faster than this:
> x_jx = 1.0 - x_ix;
> ??
>

Can I guess? (I know practically nothing about C, and absolutely nothing
about it's internals). Assuming that there is nothing different about the
output of the calculation, could it be that, when x_ix is an integer value,
the first example will perform an integer calculation, whereas the second
example will always perform a floating point calculation?

My second guess would be that with the first example the compiler "knows"
that the result will have no more decimal places than are held by x_ix,
since 1 is an unequiviqual integer. With the second example, it does not
view 1.0 as an integer and therefore makes no assumption about the degree of
precision required in the answer. Am I close? Not even warm? Freezing cold?
An idiot?

Third guess (and this would imply some idiocy on the part of the compiler).
When it sees 1.0, it realises that it is an integer and first translates it
to 1 and then translates it back to a float for the purpose of the
calculation. With the first example, it is able to skip the first part of
this process.

BTW Sorry for the anthromorphisism.

Post a reply to this message

Tom Melly wrote:
> 
> Can I guess? (I know practically nothing about C, and absolutely nothing
> about it's internals). Assuming that there is nothing different about the
> output of the calculation, could it be that, when x_ix is an integer value,
> the first example will perform an integer calculation, whereas the second
> example will always perform a floating point calculation?
> 
	No no no. x_ix and x_jx are floating point numbers in both examples so
both cases require a floating point computation...

> My second guess would be that with the first example the compiler "knows"
> that the result will have no more decimal places than are held by x_ix,
> since 1 is an unequiviqual integer. With the second example, it does not
> view 1.0 as an integer and therefore makes no assumption about the degree of
> precision required in the answer. Am I close? Not even warm? Freezing cold?
> An idiot?
> 
	Might be... (that this is the explanation, not that you're an idiot :)

> Third guess (and this would imply some idiocy on the part of the compiler).
> When it sees 1.0, it realises that it is an integer and first translates it
> to 1 and then translates it back to a float for the purpose of the
> calculation. With the first example, it is able to skip the first part of
> this process.
> 
	No, I get similar result if I use a variable instead of the constant
"1" or "1.0" and there is no possible doubt on the type of a variable...



-- 

* Doctor Jekyll had something * mailto:ber### [at] inamecom
* to Hyde...                  * http://www.enst.fr/~jberger
*******************************

Post a reply to this message

news:39D49C7F.7CCBBAAC@enst.fr...
> Tom Melly wrote:
> >
> > Can I guess? (I know practically nothing about C, and absolutely nothing
> > about it's internals). Assuming that there is nothing different about
the
> > output of the calculation, could it be that, when x_ix is an integer
value,
> > the first example will perform an integer calculation, whereas the
second
> > example will always perform a floating point calculation?
> >
> No no no. x_ix and x_jx are floating point numbers in both examples so
> both cases require a floating point computation...
>

So C will never use integer math on a variable declared as float, even when
the value of the float is an integer?

Post a reply to this message