pdf-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pdf-devel] Type 4 functions


From: jemarch
Subject: Re: [pdf-devel] Type 4 functions
Date: Sat, 09 Jan 2010 16:18:42 +0100
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/23.1.91 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)


   Treating this correctly would require attaching a type to every element
   on the stack, I think something like

   struct stack_element_t {
     enum type { BOOL, INT, REAL } t;
     double v;
   } stack[NSTACK+2];

   and a set of suitable predicates/accessors would do the job, some
   additional checks for numerical constants and return values would be
   required too. I don't know if this is considered neccessary. As far as 
   I can see the current approach works well for all valid type 4 functions.
   However, it also treats obviously invalid type 4 functions as valid ones.
   I don't think that fixing this requires too much effort.

I would go in that direction.  It is much better to clearly identify
the type of the elements in the stack.  Error checking and management
of invalid functions is as important as the management of correct
functions.

I just created a flyspray task for this problem.  Would you like to
fix it yourself?  In that case, please pick the task.

   > Actually what we need are systematic tests on every allowed operator.
   > For each operator, would be good to have:
   > 
   > - A couple of positive tests (with valid values in the domain).
   > - A couple of negative tests, if applicable (with invalid values in
   >   the domain).
   > - A couple of extreme/interesting cases tests, if applicable.

   Please find attached some first tests I have written 
   (torture/unit/base/fp/pdf-fp-func-eval.c) and the required changes to 
   pass them (src/base/pdf-fp-func.c). The changes concern the following 
   issues:

   1) Input values are not clipped to the domain.
   2) The second operand to mod must not be 0. I suppose in this case
   setting PDF_EMATH as appropriate.
   3) It is a range error to pass a negative value to the log functions. I 
   think passing 0 should cause a range error too.

I pushed a patch with those fixes to pdf-fp-func.c.  Many thanks.

As for the tests, please don't use system functions like mod_f
directly, but create a pdf_fp_mod function for that purpose in
pdf-fp.[ch] (see pdf-fp.h for examples like sqrt, sin, cos, etc).

-- 
Jose E. Marchesi  <address@hidden>
                  http://www.jemarch.net
GNU Project       http://www.gnu.org




reply via email to

[Prev in Thread] Current Thread [Next in Thread]