Re: image/binary patch updated

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:

>On Friday 14 November 2003 13:31, Ethan Merritt wrote:
>  
>
>>On Friday 14 November 2003 13:36, you wrote:
>>    
>>
>>>That crash you are describing with the
>>>swap bytes, it may be that that is not a problem
>>>with the code, but perhaps the fact that the
>>>internal floating point code for DEC cc can't
>>>handle bogus floating point numbers.
>>>      
>>>
>>But yes, there are various compiler options
>>to treat floating point errors differently.
>>I'll try again with a different set of floating
>>point settings.
>>    
>>
>
>OK.  l've rebuilt everything using IEEE floating
>point rather than the alpha native floating point.
>The crashes go away, and the postscript output
>is rather more informative (attached).
>

Glad that is accounted for.  Interesting problem I didn't anticipate.

>Note in particular that the test plot labeled 
>"Closeup of pixels having grid points ...."
>is missing the lower two boxes. That must mean
>something.... if we only recognized what.
>

The data is still not correctly ASCII85 encoded.  That example
with the close up works because with so little data it happens that
the bad coding ends up being valid ASCII85 characters still.  Of
course, the image is incorrect.

I think I see what the issue is.  It is a bug.  The ASCII85 encoding
uses 4 bytes as the input to its mapping.  That is 32 bits.  It is a
series of shift operations in which a 'long' is filled with bits by shifting
left.  When the long is 4 bytes, successive codings will simply shift
the old value out past the length of the long.  But when a long is
8 bytes, the old value is shifted into the more significant bytes of the
variable which, consequently, makes a mess of the coding.  I will update
this on SourceForge, but if you want a quick fix, search in `post.trm'
for the first use of PS_encode85() and put "tuple4 = 0;" after it.  I.e.,

        PS_encode85(tuple4, tuple5);
        tuple4 = 0;

This will clear the tuple4 value so that garbage isn't shifted upward.

>If you really require some particular floating
>point behavior then you need to figure out some
>way of testing for this and at least issue a warning
>when ./configure is run.
>

I'm going to cede to suggestions from you and the list on this one.
My experience with the innards of floating point numbers in
compilers is minimal.  I just assumed that any binary floating
point numbers read in will translate to some valid number and the
user would recognize that plotted results are invalid.  I hadn't
anticipated the possibility of a program crash.

That leaves the shredded X11 images problem unresolved.  I'll
keep thinking.

Thanks,

Dan