Hallöchen!
johannes hanika writes:
> if lf returns this magic error value sometimes, maybe it's just a
> matter of fixing the branch that results in this special
> treatment? i think it should be lf's responsibility not to
> randomly return inf/nan/special value. creating nan from sqrt(-1)
> situations sounds like badly written code and results in
> frustrating error handling workarounds in all client code..
I don't see an actual difference between returning 1.6e16, inf, or
nan. The caller has to special-handle it in either case.
> of course we still need to fix the implicit conversion from the
> overlarge value.
Not necessarily. From DT's point of view, the most convenient way
would be to make LF catch every bad value and return 1e9. This
value can safely be converted into int32, and still is larger than
all real-world pixel coordinates. DT's existing clipping features
would handle it.
Mathematically, 1e9 is wrong. Algorithmically, checking all bad
values in the C code instead of in the CPU's floating point unit
slows down (a bit). API-wise, clamping nan and inf to 1e9 means
passing not all available information to the caller, and creating an
idiosyncratic special value.
But maybe it is the most pragmatic way of doing it?
Tschö,
Torsten.
--
Torsten Bronger Jabber ID: torsten.bron...@jabber.rwth-aachen.de
or http://bronger-jmp.appspot.com
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
darktable-devel mailing list
darktable-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/darktable-devel
