The requesters are potentially willing to merge changes or finance
development? We can discuss their requests and try to find solutions to
their problems which we can merge? /Erling
On 2017-10-15 16:55, Erling Hellenäs wrote:
Hi all!
Maybe we can first determine what the problem is, then use our
imagination to find possible solutions, then discuss the pros and cons
of each possible solution, and then take decisions?
People have different goals? Some wants to work together with others
against common goals? Some wants to magnify themselves and derogate
others? Some play their own favorite psychological game?
Those who want to derogate others always destroy all creative
processes by attacking all requesters? To be able to have creative
discussions we have to stop this? We have to hinder them from
attacking the person instead of discussing the facts? When it comes to
the facts, their critical input is most welcome, just a little later
in the creative process?
Cheers,
Erling Hellenäs
On 2017-10-15 14:18, bill lam wrote:
Even results from current J is not mathematically incorrect, I don't
think
patch or proposal will ever be accepted because efficiency is very
important of J. The same holds true for GPU which does even trap NAN.
Nothing personal, please don't feel offended.
On Oct 15, 2017 8:08 PM, "Erling Hellenäs" <[email protected]>
wrote:
I think you should probably move to a bugtracking system. Handle bugs
there instead of on the wiki. /Erling
On 2017-10-15 13:56, Erling Hellenäs wrote:
We have a similar problem with IEEE floats and underflow. All old
programs are written under the assumption that precision is not
lost in
division and multiplication operations. All old error estimations
are based
on this assumption. All these programs now give random results and
have to
be retested and rewritten, or we have to find a way to get an
exception
when we have an underflow. /Erling
On 2017-10-15 13:42, Erling Hellenäs wrote:
Is there a result of this factual discussion we could study?
As I see it the programmer is responsible for creating a program that
gives correct results in the domains in which it is specified to give
correct results.
If modulo gives correct results only in a certain domain, this domain
should be clear from the specification.
The programmer who uses it is then responsible for controlling inputs
and outputs, that they are in the correct domains.
However, since this makes the programs much more complicated, we
mostly
create programs which verify their inputs and outputs, and if not
in the
domains in which the results are correct, we issue an error or
exception.
Then there is a question of compatibility. Programs were created
before
the change to 64 bit integers. The programmer verified their
function, but
the verification is no longer valid, so these programs have to be
retested
and rewritten, or we are stuck with tools and systems which give
the users
random results, and which are therefore not useful any more. /Erling
On 2017-10-14 21:19, Don Guinn wrote:
I think we have had a factual discussion on the molulo problem.
We just
haven't found a good solution to the problem. Larger precision only
moves
the problem. It does not fix it. None of the possible solutions
presented
so far seem satisfactory because there are so many ways for them
to fail
anyway, if it is assumed that coming up with a residue of zero is
really
wrong when the numbers presented to residue exceed known precision
limits.
We learned several good things in this exercise. One, the square
root
of an
integer perfect square stays integer. Two, we can't count on
conversion
of
integer to float to be exact. Three, solutions to problems must be
realistic. There will almost always be compromises and tradeoffs. We
must
watch answers we get as was done by whoever asked the question in
the
first
place. That he asked the question is most important. It now makes
us all
aware of some possible problems we can get into when pushing the
limits
of
the hardware and software.
As to spinoffs. It is great for people to explore alternative
solutions
to
programming language problems, whether J, C or any other
language. But
they
are explorations. That doesn't mean that they will stand for the
test of
time. Ken and many others spent a lot of careful designing J. It is
important to fully understand their work before trying to
"improve" on
what
they did.
On Sat, Oct 14, 2017 at 12:32 PM, Erling Hellenäs <
[email protected]>
wrote:
Hi all !
I think all problems should be put into the bugtracker and that
there
should be factual discussions about how to solve them, so that,
should
anyone want to finance or merge a solution, they can do so.
If we deny that any problems exist there will be no development.
If we turn all requests for change down there will be no
development.
People are cloning J and are willing to supply their patches for
free.
If
we don't cooperate with them there will be no development.
Cheers,
Erling Hellenäs
On 2017-10-14 19:14, Don Guinn wrote:
I think that you are making this out to be a big problem. I don't
think it
is. We have much bigger problems with coming up with good
solutions to
problems. Scaling is one of the biggest. That J deals with
numbers as
numbers, not as integer or float or whatever and does not
predefine
limits
on array sizes removes many of the problems found in traditional
programming languages. At the same time it generates other
problems
like
double float cannot represent all 64 bit integers resulting in
loss of
precision with automatic conversion of integer to float.
Whether the benefits of J's approach outweigh the disadvantages
depends on
whom you ask. But possible solutions like those you suggested
are only
partial solutions. We need to watch for things that don't make
sense,
whether caused by our design, or the design of the programming
language.
They all have lots of gotchas.
On Sat, Oct 14, 2017 at 9:11 AM, Erling Hellenäs <
[email protected]>
wrote:
Hi all!
We now have an additional proposed solution from Raul, using
extended
precision and rationals instead of integers.
Any more proposed solutions?
Opinions about the proposed solutions?
Cheers,
Erling Hellenäs
On 2017-10-13 22:28, Erling Hellenäs wrote:
Hi all!
You moved to 64 bit integer. You can't go back. Now there is a
serious
problem? You have to determine how to solve it?
The simple solution is to move to quad precision floats? Is it
possible
to add support for keeping the integers ? The ability to do all
integer
arithmetic on integers? To stop auto-converting to floats? To
internally
work with quad precision floats in integer arithmetics?
Maybe you could add support for the new IEEE decimal
standard? Move
integer arithmetic to them?
Are there other solutions?
Cheers,
Erling Hellenäs
On 2017-10-08 16:54, Don Guinn wrote:
I realize this is stating the obvious, but the loss of
precision is
the
result of 64 bit integer support. Previously "upgrading" a
number
from
integer to float was exact. Though the residue problem for very
large
numbers still existed, at least it didn't involve loss of
precision.
It's my personal opinion that one should always be careful when
working
around the limits of a system. But what should be done when
things
go a
little crazy around those limits? It is unfortunate that
IEEE only
implemented indeterminate (_.) when it could have set other
flags
in
the
unused bit configuration to indicate things like underflow,
but not
zero
or
overflow but not infinity. But they didn't.
A while back J had an option for upgrade to go to rational
instead
of
float. It was useful in labs to more easily show interesting
properties
of
numbers. Is that option still around? If so it could be used in
mod as
an
option. But it cannot be always known that the number will
eventually
be
used in mod. And many transcendental verbs must go to float.
Current hardware now supports quad precision float, at least
some
do.
If
quad float were used then the loss of precision goes away when
converting
64 bit integer to float. But that doubles the size of float,
and
even
though memory is getting huge it's still a concern for big
problems.
Not
to
mention that quad float is probably slower than double
float. And
it
may
not be supported on all hardware, similar to the AVX problem.
IBM's PLI has an interesting approach to precision. You told
it (in
decimal
digits) the largest numbers you will deal with and the
number of
digits
after the decimal. Then it picked the best way to store the
numbers
given
available hardware. In J we have 64 bit integers and floats
with
maybe
16
significant decimal digits and a tremendous range for
exponents.
Most
problems we deal with don't need such big numbers. An argument
many use
against J in that it uses so much memory for small numbers.
Perhaps a
global setting with Foreign Conjunction could give a similar
choice for
J.
I would argue against it saying things like single/double/quad
float or
16/32/64 bit integers, but specify what range and
significance is
need
and
let J choose how to handle it. Including totally ignoring it
for
some
implementations. Supporting this could make the J engine
larger,
but
nobody
seems too concerned with the monstrous size Qt.
Whatever happened with the idea bouncing around of defining a
floating
point of arbitrary size and precision like with extended
integers
and
rationals?
And now IEEE has a decimal float standard. Right now it
seems that
only
IBM
has implemented it in hardware. But think of all the
confusion we
see
when
decimal numbers like 1.1 are not represented exactly in J.
Maybe I rambled a bit. But this all involves problems when,
for one
reason
or another, the hardware can't handle needed precision.
----------------------------------------------------------------------
For information about J forums see
http://www.jsoftware.com/forum
s.htm
----------------------------------------------------------------------
For information about J forums see
http://www.jsoftware.com/forum
s.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forum
s.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forum
s.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
----------------------------------------------------------------------
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
