On Fri, Apr 2, 2021 at 9:43 AM <2qdxy4rzwzuui...@potatochowder.com> wrote: > > On 2021-04-01 at 18:10:46 -0400, > Richard Damon <rich...@damon-family.org> wrote: > > > On 4/1/21 5:47 PM, D.M. Procida wrote: > > > D.M. Procida <real-not-anti-spam-addr...@apple-juice.co.uk> wrote: > > > > > >> Hi everyone, I've created <https://github.com/evildmp/C-is-for-Camera> - > > >> a representation of a Canonet G-III QL17 in Python. > > >> > > >> There's also documentation: <https://c-is-for-camera.readthedocs.io>. > > >> > > >> It's a pure Python model of the physical sub-systems of a camera and > > >> their interactions. So far it's at a fairly high level - I haven't yet > > >> got down to the level of individual springs and levers yet. > > > I'm now working on the exposure system, which in the published version > > > so far just models inputs and outputs of the system as a whole. I want > > > to start to model its functionality by modelling the interactions of its > > > components - the levers, cams and so on. > > > > > > It seems to me I have fundamentally two approaches that I could take: > > > > > > The first is to model the movement of each lever as a series of discrete > > > steps (hundreds of tiny steps, to maintain accuracy). Pro: it models > > > movement through physical positions; con: it's ugly that it breaks > > > continuous movement into arbitrary steps. > > > > > > The second is not to move each lever in such detail, but to consider its > > > interactions: given the state of each of the other parts of the system, > > > what *would* be the outcome if something were to try to move the lever > > > from such-and-such a position to another? Pro: it feels more elegant > > > than the brute-force stepping of the alternative; con: it also feels > > > like a bit of a cheat. > > > > > > But neither approach really captures for me the interaction of moving > > > analog components, which in the case of this camera also have some > > > circular logic to them - the movement of A determines that of B which > > > determines that of C which determines that of D which finally also > > > affects the movement of A. > > > > > > Any thoughts or wise ideas? > > > > > > Daniele > > > > If you keep track of the positions as a floating point number, the > > precision will be more than you could actually measure it. > > I won't disagree with Richard, although I will give you a general > warning about floating point rounding issues: if you do, in fact, end > up with your first solution and lots and lots (millions? billions? > more?) of discrete calculations, be aware that what looks like a lot of > precision in the beginning may not be all that precise (or accurate) in > the end.
Inaccuracy introduced by FP rounding is likely to be dwarfed by inaccuracy of measurement. 53-bit precision is pretty accurate compared to most real-world measurement. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
