Hi all!
I think either we work with integers or with floating point. We use
floating point when we have non-countable and integers when we have
countable data. Non countable data is things like measurable quantities
in engineering. Countable data is when we count a certain number of
things, when the result has to be exact numbers. Currency, time, date,
indices, hashes, cryptos.
When we use floating point we want the results to be as accurate as
possible. We want a certain number of accurate digits. We want efficient
calculations. We round the results.
When we use digital data the results typically have to be exact. The
credit and debit sides must match when we do book-keeping. When we work
with date and time data we expect the results to be exact. Our indices
have to be exact. Hashes and cryptos have to be exact.
Yet when we work with countable data we sometimes have to do floating
point calculations. We have to divide. We want to calculate the power of
a number in an efficient way. This is where our fuzzy floor, ceiling,
residue and antibase comes in. They are not there to give us any "fuzzy"
results. They are there for giving us exact results when we convert our
floating point data back to integer!
To convert a 64-bit integer to floating point without losing accuracy we
need a 128-bit float? That's no problem, our computers could handle this
for a long time? A floating-point unit in todays processors are 128 bit?
Comparison tolerance can then be set to something between 2^64 and
2^112, which is the precision of IEEE quadruple precision floating
point? We can avoid any risk of small errors in the calculations
slipping into our exact integer calculations? When converting back to
integer our results can be exact?
J is seriously fucked up regarding this and has to be fixed?
Cheers,
Erling
Den 2017-09-16 kl. 00:38, skrev Erling Hellenäs:
Hi all !
Yes, but for now my discussion was restricted to the fuzz as such. For
now I held the conversion errors out of my argumentation. We can then
see an inconsistency? We get different results for float and integer
arguments? With integers fuzzy floor and ceiling is not used, with
floats it is? We should get the same results? Either both should use
fuzzy floor and ceiling, or none should?
We can also see that we get zero results, when they should not be
zero? Our program recognizes an error, but does not notify the user of
it? Is that a reasonable behavior? We recognize an error, write no
error message and instead give the user a faulty result?
Then there is the question of possible random faults when the result
of floor is larger than it's argument, the error is multiplied with a
large number and digits are cut from the front of the result in the
subtraction. We have to find out if we can get faulty results that are
not acceptable?
For the conversion error case it is reasonable to assume that the
programmer should be aware of the auto-conversion of integers when
they are used in a float operation? That the float can hold only 16
digits? The alternative is to not have auto-conversion, to have an
explicit conversion operator? That's how it is in most programming
languages? As soon as there is a risk associated with the conversion
the programmer is forced to be explicit about it? Or it is not even
allowed?
Another question raised in the thread is if (14^2) should be real or
integer. In Nial, for example, it was integer. In F# you had to
explicitly make 14 and 2 to float before the operation. The result
could be easily calculated with 128 bit floats?
/Erling
On 2017-09-15 23:14, Don Guinn wrote:
Unfortunately, there are limits which computers give "right" answers.
Here
is a case where the wrong answer is given:
(14^2) |!.0] 57290824867848391
104
196 | 57290824867848391
99
Because the number on the right has no exact representation in float
double.
x:57290824867848391 0.5
57290824867848392 1r2
So, it's a hardware restriction. Either mod only accept integer
arguments
or we have to deal with it. The fuzz is applied to the result, which is
within fuzz. One thing I have thought might help is that fuzz be
applied to
the arguments and if they are both integral values, convert them to
integer
before applying mod.
On Fri, Sep 15, 2017 at 12:49 PM, Erling Hellenäs
<[email protected]>
wrote:
Even if we take care of the zero case, a fuzzy residue will deliver
random
errors much higher than the small errors which naturally affects real
numbers? Multiplied with a big number and then the lost precision of
the
subtraction can make these errors very significant? /Erling
On 2017-09-15 17:25, Erling Hellenäs wrote:
Hi all!
OK. I guess there is some way to implement this so that both Floor and
Residue are fuzzy without having the circular dependency. It seems to
basically be the implementation we have.
It seems Floor gives the closest integer within comparison
tolerance in
the way it is specified then.
9!:19 [ 5.68434e_14
25j5": (9!:18'') * 5729082486784839 % 196
1.66153
25j5":a=: 5729082486784839 % 196
29230012687677.75000
25j5": <. a
29230012687678.00000
It means that this result, which we find strange, is according to
specification?
(14^2) | 5729082486784839
0
It also means that this result, which we find correct, is not
according
to specification?
196 | 5729082486784839
147
So, now there is a question about if we should live with this
inconsistency or change the specification or the part of the
implementation
that is not according to this specification?
I think the efforts to create a consistent algebra is good.
However, in
my practical experience I found it important that functions give
correct
results. Incorrect results without any fault indication could mean
that the
patient dies, the bridge collapses or the company gets insolvent.
Could the
zero result really be considered correct? If not, is there a way in
which
we could deliver a fault indication instead of the zero result?
This means
we should have an error in the integer case and a NaN in the real
case?
Cheers,
Erling Hellenäs
Den 2017-09-15 kl. 14:13, skrev Raul Miller:
Eugene's work should be thought of as specification, rather than
implementation.
That said, chasing through the various implementations of floor for
the various C data types can be an interesting exercise.
Thanks,
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
