 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> http://www.youtube.com/watch?v=duy8s8C7-Uc
> http://www.youtube.com/watch?v=58_s6r7PaKo
A giant fly staring at me through my monitor freaks me out!
--
"Smoking helps you lose weight -- one lung at a time!"
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawaz org<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mueen Nawaz wrote:
> A giant fly staring at me through my monitor freaks me out!
More or less so than a squashed bug surrounded by smaller squashed bugs? ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> 1,679,616 pixels, baby! :-D
>
> (Or what you DSLR people would call "1.7 megapixels". :-P )
Actually that would be five megapixels. Almost all the digital cameras count
each cell of the CCD as a pixel, so a RGB triad takes three pixels.
Some of the cameras you see where they have a full three colors per pixel
triple the megapixel count in their marketing.
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Invisible wrote:
>> 1,679,616 pixels, baby! :-D
>>
>> (Or what you DSLR people would call "1.7 megapixels". :-P )
>
> Actually that would be five megapixels. Almost all the digital cameras
> count each cell of the CCD as a pixel, so a RGB triad takes three pixels.
>
> Some of the cameras you see where they have a full three colors per
> pixel triple the megapixel count in their marketing.
Epic fail. O_O
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
> It's easier to understand if you consider a single function to integrate
> first, rather than doing acceleration/velocity and velocity/position in
> one go.
Er, yes.
OTOH, almost all physical systems are of this type.
(Unfortunately, all the texts explaining this stuff use abstract
mathematical functions, which makes it extremely difficult to figure out
what's going on.)
> There is a clever trick that lets you do both of these together
> without much extra work, but it's not too obvious and usually confuses
> things.
I'll bet...
> As you are aware, the problem is that with large time-steps big errors
> appear because you are assuming the average velocity during the time
> step is equal to the instantaneous velocity at the beginning of the time
> step - this is only approximately correct!
>
> All RK4 does is to find a much better estimate of the average_velocity
> during the time step, then you can use that to advance x with much
> higher accuracy.
So it gets a more accurate average velocity by sampling it more?
> Now we have four estimates for the velocity, one at the beginning of the
> time step (standard Euler), two in the middle, and one at the end of the
> time step.
Right. I don't really understand why it has to be these exact points...
> The RK4 algorithm then tells us to take a weighted average of these
> velocities:
...or why this specific weighting is the correct one. But hey, I guess
somebody had a reason for that.
> That is it! That is the estimate of average velocity over the entire
> time step. You will have noticed we called F four times, but doing this
> is MORE accurate than simply doing four dt/4 Euler time steps.
Clearly I'm going to have to meditate on exactly why that's the case. I
would have thought that taking 4 seperate steps would be more accurate
than computing 4 steps and then blurring them all into one step, but hey.
> You should be able to simply compare the values of AVE1,AVE2,AVE3,AVE4
> to determine if you need to go back and do a smaller time step.
Mmm, OK. I'll take a look at some numerical work and see what happens...
> Now to make things more general, you can replace the position "x" by the
> generic "state" of the system, and the velocities by the "derivative of
> state" of the system. This way, the functions F and RK4_Algorithm will
> return objects of type "derivative of state".
>
> If you are dealing with forces acting on particles, then the "state" of
> each particle is its position and momentum (4 variables in 2D), and the
> "derivative of state" is its velocity and force (another 4 variables).
>
> Now, your function F must return the velocity and force. The force it
> calculates based on your magnet formula or whatever, and the velocity it
> can easily calculate by dividing the supplied momentum value by the
> mass. That last part is the key that links the two differential
> equations together, and why it is sometimes complicated how RK4 can do
> both at the same time for acceleration and velocity.
Hmm... How is momentum and velocity different?
Oh, wait - the mass could be non-unital. I forgot about that...
Thinking about Euler integration, you end up doing something like
x' = x' + dt x''
x = x + dt x'
In other words, you compute the new velocity from the old one, and then
assume that velocity is constant while you compute the new position from
the old one. But if you assume that acceleration is constant, you can
actually *exactly solve* for position. I can't figure out the equation
off the top of my head, but it would be some kind of quadratic curve. I
wonder - would this give you any more of an accurate result?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Darren New wrote:
>> Invisible wrote:
>>> 1,679,616 pixels, baby! :-D
>>>
>>> (Or what you DSLR people would call "1.7 megapixels". :-P )
>>
>> Actually that would be five megapixels. Almost all the digital cameras
>> count each cell of the CCD as a pixel, so a RGB triad takes three pixels.
>>
>> Some of the cameras you see where they have a full three colors per
>> pixel triple the megapixel count in their marketing.
>
> Epic fail. O_O
Not really. Pixel means "picture element". Who's to say whether that's one
CCD cell or one tri-color cell? :-)
--
Darren New, San Diego CA, USA (PST)
There's no CD like OCD, there's no CD I knoooow!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> Not really. Pixel means "picture element". Who's to say whether that's one
> CCD cell or one tri-color cell? :-)
I'm wondering: Given that the blue component is significantly less
important than the other components (as demonstrated in another thread),
wouldn't it be cheaper to produce CCD cells where there are only half of
the blue cells? In other words, each second RGB triplet would actually lack
the B detector (the blue component can then be interpolated from adjacent
pixels in software). This would most probably not produce pictures of
significantly less quality.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 07 May 2009 20:13:08 +0200, Warp <war### [at] tagpovrayorg> wrote:
> I'm wondering: Given that the blue component is significantly less
> important than the other components (as demonstrated in another thread),
> wouldn't it be cheaper to produce CCD cells where there are only half of
> the blue cells? In other words, each second RGB triplet would actually
> lack the B detector
The sensor itself (be it CCD or CMOS) is monochrome in the vast majority
of digital cameras, the notable exceptions being the handful of cameras
based on Foveon sensors.
Most digital cameras use a Bayer filter to get colour; these have half the
cells dedicated to green and a quarter each to red and blue.
> the blue component can then be interpolated from
> adjacent pixels in software
This already happens with all three colour components.
--
FE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> OTOH, almost all physical systems are of this type.
Indeed, and the exact solution of that is a damped sine wave, which is why
so much stuff vibrates and resonates in the real world.
>> Now we have four estimates for the velocity, one at the beginning of the
>> time step (standard Euler), two in the middle, and one at the end of the
>> time step.
>
> Right. I don't really understand why it has to be these exact points...
>
>> The RK4 algorithm then tells us to take a weighted average of these
>> velocities:
>
> ...or why this specific weighting is the correct one. But hey, I guess
> somebody had a reason for that.
It matches the Taylor Series approximation of the function:
http://grb.physics.unlv.edu/~zbb/files/RungeKuttaProof.pdf
> Clearly I'm going to have to meditate on exactly why that's the case. I
> would have thought that taking 4 seperate steps would be more accurate
> than computing 4 steps and then blurring them all into one step, but hey.
RK4 is not just taking 4 blind steps though, it's using the result of the
previous ones to get the next ones, which is how it gets to be more accurate
than a simple linear estimate.
>> Now, your function F must return the velocity and force. The force it
>> calculates based on your magnet formula or whatever, and the velocity it
>> can easily calculate by dividing the supplied momentum value by the mass.
>> That last part is the key that links the two differential equations
>> together, and why it is sometimes complicated how RK4 can do both at the
>> same time for acceleration and velocity.
>
> Hmm... How is momentum and velocity different?
>
> Oh, wait - the mass could be non-unital. I forgot about that...
Yes that's rather key :-) I also find that keeping momentum as a state
variable rather than velocity (which would also work) avoids some of the
confusion with the differential of position in the algorithm.
> Thinking about Euler integration, you end up doing something like
>
> x' = x' + dt x''
> x = x + dt x'
>
> In other words, you compute the new velocity from the old one, and then
> assume that velocity is constant while you compute the new position from
> the old one. But if you assume that acceleration is constant, you can
> actually *exactly solve* for position. I can't figure out the equation off
> the top of my head,
x = x + dt x' + 1/2 x'' dt^2
That looks a bit like a Taylor Series expansion, doesn't it :-) You can
extend that to:
x = x + dt x' + 1/2 x'' dt^2 + 1/6 x''' dt^3
and also write it for x' instead of x:
x' = x' + dt x'' + 1/2 x''' dt^2 + 1/6 x'''' dt^3
And that is exactly what your RK4 algorithm is estimating :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>> OTOH, almost all physical systems are of this type.
>
> Indeed, and the exact solution of that is a damped sine wave, which is
> why so much stuff vibrates and resonates in the real world.
Well, I don't know about that, but physics is mostly about forces, and
forces generate acceleration, and force is usually a function of
position (or perhaps velocity). Hence differential equations seem to be
kind of ubiquitous in physics.
(My memory may be defective, but I was under the impression that indeed
differential and integral calculus were *invented* by the eniment
physacist Newton...)
Interestingly, a trivial differential equation has exponential growth as
its solution, but you never see this in mechanical systems.
>> Right. I don't really understand why it has to be these exact points...
>> ...or why this specific weighting is the correct one. But hey, I guess
>> somebody had a reason for that.
>
> It matches the Taylor Series approximation of the function:
Taylor...series...?
I thought a Taylor series is just a way of constructing a polynomial
approximation to a function that you don't have any better way to
compute. (Assuming the series is even convergent in the first place.)
I'm not sure how you use that to construct an approximation to a
completely *unknown* function...
> http://grb.physics.unlv.edu/~zbb/files/RungeKuttaProof.pdf
"Hence the idea in Theorem 9.7 is that if the step size in the RK4
method is reduced by a factor of 1/2 we can expect that the overall
F.G.E. will be reduced by a factor of 1/16."
...OK, well *that* would certainly explain why it's drastically more
stable then. (Although it still doesn't explain how this phenominon
comes about in the first place.)
>> Clearly I'm going to have to meditate on exactly why that's the case.
>> I would have thought that taking 4 seperate steps would be more
>> accurate than computing 4 steps and then blurring them all into one
>> step, but hey.
>
> RK4 is not just taking 4 blind steps though, it's using the result of
> the previous ones to get the next ones, which is how it gets to be more
> accurate than a simple linear estimate.
And taking 4 linear steps uses the result of the previous steps for the
next one. I don't get why taking those steps, throwing the result away
and just keeping the intermediate results, and then mixing that all
together gives a better result. (Altough it clearly *does*.)
>> Hmm... How is momentum and velocity different?
>>
>> Oh, wait - the mass could be non-unital. I forgot about that...
>
> Yes that's rather key :-)
Only if the particle has non-unital mass. ;-)
> I also find that keeping momentum as a state
> variable rather than velocity (which would also work) avoids some of the
> confusion with the differential of position in the algorithm.
Perhaps.
>> But if you assume that acceleration is
>> constant, you can actually *exactly solve* for position. I can't
>> figure out the equation off the top of my head,
>
> x = x + dt x' + 1/2 x'' dt^2
Yeah, something like that. :-}
> That looks a bit like a Taylor Series expansion, doesn't it :-)
I wouldn't know.
> You can extend that to:
>
> x = x + dt x' + 1/2 x'' dt^2 + 1/6 x''' dt^3
>
> and also write it for x' instead of x:
>
> x' = x' + dt x'' + 1/2 x''' dt^2 + 1/6 x'''' dt^3
>
> And that is exactly what your RK4 algorithm is estimating :-)
I don't follow. (I.e., I don't see how the final formula is remotely
related to RK4.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
