You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by "Andy Jefferson (JIRA)" <ji...@apache.org> on 2005/11/05 07:01:20 UTC
[jira] Created: (JDO-206) JDOQL test NotEquals comparing floating point numbers
JDOQL test NotEquals comparing floating point numbers
-----------------------------------------------------
Key: JDO-206
URL: http://issues.apache.org/jira/browse/JDO-206
Project: JDO
Type: Bug
Components: tck20
Reporter: Andy Jefferson
The current TCK test (carried over from JDO 1.0) for NotEquals, uses != operator on floating point numbers. This is not a good practice, and is unreliable. Its probably the case that the Equals test uses == on the same content, which also is not a good idea (as noted in the latest spec). These tests need reviewing and a reliable alternate strategy adopting
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (JDO-206) JDOQL test NotEquals comparing floating point numbers
Posted by "Erik Bengtson (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JDO-206?page=comments#action_12360212 ]
Erik Bengtson commented on JDO-206:
-----------------------------------
one more test, shows that the double converted back to float prints the expected value. More, it seems to be a "normal" floating point numbers behaviour.. In conclusion, I think it's a bug in derby that should not convert that value to double when storing.
See
http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm
http://stevehollasch.com/cgindex/coding/ieeefloat.html
public class Test
{
/**
* @param args
*/
public static void main(String[] args)
{
float f=(float)-234.23;
double d=(double)f;
float f1=(float)d;
System.out.println(f); //prints -234.23
System.out.println(d); // -234.22999572753906
System.out.println(f1); // -234.23
}
}
> JDOQL test NotEquals comparing floating point numbers
> -----------------------------------------------------
>
> Key: JDO-206
> URL: http://issues.apache.org/jira/browse/JDO-206
> Project: JDO
> Type: Bug
> Components: tck20
> Reporter: Andy Jefferson
> Assignee: Erik Bengtson
>
> The current TCK test (carried over from JDO 1.0) for NotEquals, uses != operator on floating point numbers. This is not a good practice, and is unreliable. Its probably the case that the Equals test uses == on the same content, which also is not a good idea (as noted in the latest spec). These tests need reviewing and a reliable alternate strategy adopting
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (JDO-206) JDOQL test NotEquals comparing floating point numbers
Posted by "Michael Bouschen (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JDO-206?page=all ]
Michael Bouschen updated JDO-206:
---------------------------------
Attachment: JDO-206.patch2
Attached you find a new patch (JDO-206.patch2) for review.
The patch changes the schema for derby and uses the coumn type REAL for all float fields. With this change test NotEquals succeeds. I also fixed table PrimitiveTypes and changes the column type of doubleNull and doubleNotNull to DOUBLE.
Please note, the localSetUp change from JDO-206.patch is already checked in.
> JDOQL test NotEquals comparing floating point numbers
> -----------------------------------------------------
>
> Key: JDO-206
> URL: http://issues.apache.org/jira/browse/JDO-206
> Project: JDO
> Type: Bug
> Components: tck20
> Reporter: Andy Jefferson
> Assignee: Michael Bouschen
> Attachments: JDO-206.patch, JDO-206.patch2
>
> The current TCK test (carried over from JDO 1.0) for NotEquals, uses != operator on floating point numbers. This is not a good practice, and is unreliable. Its probably the case that the Equals test uses == on the same content, which also is not a good idea (as noted in the latest spec). These tests need reviewing and a reliable alternate strategy adopting
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Commented: (JDO-206) JDOQL test NotEquals comparing floating
point numbers
Posted by Michael Bouschen <mb...@spree.de>.
Hi Craig,
I checked in the setUp changes (revision 357680). I used another JDO
issue number JDO-147 in the commit message, because the cleanUp changes
are not directly related to the float issue.
Please note, with the setUp changes the first run of one of the
operators test I changed might fail with a duplicate key exception for
application identity and a wrong query result exception for datastore
identity. The reason is that the test cases did not cleaned up the
database, so they left behind some testdata. Simply rerun the test cases
and the problem will be gone.
Regards Michael
> Hi Michael,
>
> Definitely add the setUp changes. But I'd like to get some feedback from
> others on changing the value. It appears to me that we now understand
> why the comparison was going wrong. And it is a bug that we don't match
> the float type in memory to the proper db type.
>
> Craig
>
> On Dec 18, 2005, at 3:06 PM, Michael Bouschen wrote:
>
>> Hi Craig,
>>
>> we could go through the schema and change the column type as you
>> described, but maybe we should treat this as a separate issue. I still
>> would like to change the float value and add the setUp changes as
>> implemented in the patch. What do you think?
>>
>> Regards Michael
>>
>>> [
>>> http://issues.apache.org/jira/browse/JDO-206?page=comments#action_12360759
>>> ]
>>> Craig Russell commented on JDO-206:
>>> -----------------------------------
>>>
>>> The issue here is that Derby treats the FLOAT data type is used to
>>> represent both single- and double-precision floating point numbers.
>>> To get a single-precision value in the database, you have to use
>>> either REAL data type or specify a length on FLOAT.
>>> Everywhere we really want a 32-bit floating point number to be
>>> stored, we need to specify REAL or FLOAT(24) as the column type.
>>>
>>>
>>>
>>>
>>>> JDOQL test NotEquals comparing floating point numbers
>>>> -----------------------------------------------------
>>>>
>>>> Key: JDO-206
>>>> URL: http://issues.apache.org/jira/browse/JDO-206
>>>> Project: JDO
>>>> Type: Bug
>>>> Components: tck20
>>>> Reporter: Andy Jefferson
>>>> Assignee: Michael Bouschen
>>>> Attachments: JDO-206.patch
>>>>
>>>> The current TCK test (carried over from JDO 1.0) for NotEquals, uses
>>>> != operator on floating point numbers. This is not a good practice,
>>>> and is unreliable. Its probably the case that the Equals test uses
>>>> == on the same content, which also is not a good idea (as noted in
>>>> the latest spec). These tests need reviewing and a reliable
>>>> alternate strategy adopting
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>> --
>> Michael Bouschen Tech@Spree Engineering GmbH
>> mailto:mbo.tech@spree.de http://www.tech.spree.de/
>> Tel.:++49/30/235 520-33 Buelowstr. 66
>> Fax.:++49/30/2175 2012 D-10783 Berlin
>>
>
> Craig Russell
>
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>
> 408 276-5638 mailto:Craig.Russell@sun.com
>
> P.S. A good JDO? O, Gasp!
>
>
--
Michael Bouschen Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
Re: [jira] Commented: (JDO-206) JDOQL test NotEquals comparing
floating point numbers
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Michael,
Definitely add the setUp changes. But I'd like to get some feedback
from others on changing the value. It appears to me that we now
understand why the comparison was going wrong. And it is a bug that
we don't match the float type in memory to the proper db type.
Craig
On Dec 18, 2005, at 3:06 PM, Michael Bouschen wrote:
> Hi Craig,
>
> we could go through the schema and change the column type as you
> described, but maybe we should treat this as a separate issue. I
> still would like to change the float value and add the setUp
> changes as implemented in the patch. What do you think?
>
> Regards Michael
>
>> [ http://issues.apache.org/jira/browse/JDO-206?
>> page=comments#action_12360759 ]
>> Craig Russell commented on JDO-206:
>> -----------------------------------
>>
>> The issue here is that Derby treats the FLOAT data type is used to
>> represent both single- and double-precision floating point
>> numbers. To get a single-precision value in the database, you have
>> to use either REAL data type or specify a length on FLOAT.
>> Everywhere we really want a 32-bit floating point number to be
>> stored, we need to specify REAL or FLOAT(24) as the column type.
>>
>>
>>
>>> JDOQL test NotEquals comparing floating point numbers
>>> -----------------------------------------------------
>>>
>>> Key: JDO-206
>>> URL: http://issues.apache.org/jira/browse/JDO-206
>>> Project: JDO
>>> Type: Bug
>>> Components: tck20
>>> Reporter: Andy Jefferson
>>> Assignee: Michael Bouschen
>>> Attachments: JDO-206.patch
>>>
>>> The current TCK test (carried over from JDO 1.0) for NotEquals,
>>> uses != operator on floating point numbers. This is not a good
>>> practice, and is unreliable. Its probably the case that the
>>> Equals test uses == on the same content, which also is not a good
>>> idea (as noted in the latest spec). These tests need reviewing
>>> and a reliable alternate strategy adopting
>>>
>>
>>
>
>
> --
> Michael Bouschen Tech@Spree Engineering GmbH
> mailto:mbo.tech@spree.de http://www.tech.spree.de/
> Tel.:++49/30/235 520-33 Buelowstr. 66
> Fax.:++49/30/2175 2012 D-10783 Berlin
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: [jira] Commented: (JDO-206) JDOQL test NotEquals comparing floating
point numbers
Posted by Michael Bouschen <mb...@spree.de>.
Hi Craig,
we could go through the schema and change the column type as you
described, but maybe we should treat this as a separate issue. I still
would like to change the float value and add the setUp changes as
implemented in the patch. What do you think?
Regards Michael
> [ http://issues.apache.org/jira/browse/JDO-206?page=comments#action_12360759 ]
>
>Craig Russell commented on JDO-206:
>-----------------------------------
>
>The issue here is that Derby treats the FLOAT data type is used to represent both single- and double-precision floating point numbers. To get a single-precision value in the database, you have to use either REAL data type or specify a length on FLOAT.
>
>Everywhere we really want a 32-bit floating point number to be stored, we need to specify REAL or FLOAT(24) as the column type.
>
>
>
>
>>JDOQL test NotEquals comparing floating point numbers
>>-----------------------------------------------------
>>
>> Key: JDO-206
>> URL: http://issues.apache.org/jira/browse/JDO-206
>> Project: JDO
>> Type: Bug
>> Components: tck20
>> Reporter: Andy Jefferson
>> Assignee: Michael Bouschen
>> Attachments: JDO-206.patch
>>
>>The current TCK test (carried over from JDO 1.0) for NotEquals, uses != operator on floating point numbers. This is not a good practice, and is unreliable. Its probably the case that the Equals test uses == on the same content, which also is not a good idea (as noted in the latest spec). These tests need reviewing and a reliable alternate strategy adopting
>>
>>
>
>
>
--
Michael Bouschen Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de http://www.tech.spree.de/
Tel.:++49/30/235 520-33 Buelowstr. 66
Fax.:++49/30/2175 2012 D-10783 Berlin
[jira] Commented: (JDO-206) JDOQL test NotEquals comparing floating point numbers
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JDO-206?page=comments#action_12360759 ]
Craig Russell commented on JDO-206:
-----------------------------------
The issue here is that Derby treats the FLOAT data type is used to represent both single- and double-precision floating point numbers. To get a single-precision value in the database, you have to use either REAL data type or specify a length on FLOAT.
Everywhere we really want a 32-bit floating point number to be stored, we need to specify REAL or FLOAT(24) as the column type.
> JDOQL test NotEquals comparing floating point numbers
> -----------------------------------------------------
>
> Key: JDO-206
> URL: http://issues.apache.org/jira/browse/JDO-206
> Project: JDO
> Type: Bug
> Components: tck20
> Reporter: Andy Jefferson
> Assignee: Michael Bouschen
> Attachments: JDO-206.patch
>
> The current TCK test (carried over from JDO 1.0) for NotEquals, uses != operator on floating point numbers. This is not a good practice, and is unreliable. Its probably the case that the Equals test uses == on the same content, which also is not a good idea (as noted in the latest spec). These tests need reviewing and a reliable alternate strategy adopting
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (JDO-206) JDOQL test NotEquals comparing floating point numbers
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JDO-206?page=comments#action_12360881 ]
Craig Russell commented on JDO-206:
-----------------------------------
The change looks good.
This sure had me puzzled for quite a while. The root cause of the issue was that the float values in the class were being mapped to FLOAT column types, which are double precision if no length is specified. Float values were converted to double values for both comparisons and storage, so these would work fine. That is, if a float value of e.g. 234.23 were stored, it would be stored as 234.22999572753906. A query with a float parameter of 234.23 would compare the converted double value 234.22999572753906 and it would work. But a query with a BigDecimal parameter of 234.23 would be converted to a double value of 234.2300000000000, which does not compare equal to the column value.
The change looks good to check in.
> JDOQL test NotEquals comparing floating point numbers
> -----------------------------------------------------
>
> Key: JDO-206
> URL: http://issues.apache.org/jira/browse/JDO-206
> Project: JDO
> Type: Bug
> Components: tck20
> Reporter: Andy Jefferson
> Assignee: Michael Bouschen
> Attachments: JDO-206.patch, JDO-206.patch2
>
> The current TCK test (carried over from JDO 1.0) for NotEquals, uses != operator on floating point numbers. This is not a good practice, and is unreliable. Its probably the case that the Equals test uses == on the same content, which also is not a good idea (as noted in the latest spec). These tests need reviewing and a reliable alternate strategy adopting
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (JDO-206) JDOQL test NotEquals comparing floating point numbers
Posted by "Erik Bengtson (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JDO-206?page=comments#action_12360161 ]
Erik Bengtson commented on JDO-206:
-----------------------------------
Somehow derby is not storing correct the value. I found that derby stores (float)-234.23 as -234.22999572753906
Here is the stacktrace that points the place with the bug.
Thread [main] (Suspended)
Double.isNaN(double) line: 494
NumberDataType.normalizeDOUBLE(double) line: not available
SQLDouble.setValue(float) line: not available
EmbedPreparedStatement30(EmbedPreparedStatement).setFloat(int, float) line: not available
NewProxyPreparedStatement.setFloat(int, float) line: 729
FloatRDBMSMapping.setFloat(Object, int, float) line: 90
FloatMapping(SingleFieldMapping).setFloat(PersistenceManager, Object, int[], float) line: 245
ParameterSetter.storeFloatField(int, float) line: 94
StateManagerImpl.providedFloatField(PersistenceCapable, int, float) line: 2420
AllTypes.jdoProvideField(int) line: not available
AllTypes.jdoProvideFields(int[]) line: not available
StateManagerImpl.provideFields(int[], FieldManager) line: 2827
UpdateRequest.execute(StateManager) line: 224
ClassTable.update(StateManager, FieldMetaData[]) line: 2118
RDBMSManager(StoreManager).update(StateManager, int[]) line: 780
StateManagerImpl.flush() line: 4401
PersistenceManagerImpl(AbstractPersistenceManager).flush() line: 3044
NonmanagedTransaction.getConnection(boolean, boolean, boolean) line: 220
NonmanagedTransaction.getConnection(boolean, boolean) line: 189
PersistenceManagerImpl(AbstractPersistenceManager).getConnection(boolean, boolean) line: 321
InsertRequest.execute(StateManager) line: 168
ClassTable.insert(StateManager) line: 2058
RDBMSManager(StoreManager).insert(StateManager) line: 733
StateManagerImpl.internalMakePersistent() line: 3261
StateManagerImpl.makePersistent() line: 3234
PersistenceManagerImpl(AbstractPersistenceManager).internalMakePersistent(Object, FieldValues) line: 1061
PersistenceManagerImpl(AbstractPersistenceManager).makePersistent(Object) line: 1112
AllTypes.load(PersistenceManager) line: 269
NotEquals(ComparisonTests).verifyDataLoaded(PersistenceManager) line: 91
NotEquals.test() line: 184
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]
NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25
Method.invoke(Object, Object...) line: 585
NotEquals(TestCase).runTest() line: 154
NotEquals(JDO_Test).runBare() line: 204
TestResult$1.protect() line: 106
TestResult.runProtected(Test, Protectable) line: 124
TestResult.run(TestCase) line: 109
NotEquals(TestCase).run(TestResult) line: 118
TestSuite.runTest(Test, TestResult) line: 208
TestSuite.run(TestResult) line: 203
BatchTestRunner(TestRunner).doRun(Test, boolean) line: 116
BatchTestRunner(TestRunner).doRun(Test) line: 109
BatchTestRunner.run(Test) line: 80
BatchTestRunner.run(Class) line: 75
NotEquals.main(String[]) line: 177
This is the code that reproduces the issue with derby
import org.apache.derby.iapi.error.StandardException;
import org.apache.derby.iapi.types.NumberDataType;
public class FloatTest
{
/**
* @param args
*/
public static void main(String[] args)
{
try
{
System.out.println(NumberDataType.normalizeDOUBLE((float)-234.23));
}
catch (StandardException e)
{
e.printStackTrace();
}
}
}
> JDOQL test NotEquals comparing floating point numbers
> -----------------------------------------------------
>
> Key: JDO-206
> URL: http://issues.apache.org/jira/browse/JDO-206
> Project: JDO
> Type: Bug
> Components: tck20
> Reporter: Andy Jefferson
> Assignee: Erik Bengtson
>
> The current TCK test (carried over from JDO 1.0) for NotEquals, uses != operator on floating point numbers. This is not a good practice, and is unreliable. Its probably the case that the Equals test uses == on the same content, which also is not a good idea (as noted in the latest spec). These tests need reviewing and a reliable alternate strategy adopting
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (JDO-206) JDOQL test NotEquals comparing floating point numbers
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JDO-206?page=comments#action_12360755 ]
Craig Russell commented on JDO-206:
-----------------------------------
Changes look good.
> JDOQL test NotEquals comparing floating point numbers
> -----------------------------------------------------
>
> Key: JDO-206
> URL: http://issues.apache.org/jira/browse/JDO-206
> Project: JDO
> Type: Bug
> Components: tck20
> Reporter: Andy Jefferson
> Assignee: Michael Bouschen
> Attachments: JDO-206.patch
>
> The current TCK test (carried over from JDO 1.0) for NotEquals, uses != operator on floating point numbers. This is not a good practice, and is unreliable. Its probably the case that the Equals test uses == on the same content, which also is not a good idea (as noted in the latest spec). These tests need reviewing and a reliable alternate strategy adopting
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (JDO-206) JDOQL test NotEquals comparing floating point numbers
Posted by "Craig Russell (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JDO-206?page=all ]
Craig Russell reassigned JDO-206:
---------------------------------
Assign To: Erik Bengtson
Some tricks need to be used. This test compares a BigDecimal parameter to a floating point field in the database.
> JDOQL test NotEquals comparing floating point numbers
> -----------------------------------------------------
>
> Key: JDO-206
> URL: http://issues.apache.org/jira/browse/JDO-206
> Project: JDO
> Type: Bug
> Components: tck20
> Reporter: Andy Jefferson
> Assignee: Erik Bengtson
>
> The current TCK test (carried over from JDO 1.0) for NotEquals, uses != operator on floating point numbers. This is not a good practice, and is unreliable. Its probably the case that the Equals test uses == on the same content, which also is not a good idea (as noted in the latest spec). These tests need reviewing and a reliable alternate strategy adopting
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (JDO-206) JDOQL test NotEquals comparing floating point numbers
Posted by "Erik Bengtson (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JDO-206?page=comments#action_12360162 ]
Erik Bengtson commented on JDO-206:
-----------------------------------
I extended the test, and when the JVM converts (float)-234.23 it results in -234.22999572753906.
Is that a JVM bug?
import org.apache.derby.iapi.error.StandardException;
import org.apache.derby.iapi.types.NumberDataType;
public class FloatTest
{
/**
* @param args
*/
public static void main(String[] args)
{
try
{
System.out.println(NumberDataType.normalizeDOUBLE((float)-234.23)); //prints -234.22999572753906
float f =(float)-234.23;
System.out.println(f); //prints -234.23
System.out.println((double)f); //prints -234.22999572753906
}
catch (StandardException e)
{
e.printStackTrace();
}
}
}
> JDOQL test NotEquals comparing floating point numbers
> -----------------------------------------------------
>
> Key: JDO-206
> URL: http://issues.apache.org/jira/browse/JDO-206
> Project: JDO
> Type: Bug
> Components: tck20
> Reporter: Andy Jefferson
> Assignee: Erik Bengtson
>
> The current TCK test (carried over from JDO 1.0) for NotEquals, uses != operator on floating point numbers. This is not a good practice, and is unreliable. Its probably the case that the Equals test uses == on the same content, which also is not a good idea (as noted in the latest spec). These tests need reviewing and a reliable alternate strategy adopting
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (JDO-206) JDOQL test NotEquals comparing floating point numbers
Posted by "Michael Bouschen (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JDO-206?page=all ]
Michael Bouschen resolved JDO-206:
----------------------------------
Resolution: Fixed
Fixed with revision 358029.
> JDOQL test NotEquals comparing floating point numbers
> -----------------------------------------------------
>
> Key: JDO-206
> URL: http://issues.apache.org/jira/browse/JDO-206
> Project: JDO
> Type: Bug
> Components: tck20
> Reporter: Andy Jefferson
> Assignee: Michael Bouschen
> Attachments: JDO-206.patch, JDO-206.patch2
>
> The current TCK test (carried over from JDO 1.0) for NotEquals, uses != operator on floating point numbers. This is not a good practice, and is unreliable. Its probably the case that the Equals test uses == on the same content, which also is not a good idea (as noted in the latest spec). These tests need reviewing and a reliable alternate strategy adopting
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (JDO-206) JDOQL test NotEquals comparing floating point numbers
Posted by "Michelle Caisse (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JDO-206?page=all ]
Michelle Caisse reassigned JDO-206:
-----------------------------------
Assign To: Michael Bouschen (was: Erik Bengtson)
> JDOQL test NotEquals comparing floating point numbers
> -----------------------------------------------------
>
> Key: JDO-206
> URL: http://issues.apache.org/jira/browse/JDO-206
> Project: JDO
> Type: Bug
> Components: tck20
> Reporter: Andy Jefferson
> Assignee: Michael Bouschen
>
> The current TCK test (carried over from JDO 1.0) for NotEquals, uses != operator on floating point numbers. This is not a good practice, and is unreliable. Its probably the case that the Equals test uses == on the same content, which also is not a good idea (as noted in the latest spec). These tests need reviewing and a reliable alternate strategy adopting
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (JDO-206) JDOQL test NotEquals comparing floating point numbers
Posted by "Michael Bouschen (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JDO-206?page=all ]
Michael Bouschen updated JDO-206:
---------------------------------
Attachment: JDO-206.patch
I agree with Erik that there is a problem with derby since it converts the float value to a double when storing. However, this test class is not intended to test storing of float or double values, instead it should test the != operator in JDOQL queries. Thus I propose to use a different float value that does not change when converting it to a double, e.g. -234.25 instead of -234.23.
Attached you find a patch for review including the above change. It also added a localSetUp method adding a tearDown class to the test classes Equality, NotEquals, LessThan, LessThanOrEqual, GreaterThan, and GreaterThanOrEqual. All these tests did not clean up after test execution. Please note, if you run these tests after applying the patch, then they will most probably fail, because a previous run w/o the patch did not clean up the database. You nee to run the tests again.
> JDOQL test NotEquals comparing floating point numbers
> -----------------------------------------------------
>
> Key: JDO-206
> URL: http://issues.apache.org/jira/browse/JDO-206
> Project: JDO
> Type: Bug
> Components: tck20
> Reporter: Andy Jefferson
> Assignee: Michael Bouschen
> Attachments: JDO-206.patch
>
> The current TCK test (carried over from JDO 1.0) for NotEquals, uses != operator on floating point numbers. This is not a good practice, and is unreliable. Its probably the case that the Equals test uses == on the same content, which also is not a good idea (as noted in the latest spec). These tests need reviewing and a reliable alternate strategy adopting
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira