|
Jeremy David Thomson wrote: Your 'average of all iterations' comment intrigues me
Then I was probably a little misleading, I was just trying to pick an example as to why you might want anything other than than the classic 'IterationCount / MaxIterations' which is what most folk doing this 'rite of passage' project would recognise. More practical examples might have been standard deviation or other more complex statistical analysis - many (all?) of which have been done by someone at some point to varying degrees of success and aesthetic value.
Jeremy David Thomson wrote: You may want to check out www.FractalForums.com
That I have discovered, though I have only scratched the surface at this point. It seems one of the better (or at least more broad ranging) places to go, though there are literally millions of places to get little bits and pieces of useful information.
Thanks for your time.
|
|
|
|
|
Howdy
Hmm, is double precision complex really needed, in your case e.q. storing all in int's could
reduce required space 4x.
also maybe the whole image could be 7zipped.
You could allocate each time 1M ints array and run 7zip through it, I assume a lot of compression could be achieved that way 
Dunno though
|
|
|
|
|
Zipping wouldn't work due to the very nature of fractals: they're all about chaos and unpredictability, whereas compression algorithms are all about detecting patterns and predictability of data sequences. The two don't mesh. Ever.
P.S: for the same reason restricting yourself to lower precision won't work either. In fact, with a precision of only about 55 bit (which I think is the usual length of the mantisse in a double), doing more than about 500 iterations will yield no meaningful data. It may still look nice when visualized (which is usually the point of fractal programs), but you are effectively looking at rounding errors. I would go so far as to say you need an arbitrary math library for more than 100 iterations.
|
|
|
|
|
I'm a bit in a hurry right now, but I'd like to point out that for 10000 iterations you need arbitrary precision math! The rounding errors from each iteration grow exponentially, and so will the size you need to store each resulting value in sufficient precision.
Unless of course you're fine that you're effectively looking at rounding errors after a few hundred iterations.
|
|
|
|
|
Stefan_Lang wrote: for 10000 iterations you need arbitrary precision math
Good point, well made. << Heads off to investigate >>
To be fair, at this point it's more proof of concept, can I design a set of classes that allow you to plug any fractal set into any colourising method (with any mapping technique to boot), it's not intended to be a finished product, why would the world need another fractal generator?
Thanks,
Mike
|
|
|
|
|
I had some time to get an estimate for the accumulation of the precision-based error, and found that it's upper limit is about machine_precision*4^iterations, and the average error would be around machine_precision*2^iterations. That means the maximum error approaches 1 after about 28 iterations for double values (55-56 bit mantisse), and the average error approaches 1 after about 56 iterations.
If you intend to store intermediate results, you might consider approaching this problem from the other side:
1. partition your intervals according to your machine precision, e. g. 2^16x2^16 points
2. for each point, store 1 if after one iteration the divergence criterium is met, or 0 if not. This is the iteration counter.
3. repeat for each point with a value of 0:
3.1 convert the result after one iteration to the resolution of your point array (i. e. check which pixel is closest)
3.2 check the iteration counter for the point corresponding to that value: if it is not 0, store this value+1. Else your counter is still 0.
3.3 when you're done with all points that still have a counter of 0, start all over again, for at most as many times as appropriate to your initial resolution (e. g. no more than 16 times if you started at 2^16x2^16)
This is a reversion of the actual algorithm, deliberately adding in the error (in step 3.1) that you would otherwise get when calculating at a given resolution (in this case 16 bit).
|
|
|
|
|
Thanks for spending time on this - I'm going to have to sit down with a large coffee (or 8) before I get my head around this. Separately I found GNU MP and some .Net wrappers. When I get there I'll have a decent look at both options
Thanks again,
Mik
|
|
|
|
|
From here: http://mrob.com/pub/muency/accuracy.html[^]
The commonly-seen views of the Mandelbrot Set have been challenged by arguments based on techniques like error-term analysis (see Propagation of uncertainty). They show that if you want to get an accurate view of a lemniscate ZN you need to use at least N digits in all your calculations. The result is that most views of the Mandelbrot Set that people see on computers are (in theory) completely inaccurate or even "fictitious".
However, except for certain specific purposes (notably using iteration to trace an external ray), the problem is much smaller. The overwhelming amount of experimental evidence shows that ordinary Mandelbrot images (plotting e.g. the dwell for each point on a pixel grid) are indistinguishable from equivalent results produced by exact calculation. The images look the same to the human eye regardless of how many digits you use, as long as the number of digits is sufficient to distinguish the coordinates of the parameter value C.
This is because the roundoff errors added by each step in the iteration tend to cancel out as they would if randomly distributed, rather than systematically biased in one certain direction. See Systematic error, "Systematic versus random error".
Not that this means the discussion about errors is without value, especially since the above explanation of why you might choose to ignore it relies on an assumed internal cancellation of errors through randomness. Indeed the above validates the discussion but perhaps helps put into context how much effort one might want to put into higher accuracy vs. say better functionality etc.
Mike
|
|
|
|
|
Interesting. I have to admit I was a bit doubtful of my own line of argumentation, since I've seen incredibly detailed pictures from the Mandelbrot Set as early as 25 years ago, and I doubt many of them (if any) were calculated using arbitrary precision. Nor did their smoothness indicate anything even close to the error levels that error propagation theory would suggest.
Then again, I've seen some fixed point 16 bit implementations that were clearly useless for anything but calculating the full picture (at a low resolution, preferably) - zooming in pretty quickly revealed the huge errors this limited accuracy produced.
In any case, you should make sure that when you zoom in to some interesting area, your accuracy is still some orders of magnitude above the distance between pixels, or else you'll get the same kind of artifacts I mentioned in the previous paragraph.
P.S.: I considered how to model the cancelling out: the systematic error based on machine precision has a uniform distribution. Iterating this calculation, is like adding independent variables (up to 4 times in one iteration step), resulting in a distribution that looks more like a normal distribution. The expected error will be 0, on average, but what is of a greater interest is the likelyhood that the error exceeds some value that makes the result unusable (an error about the size of 1, or greater). Unfortunately my knowledge of probability theory is somewhat rusted, but I suppose if you can determine that likelyhood and it is on the order of no more than 1/(number of pixels), then you still should get good results for visualization purposes.
|
|
|
|
|
Try doing the computation 1 pixel at a time, and discarding results from all the iterations except 0, n-1 and n, where n is the total number of iterations in the computation so far. This would reduce memory usage by complex numbers to just 48 bytes!
EDIT: Probably not 48 bytes, but 3 complex numbers need to be stored. This could be any amount, depending on the precision used.
|
|
|
|
|
Hello everyone
I need to generate a PDF417 bar code and do the reverse operation.
but the problem is that the text I need to encode is in Arabic like "أ ب ت ث ... "
I found a lot of SDK and online programs that help generating and reading pdf417 bar codes, but non of them support the Arabic language.
could anyone help me with that? and do I need to build a program for the whole pdf417 encoding which needs time?
|
|
|
|
|
I did not down-vote this, but someone probably did so because you already posted this question in the C# forum.
Having been a member on this site for almost 4 years, you should know not to do that...
Soren Madsen
|
|
|
|
|
I guess it's an algorithm sort of question, or maybe not, but this is the closest approximation I can find...
I spent many years of my life creating mathematical models of systems, but all of them were more or less continuous functions - missile guidance, targeting, filtering - that sort of thing. But I'm trying to model a discontinuous system at the moment, and I haven't a clue how to start. The current problem, I have a series of lift stations, each containing a wet well - a hole in the ground that received liquid from upstream sources at unpredictable times - and a pair of pumps that switch on at preset levels to empty each well. The linear parts I can figure out, knowing such things as the pump flow rates, head pressures and frictional pipeline losses. But how do I model the discrete on/off times for each pump in order to maintain optimal transport rates without overflowing any well in the line?
Can anyone suggest a link or two that demonstrates how this is typically done? I'm thinking some kind of state machine model with discrete time intervals, but I could be completely off the mark.
Will Rogers never met me.
|
|
|
|
|
Hi Roger,
What you are looking for is "discrete event simulation". The basic idea is that the system runs off a queue of future events, sorted in time order, and picks them off and handles them one at a time. The "clock" jumps from one event to the next, which is where the "discrete time" bit comes from. Consider me filling a tub with a bucket.
Event 1, t=0: Bucket under tap, turn tap on. It takes 5 secs to do this, so schedule event 2, time 5.
Event 2, t=5: Tap running. Tap runs at 5 gpm, bucket holds 10gal. Schedule event 3, time 65.
Event 3, t=65: Bucket full. turn tap off. 2 sec. => event 4 @ t=67.
Event 4, t=67: Carry bucket to tub and tip in. 10 secs
Event 5, t=77: Is the tub full yet? ...
These events could easily be interleaved with you filling a different tub from a different tap. Things get interesting when we interact, by sharing, say, the tap. Queuing gets involved then. (btw, discrete event simulation is *the* way to do Monte Carlo queueing problems.)
Having said all that, I'm sure:
(a) your google-fu is at least as good as mine.
(b) there are free packages out there.
The hard work is in describing the system to the point where your model is complete enough to hang together. Conservation of matter is always a good starting point.
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Peter_in_2780 wrote: The hard work is in describing the system to the point where your model is complete enough to hang together.
That's what I'm trying to grasp, I think. Six stations, 12 pumps, two pumps don't output as much as 2x 1 pump, one pump starts at level 1, the other at level 2, but both shut down at level 0... It's not as simple as simply writing a differential equation for an electrical circuit. 
Will Rogers never met me.
|
|
|
|
|
The good thing about simulation is that if it blows up, no physical damage is done! (Just as well, given some of the simulations I've run in the past!)
At each event, you need to update the state of the world (pump 1 is running, so the level in tank 23 is going down at 1000gpm, the pressure in the pipe at point X is ... ) then predict what "nonlinear" events are going to happen and when (tank 23 will reach lower limit switch level in 18 minutes, tank 28 will start filling at 1000gpm in 7 minutes ...) then plug them in as future events. All the continuous stuff (like solving DEs  ) is hidden in the 'prediction' phase of event handling.
I must admit, the first few serious simulations I wrote, the system behaviour stuff was hard-coded. The event handling skeleton and utility functions were reused, and slowly morphed into a more general purpose beast that could actually be described as a 'package'. Sadly, it's all faded into history. Last seen in the bucket "things I might port from Fortran77 to C".
The size of your system is NOT an issue for getting a simulation running. If you can model one station, then adding five more (even with different parameters) is trivial.
If you want to continue this conversation offline, feel free.
Cheers,
Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
Thanks, Peter. I've spent much of the evening doing some paper model building, and I might just take you up on the offer. I've done a bunch of state transition stuff in the past, but it's been a long time. The prime rule was, that which can be observed, can be controlled - that which can't, can't. So now I'm looking at what can be observed directly, what can be inferred from those observations, and what state variables to control using that information. It's unfortunate that we have no means by which to observe directly whether a pump is running, just crude floats that are either on or off. If I could access actual pump states, I could do so much more for prediction and control, but the best I can hope for is to learn that, after a level was reached, and it failed to subside after a set period of time, the pump did not respond. That will have to do for now, but gives me a great tool for arguing that we should add more monitoring circuitry! 
What I think I can do, though, is to model the proper operation condition, and use that to simulate different flows into and out of various stations in order to optimize the levels of the floats and perhaps, identify pumps that may be under or over sized. Later, if they let me add more monitoring, I can extend the model to failure prediction, and that's my end goal. I am a hardware weenie, after all. I really think it would be better to call an emergency crew out before the thing overflows, rather than waiting until a high level alarm is sounded just minutes before raw sewage starts running over the top.
I'll email you if I get stuck, and Thanks again for the offer!
Will Rogers never met me.
|
|
|
|
|
right now, i know how to get the mouse location and show the mouse and so left clicj right click and such. I am wondering if anyone had a formula for an AI for a path, eg
o = you sprite
| = wall can pass through
' = floor can pass through
* = path way for the spite
C = the cliked for the path to go
heres my example
o'''''<br />
'*|'''<br />
'****C
I hope you understand basicly i want to it go a certain location it will go there, and if there is an object in its way it will use a formula to get around it.
all this nis in 2d by the way.
and if you have the formula can you please make it as simple as possible?
|
|
|
|
|
|
ty, a* seems the most simple, but it still is allot and will take a while to understand
|
|
|
|
|
|
|
So I'm working on a side project at the moment dealing with computer vision, and I find myself needing to identify circles of an unknown size in an image. I've found a lot of information online about using the Hough Transform for circles, and MANY variations of that transform. Is there anything else out there that can be used for this purpose? I'm looking for something else that is quicker than the Hough Transform, and I am willing to sacrifice some accuracy to achieve this.
Please note that I am not looking for a library or tool to do this for me (like OpenCV), I've found plenty of them, and they all use the Hough Transform. I'm looking for an actual algorithm or related research.
Be The Noise
|
|
|
|
|
AFAIK Hough is the best available. When the circles are prominent, i.e. have quite some thickness, you could reduce the resolution of your image so the thickness of the circle(s) becomes say 2 pixels; that should provide quite some performance improvement.
And of course image processing is a field where you can efficiently apply multi-threading, as well as gain performance by putting locality of reference first (i.e. deal with bands or small areas, not entire images at once).
|
|
|
|
|
Thanks for the suggestions  I'll definitely try reducing the resolution and try to utilize more multi-threading (this is for a mobile app, and the benefits of multi-threading aren't THAT great). I've been playing with blur and color changes as well to speed things up.
Be The Noise
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
