A 35mm film camera represented in Python object

[Chris Angelico]

On Fri, Apr 2, 2021 at 9:43 AM <2QdxY4RzWzUUiLuE at potatochowder.com> wrote:
>
> On 2021-04-01 at 18:10:46 -0400,
> Richard Damon <Richard at Damon-Family.org> wrote:
>
> > On 4/1/21 5:47 PM, D.M. Procida wrote:
> > > D.M. Procida <real-not-anti-spam-address at 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