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
