At 18:11 -0500 2009/08/08, Tom Arneson wrote:
>J uses IEEE floating point numbers for real numbers, so the built in PI verb
>o. (PI Times) has about 17 decimal digits of precision
>
>You can use the Format verb ": to convert the real value to a literal (or
>string):
>
> 0j16": o. 1
>3.1415926535897931
> 0j20": o. 1
>3.14159265358979310000
>
>Another way to use PI is the constant 1p1, which means 1 times PI raised to
>the 1st power:
>
> 0j8": 1p1
>3.14159265
> 0j20": 1p1
>3.14159265358979310000
>
Tom, What version of j (or how did you configure) returns the above results?
version ''
Installer: j602a_mac_powerpc.dmg
Engine: j602/2008-03-03/16:45
Library: 6.02.023
ProductName: Mac OS X Version: 10.5.8
0j50 ": o. 1
3.14159265358979311599796346854418516159057617187500
Which, of course, is not accurate as shown by -
0j50 ": pi 50
3.14159265358979323846264338327950288419716939937510
I was always bemused that Doug Forkes formatting (as described in Bob
Bernecky's message appended below) worked as in your second example
shown above, i.e. putting 0's after the last digit that was relevant
in determining the bits in the 64 bit floating point number.
I think the argument was that it was better to show an incorrect
number with 0s than to put other, very probably also incorrect,
digits there which might mislead the reader... But there are a few
numbers where the value can be displayed accurately e.g.
32 ": 2^100
1267650600228229401496703205376
and it seems to me to be reasonable to display the accurate result instead of
32 ": 2^100 NB. the result below was hand edited....
1267650600228229400000000000000
of course, taking the difference of the above, (because they are
converted to floating point upon entry) -
1267650600228229401496703205376 - 1267650600228229400000000000000
0
it is nice that j provides an extended precision facility (for hobbyists :) -
1267650600228229401496703205376x - 1267650600228229400000000000000x
1496703205376
~~~~ referenced prior message ~~~~
At 15:10 -0400 2009/08/07, Robert Bernecky wrote:
>Back in the dark ages, when mainframes walked the earth,
>we would get "bug reports" about once a month about
>the formatting of real numbers in SHARP APL. (For some unknown
>reason, 0.07 came up frequently.) The problem was
>that this number would display as something like:
>
> 0.070000000000001
>
>rather than as the 0.07 that the user had entered
>I had a talk with Larry Breed around that
>time, and he mentioned an idea for formatting that he had heard
>about, but at the time, it wasn't in print. The basic idea is
>this:
>
>1. There is a range R of real numbers which, if entered into
> a computer, all map to the same floating-point number internally.
>
>2. There is no way to determine which of the numbers originally
> was entered, hence there is no reason to pick one element of
> R over another as being somehow "more precise", when printing.
>
>3. Hence, when printing, pick the number from R that has the
> fewest significant digits.
>
>In the above example, of course, this is 0.07.
>
>We talked this over, and Doug Forkes ended up rewriting the
>real-number formatter along these lines. Net result: the
>"bug reports" stopped coming in. Not a single complaint about
>missing digits, etc.
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
