Sorry, herein I disagree with Roger.
I think that Joey is correct. As is dly.
If J's origin is supposed to center (sorry, centre (evil grin)) around
_the_teachng_of_Mathematics_
then what _should_ be the case about J is that:
if
an entry is made that is valid Mathematics
then
the answer returned should also be completely valid Mathematics across
any and all paths it may take within the J processing system.
fi
Unfortunately the list of exceptions to the above principle _seems_ large
and it appears to be growing.
if
the principle is obeyed but default display formats either do or appear
to induce errors in the absoluteness of the correctness of the result
then
the Dictionary should be careful to note that case in all the relevant
places.
fi
If you do _not+_ do so, you create an additional learning burden on entry to
the J system that is misleading in the extreme:
The appearance of J being Mathematically correct, followed by the
appearance or actuality of lacking that quality
which in turn will lead to a negative disincentive against new novices in J
due to such self evident or _apparently_ self evident contradictions
A property I tend to prefer is uniform consistency.
I tend to dislike a number I enter with a particular type (1j0, complex) to
be rendered as another type (1, integer, real, rational, anything other
than complex).
One way to resolve such apparent inconsistencies is to have the concept of
deep and shallow typing
(deep: the minimum required to represent, shallow: what it was
entered//calcualted in);
resolving all such ambiguities can be complicated and not an easy choice for
_processing_ design (as distinguished from _language_ design);
arguably, reduction to minimal form will always be correct in some sense
PROVIDED that language NEVER loses _Mathematical_ significance;
so, careful definition of what _consistency_ is to be preferred has to be
considered.
Which may be where RH and I demur.
Keeping that significance thus would result in our different answers.
which seems to be the crux of the argument here.
SO, summarily summarizing here:
The significance of significance in J significantly seems to be that
it is insignificantly signified when loss of significance significantly
occurs, and thus, accrues.
Which in turn is significantly significant in what it in turn signifies
about J.
Or some such.
On 6/24/06, R&S HUI <[EMAIL PROTECTED]> wrote:
> IMHO, it would be a good idea to include a comment ...
I disagree.
The anmazing thig a bout RH is that whatever the point under discussion
is:
he is always significantly brief in his discussion of it.
Right or wrong. (evil leering grin).
----- Original Message -----
From: Joey K Tuttle <[EMAIL PROTECTED]>
Date: Saturday, June 24, 2006 9:34 am
Subject: Re: [Jgeneral] significant digits
> 365365365365365365x^2 NB. extended precision is nice
> 133491850208566925016658299941583225
>
> 36 ": 365365365365365365^2 NB. Speed demands approximations
> 133491850208566926593356837672714240
>
> But it went right past me that 8!: forces return to float and
> gives rather zany results...
>
> 'c0' 8!:2 ] 365365365365365365x^2
> 133,491,850,208,566,945,040,100,911,382,265,856
>
> For the want of a , the sense was lost...
>
> '0' 8!:2 ] 365365365365365365x^2
> 133491850208566945040100911382265856
>
> '0' 8!:2 ] 365365365365365365^2
> 133491850208566926593356837672714240
>
> 365365365365365365x^2
> 133491850208566925016658299941583225
>
> IMHO, it would be a good idea to include a comment in the 8!:
> documentation page that expands on the description - "y is
> usually an array of real numbers." to the effect that extended
> integers may cause erratic results.
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
--
--
Roy A. Crabtree
UNC '76 gaa.lifer#11086
Room 207 Studio Plus
123 East McCullough Drive
Charlotte, NC 28262-3306
336-340-1304 (office/home/cell/vmail)
704-510-0108x7404 (voicemail residence)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.authorsden.com/royacrabtree
http://skyscraper.fortunecity.com/activex/720/resume/full.doc
--
(c) RAC/IP, ARE,PRO,PAST
(Copyright) Roy Andrew Crabtree/In Perpetuity
All Rights/Reserved Explicitly
Public Reuse Only
Profits Always Safe Traded
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
