#5 bad-value as object-property rather than class property

closed
nobody
None
5
2006-07-25
2004-07-02
Anonymous
No

The current implementation of bad-values stores the
attributes per PDL-datatype rather than per pdl object.

When reading in data from different sources with
different bad-data attributes (i.e. badvalue, badflag),
it is very hard to remap all badvalues to a single
badvalue for the whole program.

Making badvalues pdl-properties would simplify the work
with bad-values in PDL a lot, in particular in larger
projects.

Best regards,

Heiko

Discussion

  • Doug Burke

    Doug Burke - 2004-07-29
    • labels: 101696 -->
    • milestone: 100443 -->
     
  • Doug Burke

    Doug Burke - 2004-07-29

    Logged In: YES
    user_id=7154

    The internals of the bad-value support were designed to allow a switch
    from class to object based properties for the bad value, although this has
    never been tested. So, this should be possible and it would hopefully not
    take too-much effort.

    A couple of issues that spring to mind:

    1) do we allow NaN's and other values for floating-point data?

    The current implementation either forces the bad value to be a NaN
    or a non-NaN for floating-point data (this is a compile-time option). It
    could be changed to allow both, although I don't know what the speed
    penalty would be.

    2) How should
    $c = $a + $b;
    be handled when $a and $b have different bad values (but are the same
    type)? I guess the simplest suggestion is to use the default bad value for
    that datatype rather than decide on using the value from $a or $b.

    If you have any thoughts/opinions please send them to one of the email
    lists.

     
  • Doug Burke

    Doug Burke - 2006-07-25

    Logged In: YES
    user_id=7154

    The CVS version includes experimental support for per-piddle bad values.
    You need to set the BADVAL_PER_PDL configuration option to 1 (and note that
    you can not combine this with the BADVAL_USENAN option). This is Heiko's
    patch 1099405 (thanks for that by the way).

    Doug

     
  • Doug Burke

    Doug Burke - 2006-07-25
    • status: open --> closed
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks