Re: [Jprogramming] 4 <3!:0 <. y WAS: Integer-floating type change for large numbers in j805 and j806
I see your point but how likely will a 9999. sort of situation occur? Drop 1 digit and the result will be 1e15. which is perfectly satisfactory. The problem is that when you push the limits of the size of a floating point number, the result is within the the tolerance level for 'close enough" to integer to be treated as one. This is inherent in APL and J and was done for a purpose. -the number of digits of a float will be less than for an integer because the float requires an exponent as well as a mantissa while then integer doesn't need the exponent. A 32bit word could hold a 31 bit number while a float with an 8 bit exponent would hold a 23 bit number r=:1.0009 r=1 1 r-1 8.88178e_16 r=:1.9 r=1 1 r-1 0 least significant bits lost because there is no room for them. in 99.+ % of cases this is not a problem. Don Kelly On 2017-08-11 2:11 AM, Henry Rich wrote: The error, methinks, is that 999...9. is rounded to integer and then reported as integer. It should keep floating type. Bit-twisting code needs to be sure that no bits have been lost. Integral type should be a guarantee of that. Floats that have values unrepresentable accurately should not be automatically called ints. Henry Rich On Aug 11, 2017 06:14, "Don Kelly" wrote: isn't an advantage of APL and J that the person writing a program/app/whatever, doesn't have to deal with the distinctions between integer and damn near integer within the limitations of the computer binary resolution?. In most cases this isa good thing because close enough -given the +/- of data input is sufficient for the idiot box to decide. J moves away from C/C++/ and other languages which often seem to be emphasizing stuff that Iverson tried to eliminate in APL and J . Muh of that stuff is something that can be handled by the idiot box so that: Problem-->basic analysis--. coding that fits the analysis rather than the details( users aim at the essentials rather than the details- "/I want the answer and I dont care about what is involved in the background of %,* */ The discussion below deals with representation of numeric values being floating point or integer when pushing the limits-IS IT IMPORTANT IN THE REAL WORLD unless you have a Cray in the back bedroom? Old fart expressing opinions Don Kelly On 2017-08-10 6:27 PM, Bill wrote: I suspect J interpreter didn't has the knowledge that the original string had been .3 with .3 because what J saw was the floating point result of parsing by c library. Ieee floating point has 15 to 16 significant digits so that 1e16 and 1e16-1 is the same number. Perhaps one could use long double to parse number on J64. Sent from my iPhone On 10 Aug, 2017, at 3:48 AM, Henry Rich wrote: Quite right. Henry Rich On Aug 9, 2017 20:46, "Raul Miller" wrote: Well, since it's encoded as an integer (which I would have noticed if I had read Bob Therriault's original post more closely), and not [like I was thinking] a float, I agree that dropping the .3 is better than adding a 1. That said, I guess we also should not object too loudly if .3 were instead encoded the same as +0.3 gets encoded. Thanks, -- Raul On Wed, Aug 9, 2017 at 3:25 PM, Henry Rich wrote: Surely integer 999...9 is a better value than 1000...0 . Henry Rich On Aug 9, 2017 18:33, "Raul Miller" wrote: It's not a bug, it's an artifact of the 64 bit floating point standard. 2 ^. 53.1508 https://en.wikipedia.org/wiki/IEEE_754#Basic_and_interchange_formats The binary64 format has 53 binary digits or 15.95 decimal digits. This means ".16#'9' cannot be represented exactly using this format. And, we do not use exact representation of large numbers by default because that's too slow for large datasets. Put differently, if you want exact representation and are willing to take the performance hit, you should specify that. For example: ".'x',~16#'9' or ".'3r10+','x',~16#'9' Thanks, -- Raul On Wed, Aug 9, 2017 at 12:05 PM, Henry Rich wrote: This is a bug, since 999...9.3 should become 999...9 rather than 100...0. I'm away from home now, but I think what's happening is this: 999...9 is converted to integer . is encountered and turns it to float It's rounded to the nearest float which is 100...0 As a final step the JE checks to see if the value is exactly integral, which it is, and it is converted back to integer. If you add this to Interpreter/Bugs I'll fix it when i get back. Henry Rich On Aug 9, 2017 16:16, "bill lam" wrote: I think this is the difference between 32 and 64-bit, 9!:14'' j602/2008-03-03/16:45 3!:0[ .3 4 In J32 a.i. 2 fc .3 0 128 224 55 121 195 65 67 a.i. 2 fc 1e16 0 128 224 55 121 195 65 67 the number has the same bit pattern as 1e16 (an integer) which can be represented as a 64-bit integer. I guess J64 is correct since .3 and 1e16 is
Re: [Jprogramming] 4 <3!:0 <. y WAS: Integer-floating type change for large numbers in j805 and j806
9.3x |ill-formed number could, it instead "parse" to 93r10 ? From: Henry Rich To: Programming forum Sent: Friday, August 11, 2017 5:11 AM Subject: [Jprogramming] 4 <3!:0 <. y WAS: Integer-floating type change for large numbers in j805 and j806 The error, methinks, is that 999...9. is rounded to integer and then reported as integer. It should keep floating type. Bit-twisting code needs to be sure that no bits have been lost. Integral type should be a guarantee of that. Floats that have values unrepresentable accurately should not be automatically called ints. Henry Rich On Aug 11, 2017 06:14, "Don Kelly" wrote: isn't an advantage of APL and J that the person writing a program/app/whatever, doesn't have to deal with the distinctions between integer and damn near integer within the limitations of the computer binary resolution?. In most cases this isa good thing because close enough -given the +/- of data input is sufficient for the idiot box to decide. J moves away from C/C++/ and other languages which often seem to be emphasizing stuff that Iverson tried to eliminate in APL and J . Muh of that stuff is something that can be handled by the idiot box so that: Problem-->basic analysis--. coding that fits the analysis rather than the details( users aim at the essentials rather than the details- "/I want the answer and I dont care about what is involved in the background of %,* */ The discussion below deals with representation of numeric values being floating point or integer when pushing the limits-IS IT IMPORTANT IN THE REAL WORLD unless you have a Cray in the back bedroom? Old fart expressing opinions Don Kelly On 2017-08-10 6:27 PM, Bill wrote: > I suspect J interpreter didn't has the knowledge that the original string > had been .3 > with .3 because what J saw was the floating point result of parsing by c > library. Ieee floating point has 15 to 16 significant digits so that 1e16 > and 1e16-1 is the same number. > > Perhaps one could use long double to parse number on J64. > > Sent from my iPhone > > On 10 Aug, 2017, at 3:48 AM, Henry Rich wrote: > > Quite right. >> >> Henry Rich >> >> On Aug 9, 2017 20:46, "Raul Miller" wrote: >> >> Well, since it's encoded as an integer (which I would have noticed if >>> I had read Bob Therriault's original post more closely), and not [like >>> I was thinking] a float, I agree that dropping the .3 is better than >>> adding a 1. >>> >>> That said, I guess we also should not object too loudly if >>> .3 were instead encoded the same as >>> +0.3 gets encoded. >>> >>> Thanks, >>> >>> -- >>> Raul >>> >>> On Wed, Aug 9, 2017 at 3:25 PM, Henry Rich wrote: >>> >>>> Surely integer 999...9 is a better value than 1000...0 . >>>> >>>> Henry Rich >>>> >>>> On Aug 9, 2017 18:33, "Raul Miller" wrote: >>>> >>>> It's not a bug, it's an artifact of the 64 bit floating point standard. >>>>> >>>>>2 ^. >>>>> 53.1508 >>>>> >>>>> https://en.wikipedia.org/wiki/IEEE_754#Basic_and_interchange_formats >>>>> >>>>> The binary64 format has 53 binary digits or 15.95 decimal digits. This >>>>> means ".16#'9' cannot be represented exactly using this format. >>>>> >>>>> And, we do not use exact representation of large numbers by default >>>>> because that's too slow for large datasets. Put differently, if you >>>>> want exact representation and are willing to take the performance hit, >>>>> you should specify that. For example: ".'x',~16#'9' or >>>>> ".'3r10+','x',~16#'9' >>>>> >>>>> Thanks, >>>>> >>>>> -- >>>>> Raul >>>>> >>>>> On Wed, Aug 9, 2017 at 12:05 PM, Henry Rich >>>>> >>>> wrote: >>> >>>> This is a bug, since 999...9.3 should become 999...9 rather than >>>>>> >>>>> 100...0. >>>>> >>>>>> I'm away from home now, but I think what's happening is this: >>>>>> >>>>>> 999...9 is converted to integer >>>>>> >&g
[Jprogramming] 4 <3!:0 <. y WAS: Integer-floating type change for large numbers in j805 and j806
The error, methinks, is that 999...9. is rounded to integer and then reported as integer. It should keep floating type. Bit-twisting code needs to be sure that no bits have been lost. Integral type should be a guarantee of that. Floats that have values unrepresentable accurately should not be automatically called ints. Henry Rich On Aug 11, 2017 06:14, "Don Kelly" wrote: isn't an advantage of APL and J that the person writing a program/app/whatever, doesn't have to deal with the distinctions between integer and damn near integer within the limitations of the computer binary resolution?. In most cases this isa good thing because close enough -given the +/- of data input is sufficient for the idiot box to decide. J moves away from C/C++/ and other languages which often seem to be emphasizing stuff that Iverson tried to eliminate in APL and J . Muh of that stuff is something that can be handled by the idiot box so that: Problem-->basic analysis--. coding that fits the analysis rather than the details( users aim at the essentials rather than the details- "/I want the answer and I dont care about what is involved in the background of %,* */ The discussion below deals with representation of numeric values being floating point or integer when pushing the limits-IS IT IMPORTANT IN THE REAL WORLD unless you have a Cray in the back bedroom? Old fart expressing opinions Don Kelly On 2017-08-10 6:27 PM, Bill wrote: > I suspect J interpreter didn't has the knowledge that the original string > had been .3 > with .3 because what J saw was the floating point result of parsing by c > library. Ieee floating point has 15 to 16 significant digits so that 1e16 > and 1e16-1 is the same number. > > Perhaps one could use long double to parse number on J64. > > Sent from my iPhone > > On 10 Aug, 2017, at 3:48 AM, Henry Rich wrote: > > Quite right. >> >> Henry Rich >> >> On Aug 9, 2017 20:46, "Raul Miller" wrote: >> >> Well, since it's encoded as an integer (which I would have noticed if >>> I had read Bob Therriault's original post more closely), and not [like >>> I was thinking] a float, I agree that dropping the .3 is better than >>> adding a 1. >>> >>> That said, I guess we also should not object too loudly if >>> .3 were instead encoded the same as >>> +0.3 gets encoded. >>> >>> Thanks, >>> >>> -- >>> Raul >>> >>> On Wed, Aug 9, 2017 at 3:25 PM, Henry Rich wrote: >>> Surely integer 999...9 is a better value than 1000...0 . Henry Rich On Aug 9, 2017 18:33, "Raul Miller" wrote: It's not a bug, it's an artifact of the 64 bit floating point standard. > >2 ^. > 53.1508 > > https://en.wikipedia.org/wiki/IEEE_754#Basic_and_interchange_formats > > The binary64 format has 53 binary digits or 15.95 decimal digits. This > means ".16#'9' cannot be represented exactly using this format. > > And, we do not use exact representation of large numbers by default > because that's too slow for large datasets. Put differently, if you > want exact representation and are willing to take the performance hit, > you should specify that. For example: ".'x',~16#'9' or > ".'3r10+','x',~16#'9' > > Thanks, > > -- > Raul > > On Wed, Aug 9, 2017 at 12:05 PM, Henry Rich > wrote: >>> This is a bug, since 999...9.3 should become 999...9 rather than >> > 100...0. > >> I'm away from home now, but I think what's happening is this: >> >> 999...9 is converted to integer >> >> . is encountered and turns it to float >> >> It's rounded to the nearest float which is 100...0 >> >> As a final step the JE checks to see if the value is exactly integral, >> which it is, and it is converted back to integer. >> >> If you add this to Interpreter/Bugs I'll fix it when i get back. >> >> Henry Rich >> >> On Aug 9, 2017 16:16, "bill lam" wrote: >> >> I think this is the difference between 32 and 64-bit, >> >>9!:14'' >> j602/2008-03-03/16:45 >>3!:0[ .3 >> 4 >> >> In J32 >> >>a.i. 2 fc .3 >> 0 128 224 55 121 195 65 67 >>a.i. 2 fc 1e16 >> 0 128 224 55 121 195 65 67 >> >> the number has the same bit pattern as 1e16 (an integer) >> which can be represented as a 64-bit integer. I guess >> J64 is correct since .3 and 1e16 is the >> same number in ieee fp and J prefers integer to floats, >> eg >> 3!:0 [ 2.0 >> 4 >> >> Ср, 09 авг 2017, robert therriault написал(а): >> >>> Hi Pascal, >>> >>> I see the same behaviour in j806 as j805. Do you see something >>> >> different? > >> JVERSION >>> Engine: j806/j64avx/darwin >>> Beta-4: commercial/2017-06-27T12:55:06 >>> Library: 8.06.03 >
