> 
> 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

Tom Melly wrote:
> 
> > 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?
	I don't think it will, but anyway in this case, the values were not
integers...


-- 

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

Post a reply to this message

news:39D4ABB9.43F155FB@enst.fr...
> > So C will never use integer math on a variable declared as float, even
when
> > the value of the float is an integer?
> I don't think it will, but anyway in this case, the values were not
> integers...

Never? - I was slightly assuming that the value of x_ix changed. What I
meant was that if x_ix went through the series 0.5, 0.6, 0.7, 0.8, 0.9, 1.0,
1.1, etc. then the calculation when x_ix = 1.0 could be quicker. Of course,
it wouldn't be much of an optimisation since it would only (in the above
example) speed up one calculation out of every 10.

Actually, in the language I most commonly code in (a proprietry db lang.
based on pascal I think), the speed difference you noticed would be exactly
what I'd expect. Although a side effect would be that the result would alway
be an integer (the language does not require pre-declaration of data-types).

So: 1 + 1.5 = 2, but 1.0 + 1.5 = 2.5 since the result is data-typed to match
the data type of the first input. (therefore 1.5 + 1 = 2.5)

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...
> 
Instead of shifting bit masking with & could be considered as well...


>         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??
> 
Generate assembler code and look at it, this might give hint. I tried it
with IBM compiler and only difference is the fact, that in first case
double value 1.0 (yes, compiler converted it to double) is put into same
segment as code, on second case it was put into constant segment. This
might be one reason (loading constant segment page into memory or
something like this).
But I won't count very much on this speed-up obtaining, as different
compilers on different platforms might give different results. More
clear would be using 1.0.

Post a reply to this message

Vahur Krouverk wrote:
> 
> Instead of shifting bit masking with & could be considered as well...
> 
	Well of course, shifting for divisions and bit masking for modulus...

> Generate assembler code and look at it, this might give hint. I tried it
> with IBM compiler and only difference is the fact, that in first case
> double value 1.0 (yes, compiler converted it to double) is put into same
> segment as code, on second case it was put into constant segment. This
> might be one reason (loading constant segment page into memory or
> something like this).
	Good point, I'll try and see what gcc does...


-- 

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

Post a reply to this message

Nathan Kopp wrote:

> 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].

Is there a way we could have two functions,

    1)  one "[-0.5, 1.5] clamped down to [0,1].",  for all the folks
complaining about their old sky textures,

    2)  one  based on this raw [-0.5, 1.5] noise,  but
newnoise=(computersrawnoisefunction +0.5) /2


?

Post a reply to this message

In article <39DDAB0F.7C1182B2@my-dejanews.com>, 
gre### [at] my-dejanewscom wrote:

> Is there a way we could have two functions,
> 
>     1)  one "[-0.5, 1.5] clamped down to [0,1].",  for all the folks
> complaining about their old sky textures,
> 
>     2)  one  based on this raw [-0.5, 1.5] noise,  but
> newnoise=(computersrawnoisefunction +0.5) /2

That is what is done now, though it is controlled with the #version 
directive.
Anyway, two noise functions are not necessary, since you can get the old 
one from the new version(but you can't go the other way, and get 
plateau-less noise from the old kind). Just put a space of solid 
material(color, texture, pigment, etc) at each end of the blend map, and 
squash the existing colors into the middle. I think this is the cleanest 
and best solution, even though it does require changing some older 
scenes.

But if you really want separate noise types, it could be done by 
internally duplicating every feature that uses noise, and using a 
"#noise_type" keyword to tell the parser which one to choose. This would 
be very time-consuming to do, and messy(since it would need two versions 
of bozo, wrinkles, turbulence, etc, etc...), but it would allow you to 
use both types of noise in one scene, and would be the cleanest from the 
user's point of view.
A much simpler way would be a global_settings keyword, but that would 
force everything in the scene to use the same noise type. This could be 
a problem if you are using include files which depend on a different 
noise type.

-- 
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