RE: Fix for 687337 Zerodivide in cie_cache_mult

Igor,

>Instead the comparison with zero,
>I would recommend any_abs(delta) < 1e-30 .

I do no think that this is possible with real (i.e. not test)
color rendering dictionary data.  However since the change
that you suggest involves little additional CPU time and it is
possible that I am wrong and this change might save one situation,
I am willing add this modification.


Dan


-----Original Message-----
From: Igor V. Melichev [mailto:[email protected]]
Sent: Saturday, March 13, 2004 10:45 AM
To: '[email protected]'; Gs-Code-Review
Subject: Re: [gs-code-review] Fix for 687337 Zerodivide in
cie_cache_mult xefitra


Dan,

Instead the comparison with zero,
I would recommend any_abs(delta) < 1e-30 .
This threshold is near the precision of double.
Such thing is significantly more stable, because <1e-30
frequently happen due to subtraction of close doubles.

Scale=1 for the degenerate case is fine with me.

Igor.

----- Original Message -----
From: "Dan Coby" <[email protected]>
To: "Gs-Code-Review" <[email protected]>
Sent: Friday, March 12, 2004 10:25 AM
Subject: [gs-code-review] Fix for 687337 Zerodivide in cie_cache_mult


>
> Fix for 687337 Zerodivide in cie_cache_mult.
>
> DETAILS:
>
> The direct cause of the problem, and also the reason that we
> have not seen this problem in real world files is that the
> 050-01.ps test file contains the following color rendering
> dictionary.
>
> /RenderDict2
> 12 dict begin
>   /BlackPoint [ 0 0 0 ] def
>   /ColorRenderingType 1 def
>   /EncodeABC [ {} {} {} ] def
>   /EncodeLMN [ {} {} {} ] def
>   /MatrixABC [ 0 0 0  0 0 0  0 0 0 ] def
>   /MatrixLMN [ 0 0 0  0 0 0  0 0 0 ] def
>   /RangeABC [ 0 1  0 1  0 1 ] def
>   /RangeLMN [ 0 1  0 1  0 1 ] def
>   /RangePQR [ 0 1  0 1  0 1 ] def
>   /TransformPQR [ {} {} {} ] def
>   /WhitePoint [ 1 1 1 ] def
>
> Note:  The matrices full of zeroes do not represent real
> world data.  The zero matrices will result in all output
> component values being zero no matter what the inputs.
>
> Using this data, Ghostscript uses the given ranges and
> matrices to calculate values for DomainABC and DomainLMN.
> The results are [0, 0] for each domain.  The domain values
> are later used to calculate a scaling factors which is
> also 0.  Calculations, which use one of these values as
> a divisor, then generate a divide by zero exception.
>
> One option to fix this problem would be to check for zero
> before doing any calculations with the scaling factors.
> However another and simpler option is to check for the zero
> factors when they are crated and set the value to a value
> which will not cause the divide problem.  Note:  Even though
> we are using a dummy factor (1.0), the zero matrices still
> result in zero output values from the calculations.
>
>
> Index: src/gscie.c
> ===================================================================
> RCS file: /cvs/ghostscript/gs/src/gscie.c,v
> retrieving revision 1.14
> diff -u -r1.14 gscie.c
> --- a/src/gscie.c       4 Dec 2003 12:35:35 -0000       1.14
> +++ b/src/gscie.c       12 Mar 2004 07:21:25 -0000
> @@ -821,7 +821,13 @@
>  #else
>      pcache->base = A - delta / 2;      /* so lookup will round */
>  #endif
> -    pcache->factor = (delta == 0 ? 0 : N / R);
> +    /*
> +     * If size of the domain is zero, then use 1.0 as the scaling
> +     * factor.  This prevents divide by zero errors in later
calculations.
> +     * This should only occurs with zero matrices.  It does occur with
> +     * Genoa test file 050-01.ps.
> +     */
> +    pcache->factor = (delta == 0.0 ? 1.0 : N / R);
>      if_debug4('c', "[c]cache %s 0x%lx base=%g, factor=%g\n",
>               (const char *)cname, (ulong) pcache,
>               pcache->base, pcache->factor);
> _______________________________________________
> gs-code-review mailing list
> [email protected]
> http://www.ghostscript.com/mailman/listinfo/gs-code-review
>