[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-2d-dev
Subject: Re: [OpenJDK 2D-Dev] [9] 8152293: Incomplete fraction reduction in getValueAsString() for TIFFTag.TI
From: Alexander Stepanov <alexander.v.stepanov () oracle ! com>
Date: 2016-11-15 16:59:42
Message-ID: b74b4211-7ed2-ca69-9cc8-0d98ce2ae0b3 () oracle ! com
[Download RAW message or body]
Hello, Brian
On 11/15/2016 7:25 PM, Brian Burkhalter wrote:
> Hello Alexander,
>
> On Nov 15, 2016, at 4:11 AM, Alexander Stepanov
> <alexander.v.stepanov@oracle.com
> <mailto:alexander.v.stepanov@oracle.com>> wrote:
>
>> Thank you for the comments (hopefully I wasn't too confident picking
>> the issue).
>
> You’re welcome. I doubt that you will have any trouble with it.
>
>> Yes, from the "do not harm" position it seems better to remove all
>> the reduction-related fragments (leaving these worries to the user),
>> but keep the zero denominator checks + the sign checks for the
>> unsigned fractions.
>
> Again, as I mentioned, I don’t know about the feasibility of zero
> denominator checks given that it is sometimes necessary to create a
> TIFFField whose data object is allocated but uninitialized.
yes, the changes in createArrayForType() were made for this purpose.
probably they are not enough..
>
>> One more silly question - if some upper bound (2^32 - 1) check should
>> be added for TIFF_RATIONAL's numerator/denominator? At a 1st glance,
>> it seems to be needless; on the other hand, it seems that the longs
>> should be used to store 32-bit unsigned integers(?). Not sure if it
>> could cause any side effects.
>
> If one were to do the actual division and the numerator is not a
> multiple of the denominator, then the result would likely be stored as
> a floating point value. Given that I am not sure that an overflow
> check is needed.
>
> Thanks,
>
> Brian
Looking more carefully at some other TIFF_<TYPES>, some other potential
border/sign issues can be seen (JDK-8169725, JDK-8169728). So it seems
there is some common potential imprecision here.
Thanks,
Alexander
[Attachment #3 (text/html)]
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hello, Brian<br>
</p>
On 11/15/2016 7:25 PM, Brian Burkhalter wrote:<br>
<blockquote
cite="mid:483957F9-E222-466F-9977-81DF878CF59A@oracle.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
Hello Alexander,
<div><br>
<div>
<div>On Nov 15, 2016, at 4:11 AM, Alexander Stepanov <<a
moz-do-not-send="true"
href="mailto:alexander.v.stepanov@oracle.com">alexander.v.stepanov@oracle.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite"><span style="font-family: Helvetica;
font-size: 12px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
normal; orphans: auto; text-align: start; text-indent:
0px; text-transform: none; white-space: normal; widows:
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;
float: none; display: inline !important;">Thank you for
the comments (hopefully I wasn't too confident picking the
issue).</span><br style="font-family: Helvetica;
font-size: 12px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
normal; orphans: auto; text-align: start; text-indent:
0px; text-transform: none; white-space: normal; widows:
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
</blockquote>
<div><br>
</div>
<div>You’re welcome. I doubt that you will have any trouble
with it.</div>
<br>
<blockquote type="cite"><span style="font-family: Helvetica;
font-size: 12px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
normal; orphans: auto; text-align: start; text-indent:
0px; text-transform: none; white-space: normal; widows:
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;
float: none; display: inline !important;">Yes, from the
"do not harm" position it seems better to remove all the
reduction-related fragments (leaving these worries to the
user), but keep the zero denominator checks + the sign
checks for the unsigned fractions.</span><br
style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant: normal; font-weight:
normal; letter-spacing: normal; line-height: normal;
orphans: auto; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: auto;
word-spacing: 0px; -webkit-text-stroke-width: 0px;">
</blockquote>
<div><br>
</div>
<div>Again, as I mentioned, I don’t know about the feasibility
of zero denominator checks given that it is sometimes
necessary to create a TIFFField whose data object is
allocated but uninitialized.</div>
</div>
</div>
</blockquote>
yes, the changes in createArrayForType() were made for this purpose.
probably they are not enough..<br>
<blockquote
cite="mid:483957F9-E222-466F-9977-81DF878CF59A@oracle.com"
type="cite">
<div>
<div><br>
<blockquote type="cite"><span style="font-family: Helvetica;
font-size: 12px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height:
normal; orphans: auto; text-align: start; text-indent:
0px; text-transform: none; white-space: normal; widows:
auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;
float: none; display: inline !important;">One more silly
question - if some upper bound (2^32 - 1) check should be
added for TIFF_RATIONAL's numerator/denominator? At a 1st
glance, it seems to be needless; on the other hand, it
seems that the longs should be used to store 32-bit
unsigned integers(?). Not sure if it could cause any side
effects.</span></blockquote>
</div>
<br>
</div>
<div>If one were to do the actual division and the numerator is
not a multiple of the denominator, then the result would likely
be stored as a floating point value. Given that I am not sure
that an overflow check is needed.</div>
<div><br>
</div>
<div>Thanks,</div>
<div><br>
</div>
<div>Brian</div>
</blockquote>
<br>
Looking more carefully at some other TIFF_<TYPES>, some other
potential border/sign issues can be seen (JDK-8169725, JDK-8169728).
So it seems there is some common potential imprecision here.<br>
<br>
Thanks,<br>
Alexander<br>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic