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