[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ShopSuite-dev] new rational.c, check it
From: |
Davi Leal |
Subject: |
Re: [ShopSuite-dev] new rational.c, check it |
Date: |
Wed, 22 Aug 2001 15:32:51 +0100 |
Tomasz Wegrzanowski wrote:
> Binary format changed from 128-bit (16 bytes) to 64-bit (8 bytes),
> so new rational.sql.in is attached, and all databases that
> uses rational plugin *must* be rebuild.
OK
> Plugin is much more solid that it was before,
> but it should be checked against stupid mistakes.
>
> Also operations on negative numbers should be included in check,
> as they were broken in old rational.c
See below.
> What about making automatic test in two files ?
> rational/test/queries.sql
> rational/test/expected.out
>
> That would help a lot.
Great idea, however, are two files needed?. What do you think about only using
rational/checks.sql with the expected value as a "SELECT (expected value);"
query?.
So both the expected and the got value must be the same, and the user checks it
easily due to both appears in adjacent lines. (I will be today evening at irc,
therefore, if you will be there, we will be able to discus the minor details).
List of initial suggested tests:
shop=> select rational('1/2') + rational('1/0');
0/0 <-- OK
shop=> select rational('0/2') + rational('1/3');
1/3 <-- OK
shop=> select rational('0/2') + rational('0/3');
0/1 <-- OK
shop=> select rational('0/2') + rational('0/0');
0/0 <-- OK
shop=> select rational('0/2') + rational('1/0');
0/0 <-- OK
shop=> INSERT INTO transform_ingredient VALUES(4,2,'9/0');
INSERT 94568 1
shop=> select * from transform_ingredient;
4 | 2 | 9/0 <-- It must be converted to '0/0'.
If you know additional useful tests ... for example the negative ones, could you
add it?.
-o-
I have carried out the above test set and I got bad results:
shop=> select rational('1/2') + rational('1/0');
0/0d
shop=> select rational('0/2') + rational('1/3');
0/0d
shop=> select rational('0/2') + rational('0/3');
0/0d
shop=> select rational('0/2') + rational('0/0');
ERROR: floating point exception! The last floating point operation either
exceeded
legal ranges or
was a divide by zero
shop=> select rational('0/2') + rational('1/0');
0/0d
shop=> INSERT INTO transform_ingredient VALUES(4,2,'9/0');
INSERT 110630 1
shop=> select * from transform_ingredient;
1 | 2 | 1/0d
Please, run the test set before sending rational.c to the dev list.
-------------
About the README I think that there is a mistake. See the attached one.
Specification of rational numbers format:
In rational plugin, n==32.
Rational number logically consists of:
n-bit signed integer numerator
n-bit unsigned integer denominator
Where sign of numerator is sign of whole rational number.
There are three types of rational numbers:
1. Non-Zero
numerator != 0
denominator != 0
gcd (abs(numerator), denominator) == 1
2. Zero
numerator == 0
denominator == 1
3. Not-A-Number
numerator == 0
denominator == 0
All other numbers are invalid, and result of any computations
with them is undefined. Rational numbers plugin must convert,
on input parsing, all invalid numbers to valid ones,
and must not allow any invalid number to appear as
result of computations.
Conversion tables:
1. Converted to Non-Zero
Invalid Number:
numerator != 0
denominator != 0
gcd (abs(numerator), denominator) != 1
Conversion algorithm:
numerator /= gcd (abs(numerator), denominator)
denominator /= gcd (abs(numerator), denominator)
2. Converted to Zero
Invalid Number:
numerator == 0
denominator != 0
denominator != 1
Conversion algorithm:
denominator = 1
3. Converted to Not-A-Number
Invalid Number:
numerator != 0
denominator == 0
Conversion algorithm:
numerator = 1
< numerator = 1 <------- Must be converted to 0 ???
< As above:
< 3. Not-A-Number
< numerator == 0
< denominator == 0
Result of any computation that includes Not-A-Number is Not-A-Number.
If and only if the result cannot fit into rational number format due to
overflow, it Not-A-Number is returned.
Rational numbers plugin must assure that correct result is returned
even if there could be overflow somewhere during computations.
This usually can be achieved by using twice as many bits in internal
computations than are be used in external representation.
Undef is not equal to any other rational number.
Results of other comparisions between undef and non-undef are undefined,
but they must be consintent and commutators and negators must be preserved.