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
