Re: [Jprogramming] Integer-floating type change for large numbers in j805 and j806

[Raul Miller]

This discussion really belongs on chat, But it looks like my previous
attempt to move it there is being ignored, so I'll respond here:

Value to who, though? Value is a subjective judgement, and subject to
change, so there's also potential accuracy gains in identifying when
it would have had that value.

That said, there's a lot of sales statistics that the actual numbers
are based on, and law of large numbers along with a variety of
institutional practices lends some credibility to those prices. But
those kinds of numbers bring in a variety of additional constraints
(including stuff like the rate at which it's sold and future changes
in those institutions).

Still, if you talk about economics without being away of the nature of
value, you will be woefully mislead in all sorts of ways.

Thanks,

-- 
Raul

On Mon, Aug 14, 2017 at 5:13 AM, 'Bo Jacoby' via Programming
 wrote:
> The value of a partially known oil reserve could be reported like this: 
> $100*10^(±1)
>
> Den 20:26 søndag den 13. august 2017 skrev Jimmy Gauvin 
> :
>
>
>  It gets even better with blind faith put into "algorithms" :
>
> A nice read on the subject can be found in Cathy O'Neil's book:
>
> https://weaponsofmathdestructionbook.com/
>
> On Sun, Aug 13, 2017 at 10:17 AM, Don Guinn  wrote:
>
>> What bothers me is that even though the source of data is unreliable, once
>> run through a computer program people tend to believe that now the results
>> are very accurate. One particular measure is oil reserves in the USA and
>> world. We don't even know within a power of 10 what is out there. Do we
>> include various methods of recovery like secondary, tertiary, various
>> injection methods in our estimates? What fields being explored now may
>> produce? We only have rough estimates on the size of fields. Yet oil
>> companies have to report to the government the value of these reserves to
>> the dollar.
>>
>> On Sat, Aug 12, 2017 at 8:43 PM, Don Kelly  wrote:
>>
>> > I think that Don Guinn was referring to the fact that the output results
>> > from input of n sig figs will not be good to anything better than n  sig
>> > figs. You have pointed out limits in  the representation of base 10
>> > integers in a base 2 system. In fact, the results of multiplying 2 4
>> digit
>> > numbers might result in an overflow or conversion to float with
>> truncation.
>> >
>> > Don Kelly
>> > On 2017-08-12 12:19 PM, 'Bo Jacoby' via Programming wrote:
>> >
>> >> Don Guinn wrote: "But few things need precision beyond 16 significant
>> >> digits". Well, just computing the determinant of a 4*4 matrix of
>> 4-figure
>> >> integers require 16 digit precision!
>> >>
>> >>  Den 1:52 lørdag den 12. august 2017 skrev Don Kelly > >:
>> >>
>> >>  Right on!
>> >>
>> >> In most numerical operations on a  computer, there is an inherent
>> >> propagation of errors (in fact Numerical analysis texts spend a lot of
>> >> effort on ways to reduce such errors) and 16 or more digits don't
>> >> provide precision greater than  that of the input data but do reduce the
>> >> computational  fuzz to an insignificant level. The ideal kit for a
>> >> student using a hand calculator would be a strip of electrical tape to
>> >> cover the extra digits.
>> >>
>> >> Don Kelly
>> >>
>> >>
>> >> On 2017-08-11 6:33 AM, Don Guinn wrote:
>> >>
>> >>> We too often assume that calculations carried out to 16 significant
>> >>> digits
>> >>> are accurate when the input may not be known to less than 2 or 3
>> >>> significant digits. We can calculate the distance to the moon
>> accurately
>> >>> to
>> >>> the wavelength of visible light in IEEE floating point. We can
>> calculate
>> >>> the national debt to the penny. Maybe calculating relativistic effects
>> >>> on a
>> >>> satellite orbiting the earth might exceed IEEE floating point. But few
>> >>> things need precision beyond 16 significant digits.
>> >>>
>> >>> On Thu, Aug 10, 2017 at 11:14 PM, 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 

Re: [Jprogramming] Integer-floating type change for large numbers in j805 and j806

['Bo Jacoby' via Programming]

The value of a partially known oil reserve could be reported like this: 
$100*10^(±1)  

Den 20:26 søndag den 13. august 2017 skrev Jimmy Gauvin 
:
 

 It gets even better with blind faith put into "algorithms" :

A nice read on the subject can be found in Cathy O'Neil's book:

https://weaponsofmathdestructionbook.com/

On Sun, Aug 13, 2017 at 10:17 AM, Don Guinn  wrote:

> What bothers me is that even though the source of data is unreliable, once
> run through a computer program people tend to believe that now the results
> are very accurate. One particular measure is oil reserves in the USA and
> world. We don't even know within a power of 10 what is out there. Do we
> include various methods of recovery like secondary, tertiary, various
> injection methods in our estimates? What fields being explored now may
> produce? We only have rough estimates on the size of fields. Yet oil
> companies have to report to the government the value of these reserves to
> the dollar.
>
> On Sat, Aug 12, 2017 at 8:43 PM, Don Kelly  wrote:
>
> > I think that Don Guinn was referring to the fact that the output results
> > from input of n sig figs will not be good to anything better than n  sig
> > figs. You have pointed out limits in  the representation of base 10
> > integers in a base 2 system. In fact, the results of multiplying 2 4
> digit
> > numbers might result in an overflow or conversion to float with
> truncation.
> >
> > Don Kelly
> > On 2017-08-12 12:19 PM, 'Bo Jacoby' via Programming wrote:
> >
> >> Don Guinn wrote: "But few things need precision beyond 16 significant
> >> digits". Well, just computing the determinant of a 4*4 matrix of
> 4-figure
> >> integers require 16 digit precision!
> >>
> >>      Den 1:52 lørdag den 12. august 2017 skrev Don Kelly  >:
> >>
> >>  Right on!
> >>
> >> In most numerical operations on a  computer, there is an inherent
> >> propagation of errors (in fact Numerical analysis texts spend a lot of
> >> effort on ways to reduce such errors) and 16 or more digits don't
> >> provide precision greater than  that of the input data but do reduce the
> >> computational  fuzz to an insignificant level. The ideal kit for a
> >> student using a hand calculator would be a strip of electrical tape to
> >> cover the extra digits.
> >>
> >> Don Kelly
> >>
> >>
> >> On 2017-08-11 6:33 AM, Don Guinn wrote:
> >>
> >>> We too often assume that calculations carried out to 16 significant
> >>> digits
> >>> are accurate when the input may not be known to less than 2 or 3
> >>> significant digits. We can calculate the distance to the moon
> accurately
> >>> to
> >>> the wavelength of visible light in IEEE floating point. We can
> calculate
> >>> the national debt to the penny. Maybe calculating relativistic effects
> >>> on a
> >>> satellite orbiting the earth might exceed IEEE floating point. But few
> >>> things need precision beyond 16 significant digits.
> >>>
> >>> On Thu, Aug 10, 2017 at 11:14 PM, 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 

Re: [Jprogramming] Integer-floating type change for large numbers in j805 and j806

[Jimmy Gauvin]

It gets even better with blind faith put into "algorithms" :

A nice read on the subject can be found in Cathy O'Neil's book:

https://weaponsofmathdestructionbook.com/

On Sun, Aug 13, 2017 at 10:17 AM, Don Guinn  wrote:

> What bothers me is that even though the source of data is unreliable, once
> run through a computer program people tend to believe that now the results
> are very accurate. One particular measure is oil reserves in the USA and
> world. We don't even know within a power of 10 what is out there. Do we
> include various methods of recovery like secondary, tertiary, various
> injection methods in our estimates? What fields being explored now may
> produce? We only have rough estimates on the size of fields. Yet oil
> companies have to report to the government the value of these reserves to
> the dollar.
>
> On Sat, Aug 12, 2017 at 8:43 PM, Don Kelly  wrote:
>
> > I think that Don Guinn was referring to the fact that the output results
> > from input of n sig figs will not be good to anything better than n  sig
> > figs. You have pointed out limits in  the representation of base 10
> > integers in a base 2 system. In fact, the results of multiplying 2 4
> digit
> > numbers might result in an overflow or conversion to float with
> truncation.
> >
> > Don Kelly
> > On 2017-08-12 12:19 PM, 'Bo Jacoby' via Programming wrote:
> >
> >> Don Guinn wrote: "But few things need precision beyond 16 significant
> >> digits". Well, just computing the determinant of a 4*4 matrix of
> 4-figure
> >> integers require 16 digit precision!
> >>
> >>  Den 1:52 lørdag den 12. august 2017 skrev Don Kelly  >:
> >>
> >>   Right on!
> >>
> >> In most numerical operations on a  computer, there is an inherent
> >> propagation of errors (in fact Numerical analysis texts spend a lot of
> >> effort on ways to reduce such errors) and 16 or more digits don't
> >> provide precision greater than  that of the input data but do reduce the
> >> computational  fuzz to an insignificant level. The ideal kit for a
> >> student using a hand calculator would be a strip of electrical tape to
> >> cover the extra digits.
> >>
> >> Don Kelly
> >>
> >>
> >> On 2017-08-11 6:33 AM, Don Guinn wrote:
> >>
> >>> We too often assume that calculations carried out to 16 significant
> >>> digits
> >>> are accurate when the input may not be known to less than 2 or 3
> >>> significant digits. We can calculate the distance to the moon
> accurately
> >>> to
> >>> the wavelength of visible light in IEEE floating point. We can
> calculate
> >>> the national debt to the penny. Maybe calculating relativistic effects
> >>> on a
> >>> satellite orbiting the earth might exceed IEEE floating point. But few
> >>> things need precision beyond 16 significant digits.
> >>>
> >>> On Thu, Aug 10, 2017 at 11:14 PM, 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 

Re: [Jprogramming] Integer-floating type change for large numbers in j805 and j806

[Don Guinn]

What bothers me is that even though the source of data is unreliable, once
run through a computer program people tend to believe that now the results
are very accurate. One particular measure is oil reserves in the USA and
world. We don't even know within a power of 10 what is out there. Do we
include various methods of recovery like secondary, tertiary, various
injection methods in our estimates? What fields being explored now may
produce? We only have rough estimates on the size of fields. Yet oil
companies have to report to the government the value of these reserves to
the dollar.

On Sat, Aug 12, 2017 at 8:43 PM, Don Kelly  wrote:

> I think that Don Guinn was referring to the fact that the output results
> from input of n sig figs will not be good to anything better than n  sig
> figs. You have pointed out limits in  the representation of base 10
> integers in a base 2 system. In fact, the results of multiplying 2 4 digit
> numbers might result in an overflow or conversion to float with truncation.
>
> Don Kelly
> On 2017-08-12 12:19 PM, 'Bo Jacoby' via Programming wrote:
>
>> Don Guinn wrote: "But few things need precision beyond 16 significant
>> digits". Well, just computing the determinant of a 4*4 matrix of 4-figure
>> integers require 16 digit precision!
>>
>>  Den 1:52 lørdag den 12. august 2017 skrev Don Kelly :
>>
>>   Right on!
>>
>> In most numerical operations on a  computer, there is an inherent
>> propagation of errors (in fact Numerical analysis texts spend a lot of
>> effort on ways to reduce such errors) and 16 or more digits don't
>> provide precision greater than  that of the input data but do reduce the
>> computational  fuzz to an insignificant level. The ideal kit for a
>> student using a hand calculator would be a strip of electrical tape to
>> cover the extra digits.
>>
>> Don Kelly
>>
>>
>> On 2017-08-11 6:33 AM, Don Guinn wrote:
>>
>>> We too often assume that calculations carried out to 16 significant
>>> digits
>>> are accurate when the input may not be known to less than 2 or 3
>>> significant digits. We can calculate the distance to the moon accurately
>>> to
>>> the wavelength of visible light in IEEE floating point. We can calculate
>>> the national debt to the penny. Maybe calculating relativistic effects
>>> on a
>>> satellite orbiting the earth might exceed IEEE floating point. But few
>>> things need precision beyond 16 significant digits.
>>>
>>> On Thu, Aug 10, 2017 at 11:14 PM, 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 

Re: [Jprogramming] Integer-floating type change for large numbers in j805 and j806

[Don Kelly]

I think that Don Guinn was referring to the fact that the output results 
from input of n sig figs will not be good to anything better than n  sig 
figs. You have pointed out limits in  the representation of base 10 
integers in a base 2 system. In fact, the results of multiplying 2 4 
digit numbers might result in an overflow or conversion to float with 
truncation.


Don Kelly
On 2017-08-12 12:19 PM, 'Bo Jacoby' via Programming wrote:

Don Guinn wrote: "But few things need precision beyond 16 significant digits". 
Well, just computing the determinant of a 4*4 matrix of 4-figure integers require 16 
digit precision!

 Den 1:52 lørdag den 12. august 2017 skrev Don Kelly :
  


  Right on!

In most numerical operations on a  computer, there is an inherent
propagation of errors (in fact Numerical analysis texts spend a lot of
effort on ways to reduce such errors) and 16 or more digits don't
provide precision greater than  that of the input data but do reduce the
computational  fuzz to an insignificant level. The ideal kit for a
student using a hand calculator would be a strip of electrical tape to
cover the extra digits.

Don Kelly


On 2017-08-11 6:33 AM, Don Guinn wrote:

We too often assume that calculations carried out to 16 significant digits
are accurate when the input may not be known to less than 2 or 3
significant digits. We can calculate the distance to the moon accurately to
the wavelength of visible light in IEEE floating point. We can calculate
the national debt to the penny. Maybe calculating relativistic effects on a
satellite orbiting the earth might exceed IEEE floating point. But few
things need precision beyond 16 significant digits.

On Thu, Aug 10, 2017 at 11:14 PM, 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 

Re: [Jprogramming] Integer-floating type change for large numbers in j805 and j806

['Bo Jacoby' via Programming]

Don Guinn wrote: "But few things need precision beyond 16 significant digits". 
Well, just computing the determinant of a 4*4 matrix of 4-figure integers 
require 16 digit precision! 

Den 1:52 lørdag den 12. august 2017 skrev Don Kelly :
 

 Right on!

In most numerical operations on a  computer, there is an inherent 
propagation of errors (in fact Numerical analysis texts spend a lot of 
effort on ways to reduce such errors) and 16 or more digits don't 
provide precision greater than  that of the input data but do reduce the 
computational  fuzz to an insignificant level. The ideal kit for a 
student using a hand calculator would be a strip of electrical tape to 
cover the extra digits.

Don Kelly


On 2017-08-11 6:33 AM, Don Guinn wrote:
> We too often assume that calculations carried out to 16 significant digits
> are accurate when the input may not be known to less than 2 or 3
> significant digits. We can calculate the distance to the moon accurately to
> the wavelength of visible light in IEEE floating point. We can calculate
> the national debt to the penny. Maybe calculating relativistic effects on a
> satellite orbiting the earth might exceed IEEE floating point. But few
> things need precision beyond 16 significant digits.
>
> On Thu, Aug 10, 2017 at 11:14 PM, 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 

Re: [Jprogramming] Integer-floating type change for large numbers in j805 and j806

[Don Kelly]

Right on!

In most numerical operations on a  computer, there is an inherent 
propagation of errors (in fact Numerical analysis texts spend a lot of 
effort on ways to reduce such errors) and 16 or more digits don't 
provide precision greater than  that of the input data but do reduce the 
computational  fuzz to an insignificant level. The ideal kit for a 
student using a hand calculator would be a strip of electrical tape to 
cover the extra digits.


Don Kelly


On 2017-08-11 6:33 AM, Don Guinn wrote:

We too often assume that calculations carried out to 16 significant digits
are accurate when the input may not be known to less than 2 or 3
significant digits. We can calculate the distance to the moon accurately to
the wavelength of visible light in IEEE floating point. We can calculate
the national debt to the penny. Maybe calculating relativistic effects on a
satellite orbiting the earth might exceed IEEE floating point. But few
things need precision beyond 16 significant digits.

On Thu, Aug 10, 2017 at 11:14 PM, 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 

Re: [Jprogramming] Integer-floating type change for large numbers in j805 and j806

[Jimmy Gauvin]

A casual glance at the following table reminds us to be wary of binary
decimal interaction whether we have reached the end of the 16 significant
digits or not.

   (_17|.1j1,63#1)#"1(64$'..|:..'),64j62 ":,.  0.01 *i.101
..|:|: |:|:|:|:|.
0. 00
0.0100 0020816681711721685132943093776702880859375000
0.0200 004163336342344337026588618755340576171875
0.0299 988897769753748434595763683319091796875000
0.0400 008326672684688674053177237510681152343750
0.0500 027755575615628913510590791702270507812500
0.0599 97779553950749686919152736663818359375


As usual, J has a solution for this:

   (_17|.1j1,63#1)#"1(64$'..|:..'),64j62 ":,.  100%~i.101x
..|:|: |:|:|:|:|.
0. 00
0.0100 00
0.0200 00
0.0300 00
0.0400 00
0.0500 00
0.0600 00
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] Integer-floating type change for large numbers in j805 and j806

[Don Guinn]

We too often assume that calculations carried out to 16 significant digits
are accurate when the input may not be known to less than 2 or 3
significant digits. We can calculate the distance to the moon accurately to
the wavelength of visible light in IEEE floating point. We can calculate
the national debt to the penny. Maybe calculating relativistic effects on a
satellite orbiting the earth might exceed IEEE floating point. But few
things need precision beyond 16 significant digits.

On Thu, Aug 10, 2017 at 11:14 PM, 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 

Re: [Jprogramming] Integer-floating type change for large numbers in j805 and j806

[Don Kelly]

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
Qt IDE: 1.5.3/5.6.2
Platform: Darwin 64
Installer: J806 install
InstallPath: /users/bobtherriault/j64-806
Contact: www.jsoftware.com
   (; datatype) 999.3
┌┬┐
│1e15│floating│
└┴┘
   (; datatype) .3
┌─┬───┐
│1│integer│
└─┴───┘
   (; datatype) 9.3
┌──┬───┐
│10│integer│
└──┴───┘
   (; datatype) 99.3
┌───┬───┐
│100│integer│
└───┴───┘
   (; datatype) 999.3
┌┬┐
│1e19│floating│
└┴┘

Cheers, bob


On Aug 9, 2017, at 7:54 AM, 'Pascal Jasmin' via Programming <

programm...@jsoftware.com> wrote:

in j806,.31 probably the j805

Re: [Jprogramming] Integer-floating type change for large numbers in j805 and j806

[Bill]

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
>> Qt IDE: 1.5.3/5.6.2
>> Platform: Darwin 64
>> Installer: J806 install
>> InstallPath: /users/bobtherriault/j64-806
>> Contact: www.jsoftware.com
>>   (; datatype) 999.3
>> ┌┬┐
>> │1e15│floating│
>> └┴┘
>>   (; datatype) .3
>> ┌─┬───┐
>> │1│integer│
>> └─┴───┘
>>   (; datatype) 9.3
>> ┌──┬───┐
>> │10│integer│
>> └──┴───┘
>>   (; datatype) 99.3
>> ┌───┬───┐
>> │100│integer│
>> └───┴───┘
>>   (; datatype) 999.3
>> ┌┬┐
>> │1e19│floating│
>> └┴┘
>> 
>> Cheers, bob
>> 
>>> On Aug 9, 2017, at 7:54 AM, 'Pascal Jasmin' via Programming <
> programm...@jsoftware.com> wrote:
>>> 
>>> in j806,.31 probably the j805
> behaviour is preferred.  If only for consistency.  But there may be a
 good
> reason for change.
>>> 
>>> From: robert therriault 
>>> To: Programming forum 
>>> Sent: Wednesday, August 9, 2017 10:40 AM
>>> Subject: [Jprogramming] Integer-floating type change for large
>> numbers
> in 

Re: [Jprogramming] Integer-floating type change for large numbers in j805 and j806

[Henry Rich]

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
> >> >> Qt IDE: 1.5.3/5.6.2
> >> >> Platform: Darwin 64
> >> >> Installer: J806 install
> >> >> InstallPath: /users/bobtherriault/j64-806
> >> >> Contact: www.jsoftware.com
> >> >>(; datatype) 999.3
> >> >> ┌┬┐
> >> >> │1e15│floating│
> >> >> └┴┘
> >> >>(; datatype) .3
> >> >> ┌─┬───┐
> >> >> │1│integer│
> >> >> └─┴───┘
> >> >>(; datatype) 9.3
> >> >> ┌──┬───┐
> >> >> │10│integer│
> >> >> └──┴───┘
> >> >>(; datatype) 99.3
> >> >> ┌───┬───┐
> >> >> │100│integer│
> >> >> └───┴───┘
> >> >>(; datatype) 999.3
> >> >> ┌┬┐
> >> >> │1e19│floating│
> >> >> └┴┘
> >> >>
> >> >> Cheers, bob
> >> >>
> >> >> > On Aug 9, 2017, at 7:54 AM, 'Pascal Jasmin' via Programming <
> >> > programm...@jsoftware.com> wrote:
> >> >> >
> >> >> > in j806,.31 probably the j805
> >> > behaviour is preferred.  If only for consistency.  But there may be a
> >> good
> >> > reason for change.
> >> >> >
> >> >> >  From: robert therriault 
> >> >> > To: Programming forum 
> >> >> > Sent: Wednesday, August 9, 2017 10:40 AM
> >> >> > Subject: [Jprogramming] Integer-floating type change for large
> numbers
> >> > in j805 and j806
> >> >> >
> >> >> > I am guessing that the following has something to do with
> precision of
> >> > large numbers in j805 and is also true for j806.
> >> >> >
> >> >> >   (; datatype) 999.3
> >> >> > ┌┬┐
> >> >> > │1e15│floating│
> >> >> > └┴┘
> >> >> >   (; datatype) .3
> >> >> > ┌─┬───┐
> >> >> > 

Re: [Jprogramming] Integer-floating type change for large numbers in j805 and j806

[Raul Miller]

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
>> >> Qt IDE: 1.5.3/5.6.2
>> >> Platform: Darwin 64
>> >> Installer: J806 install
>> >> InstallPath: /users/bobtherriault/j64-806
>> >> Contact: www.jsoftware.com
>> >>(; datatype) 999.3
>> >> ┌┬┐
>> >> │1e15│floating│
>> >> └┴┘
>> >>(; datatype) .3
>> >> ┌─┬───┐
>> >> │1│integer│
>> >> └─┴───┘
>> >>(; datatype) 9.3
>> >> ┌──┬───┐
>> >> │10│integer│
>> >> └──┴───┘
>> >>(; datatype) 99.3
>> >> ┌───┬───┐
>> >> │100│integer│
>> >> └───┴───┘
>> >>(; datatype) 999.3
>> >> ┌┬┐
>> >> │1e19│floating│
>> >> └┴┘
>> >>
>> >> Cheers, bob
>> >>
>> >> > On Aug 9, 2017, at 7:54 AM, 'Pascal Jasmin' via Programming <
>> > programm...@jsoftware.com> wrote:
>> >> >
>> >> > in j806,.31 probably the j805
>> > behaviour is preferred.  If only for consistency.  But there may be a
>> good
>> > reason for change.
>> >> >
>> >> >  From: robert therriault 
>> >> > To: Programming forum 
>> >> > Sent: Wednesday, August 9, 2017 10:40 AM
>> >> > Subject: [Jprogramming] Integer-floating type change for large numbers
>> > in j805 and j806
>> >> >
>> >> > I am guessing that the following has something to do with precision of
>> > large numbers in j805 and is also true for j806.
>> >> >
>> >> >   (; datatype) 999.3
>> >> > ┌┬┐
>> >> > │1e15│floating│
>> >> > └┴┘
>> >> >   (; datatype) .3
>> >> > ┌─┬───┐
>> >> > │1│integer│
>> >> > └─┴───┘
>> >> >   (; datatype) 9.3
>> >> > ┌──┬───┐
>> >> > │10│integer│
>> >> > └──┴───┘
>> >> >   (; datatype) 99.3
>> >> > ┌───┬───┐
>> >> > │100│integer│
>> >> > └───┴───┘
>> >> >   (; 

Re: [Jprogramming] Integer-floating type change for large numbers in j805 and j806

[Henry Rich]

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
> >> Qt IDE: 1.5.3/5.6.2
> >> Platform: Darwin 64
> >> Installer: J806 install
> >> InstallPath: /users/bobtherriault/j64-806
> >> Contact: www.jsoftware.com
> >>(; datatype) 999.3
> >> ┌┬┐
> >> │1e15│floating│
> >> └┴┘
> >>(; datatype) .3
> >> ┌─┬───┐
> >> │1│integer│
> >> └─┴───┘
> >>(; datatype) 9.3
> >> ┌──┬───┐
> >> │10│integer│
> >> └──┴───┘
> >>(; datatype) 99.3
> >> ┌───┬───┐
> >> │100│integer│
> >> └───┴───┘
> >>(; datatype) 999.3
> >> ┌┬┐
> >> │1e19│floating│
> >> └┴┘
> >>
> >> Cheers, bob
> >>
> >> > On Aug 9, 2017, at 7:54 AM, 'Pascal Jasmin' via Programming <
> > programm...@jsoftware.com> wrote:
> >> >
> >> > in j806,.31 probably the j805
> > behaviour is preferred.  If only for consistency.  But there may be a
> good
> > reason for change.
> >> >
> >> >  From: robert therriault 
> >> > To: Programming forum 
> >> > Sent: Wednesday, August 9, 2017 10:40 AM
> >> > Subject: [Jprogramming] Integer-floating type change for large numbers
> > in j805 and j806
> >> >
> >> > I am guessing that the following has something to do with precision of
> > large numbers in j805 and is also true for j806.
> >> >
> >> >   (; datatype) 999.3
> >> > ┌┬┐
> >> > │1e15│floating│
> >> > └┴┘
> >> >   (; datatype) .3
> >> > ┌─┬───┐
> >> > │1│integer│
> >> > └─┴───┘
> >> >   (; datatype) 9.3
> >> > ┌──┬───┐
> >> > │10│integer│
> >> > └──┴───┘
> >> >   (; datatype) 99.3
> >> > ┌───┬───┐
> >> > │100│integer│
> >> > └───┴───┘
> >> >   (; datatype) 999.3
> >> > ┌┬┐
> >> > │1e19│floating│
> >> > └┴┘
> >> >   JVERSION
> >> > Engine: j805/j64/darwin
> >> > Release: commercial/2016-12-11T08:17:56
> >> > Library: 8.05.14
> >> > Qt IDE: 1.5.4/5.6.2
> >> > Platform: Darwin 64
> >> > Installer: J805 install
> >> > InstallPath: /applications/j64-805
> >> > Contact: www.jsoftware.com
> >> >
> >> > Further investigation shows me it was not this way with the 32 bit
> > version of j701, so it may be an artifact of moving to 64 bit?
> >> >
> >> >   (; datatype) 999.3
> >> > ┌┬┐
> >> 

Re: [Jprogramming] Integer-floating type change for large numbers in j805 and j806

[Vijay Lulla]

Though not quite the same issue but is this related to the behavior listed
at http://geocar.sdf1.org/numbers.html ?

On Wed, Aug 9, 2017 at 2:17 PM, robert therriault 
wrote:

> I was more surprised by the type change within a certain numeric range.
>
> That just seemed a little...odd.
>
> I guess that even though it feels strange to have a constant change type
> just by being
> entered, it's not really any different than these examples.
>
> (; datatype) 3j0
> ┌─┬───┐
> │3│integer│
> └─┴───┘
>(; datatype) 3.0
> ┌─┬───┐
> │3│integer│
> └─┴───┘
>(; datatype) 3.6j0
> ┌───┬┐
> │3.6│floating│
> └───┴┘
>(; datatype) 3r5j0
> ┌───┬┐
> │0.6│floating│
> └───┴┘
>
> Cheers, bob
>
> > On Aug 9, 2017, at 10:33 AM, 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
> >>> Qt IDE: 1.5.3/5.6.2
> >>> Platform: Darwin 64
> >>> Installer: J806 install
> >>> InstallPath: /users/bobtherriault/j64-806
> >>> Contact: www.jsoftware.com
> >>>   (; datatype) 999.3
> >>> ┌┬┐
> >>> │1e15│floating│
> >>> └┴┘
> >>>   (; datatype) .3
> >>> ┌─┬───┐
> >>> │1│integer│
> >>> └─┴───┘
> >>>   (; datatype) 9.3
> >>> ┌──┬───┐
> >>> │10│integer│
> >>> └──┴───┘
> >>>   (; datatype) 99.3
> >>> ┌───┬───┐
> >>> │100│integer│
> >>> └───┴───┘
> >>>   (; datatype) 999.3
> >>> ┌┬┐
> >>> │1e19│floating│
> >>> └┴┘
> >>>
> >>> Cheers, bob
> >>>
>  On Aug 9, 2017, at 7:54 AM, 'Pascal Jasmin' via Programming <
> >> programm...@jsoftware.com> wrote:
> 
>  in j806,.31 probably the j805
> >> behaviour is preferred.  If only for consistency.  But there may be a
> good
> >> reason for change.
> 
>  From: robert therriault 
>  To: Programming forum 
>  Sent: Wednesday, August 9, 2017 10:40 AM
>  Subject: [Jprogramming] Integer-floating type change for large numbers
> >> in j805 and j806
> 
>  I am guessing that the following has something to do with precision of
> >> large numbers in j805 and is also true for j806.
> 
>   (; datatype) 999.3
>  ┌┬┐
>  │1e15│floating│
>  └┴┘
>   (; datatype) .3
>  ┌─┬───┐
>  │1│integer│
>  └─┴───┘
>   (; datatype) 9.3
>  ┌──┬───┐
>  

Re: [Jprogramming] Integer-floating type change for large numbers in j805 and j806

[robert therriault]

I was more surprised by the type change within a certain numeric range.

That just seemed a little...odd. 

I guess that even though it feels strange to have a constant change type just 
by being
entered, it's not really any different than these examples.

(; datatype) 3j0
┌─┬───┐
│3│integer│
└─┴───┘
   (; datatype) 3.0
┌─┬───┐
│3│integer│
└─┴───┘
   (; datatype) 3.6j0
┌───┬┐
│3.6│floating│
└───┴┘
   (; datatype) 3r5j0
┌───┬┐
│0.6│floating│
└───┴┘

Cheers, bob

> On Aug 9, 2017, at 10:33 AM, 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
>>> Qt IDE: 1.5.3/5.6.2
>>> Platform: Darwin 64
>>> Installer: J806 install
>>> InstallPath: /users/bobtherriault/j64-806
>>> Contact: www.jsoftware.com
>>>   (; datatype) 999.3
>>> ┌┬┐
>>> │1e15│floating│
>>> └┴┘
>>>   (; datatype) .3
>>> ┌─┬───┐
>>> │1│integer│
>>> └─┴───┘
>>>   (; datatype) 9.3
>>> ┌──┬───┐
>>> │10│integer│
>>> └──┴───┘
>>>   (; datatype) 99.3
>>> ┌───┬───┐
>>> │100│integer│
>>> └───┴───┘
>>>   (; datatype) 999.3
>>> ┌┬┐
>>> │1e19│floating│
>>> └┴┘
>>> 
>>> Cheers, bob
>>> 
 On Aug 9, 2017, at 7:54 AM, 'Pascal Jasmin' via Programming <
>> programm...@jsoftware.com> wrote:
 
 in j806,.31 probably the j805
>> behaviour is preferred.  If only for consistency.  But there may be a good
>> reason for change.
 
 From: robert therriault 
 To: Programming forum 
 Sent: Wednesday, August 9, 2017 10:40 AM
 Subject: [Jprogramming] Integer-floating type change for large numbers
>> in j805 and j806
 
 I am guessing that the following has something to do with precision of
>> large numbers in j805 and is also true for j806.
 
  (; datatype) 999.3
 ┌┬┐
 │1e15│floating│
 └┴┘
  (; datatype) .3
 ┌─┬───┐
 │1│integer│
 └─┴───┘
  (; datatype) 9.3
 ┌──┬───┐
 │10│integer│
 └──┴───┘
  (; datatype) 99.3
 ┌───┬───┐
 │100│integer│
 └───┴───┘
  (; datatype) 999.3
 ┌┬┐
 │1e19│floating│
 └┴┘
  JVERSION
 Engine: j805/j64/darwin
 Release: commercial/2016-12-11T08:17:56
 Library: 8.05.14
 Qt IDE: 1.5.4/5.6.2
 Platform: Darwin 64
 Installer: J805 install

Re: [Jprogramming] Integer-floating type change for large numbers in j805 and j806

[Raul Miller]

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
>> Qt IDE: 1.5.3/5.6.2
>> Platform: Darwin 64
>> Installer: J806 install
>> InstallPath: /users/bobtherriault/j64-806
>> Contact: www.jsoftware.com
>>(; datatype) 999.3
>> ┌┬┐
>> │1e15│floating│
>> └┴┘
>>(; datatype) .3
>> ┌─┬───┐
>> │1│integer│
>> └─┴───┘
>>(; datatype) 9.3
>> ┌──┬───┐
>> │10│integer│
>> └──┴───┘
>>(; datatype) 99.3
>> ┌───┬───┐
>> │100│integer│
>> └───┴───┘
>>(; datatype) 999.3
>> ┌┬┐
>> │1e19│floating│
>> └┴┘
>>
>> Cheers, bob
>>
>> > On Aug 9, 2017, at 7:54 AM, 'Pascal Jasmin' via Programming <
> programm...@jsoftware.com> wrote:
>> >
>> > in j806,.31 probably the j805
> behaviour is preferred.  If only for consistency.  But there may be a good
> reason for change.
>> >
>> >  From: robert therriault 
>> > To: Programming forum 
>> > Sent: Wednesday, August 9, 2017 10:40 AM
>> > Subject: [Jprogramming] Integer-floating type change for large numbers
> in j805 and j806
>> >
>> > I am guessing that the following has something to do with precision of
> large numbers in j805 and is also true for j806.
>> >
>> >   (; datatype) 999.3
>> > ┌┬┐
>> > │1e15│floating│
>> > └┴┘
>> >   (; datatype) .3
>> > ┌─┬───┐
>> > │1│integer│
>> > └─┴───┘
>> >   (; datatype) 9.3
>> > ┌──┬───┐
>> > │10│integer│
>> > └──┴───┘
>> >   (; datatype) 99.3
>> > ┌───┬───┐
>> > │100│integer│
>> > └───┴───┘
>> >   (; datatype) 999.3
>> > ┌┬┐
>> > │1e19│floating│
>> > └┴┘
>> >   JVERSION
>> > Engine: j805/j64/darwin
>> > Release: commercial/2016-12-11T08:17:56
>> > Library: 8.05.14
>> > Qt IDE: 1.5.4/5.6.2
>> > Platform: Darwin 64
>> > Installer: J805 install
>> > InstallPath: /applications/j64-805
>> > Contact: www.jsoftware.com
>> >
>> > Further investigation shows me it was not this way with the 32 bit
> version of j701, so it may be an artifact of moving to 64 bit?
>> >
>> >   (; datatype) 999.3
>> > ┌┬┐
>> > │1e15│floating│
>> > └┴┘
>> >   (; datatype) .3
>> > ┌┬┐
>> > │1e16│floating│
>> > └┴┘
>> >   (; datatype) 99.3
>> > ┌┬┐
>> > │1e18│floating│
>> > └┴┘
>> >   (; datatype) 999.3
>> > ┌┬┐
>> > │1e19│floating│
>> > └┴┘
>> >   JVERSION
>> > Engine: j701/2011-01-10/11:25
>> > Library: 7.01.088
>> > Platform: 

Re: [Jprogramming] Integer-floating type change for large numbers in j805 and j806

[robert therriault]

Thank you Henry,

I reported it here.

http://code.jsoftware.com/wiki/System/Interpreter/Bugs/Errors#Error_in_float_representation_between_1e15_and_1e19

Let me know if you had somewhere else in mind.

Cheers, bob

> On Aug 9, 2017, at 9:05 AM, 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
>> Qt IDE: 1.5.3/5.6.2
>> Platform: Darwin 64
>> Installer: J806 install
>> InstallPath: /users/bobtherriault/j64-806
>> Contact: www.jsoftware.com
>>   (; datatype) 999.3
>> ┌┬┐
>> │1e15│floating│
>> └┴┘
>>   (; datatype) .3
>> ┌─┬───┐
>> │1│integer│
>> └─┴───┘
>>   (; datatype) 9.3
>> ┌──┬───┐
>> │10│integer│
>> └──┴───┘
>>   (; datatype) 99.3
>> ┌───┬───┐
>> │100│integer│
>> └───┴───┘
>>   (; datatype) 999.3
>> ┌┬┐
>> │1e19│floating│
>> └┴┘
>> 
>> Cheers, bob
>> 
>>> On Aug 9, 2017, at 7:54 AM, 'Pascal Jasmin' via Programming <
> programm...@jsoftware.com> wrote:
>>> 
>>> in j806,.31 probably the j805
> behaviour is preferred.  If only for consistency.  But there may be a good
> reason for change.
>>> 
>>> From: robert therriault 
>>> To: Programming forum 
>>> Sent: Wednesday, August 9, 2017 10:40 AM
>>> Subject: [Jprogramming] Integer-floating type change for large numbers
> in j805 and j806
>>> 
>>> I am guessing that the following has something to do with precision of
> large numbers in j805 and is also true for j806.
>>> 
>>>  (; datatype) 999.3
>>> ┌┬┐
>>> │1e15│floating│
>>> └┴┘
>>>  (; datatype) .3
>>> ┌─┬───┐
>>> │1│integer│
>>> └─┴───┘
>>>  (; datatype) 9.3
>>> ┌──┬───┐
>>> │10│integer│
>>> └──┴───┘
>>>  (; datatype) 99.3
>>> ┌───┬───┐
>>> │100│integer│
>>> └───┴───┘
>>>  (; datatype) 999.3
>>> ┌┬┐
>>> │1e19│floating│
>>> └┴┘
>>>  JVERSION
>>> Engine: j805/j64/darwin
>>> Release: commercial/2016-12-11T08:17:56
>>> Library: 8.05.14
>>> Qt IDE: 1.5.4/5.6.2
>>> Platform: Darwin 64
>>> Installer: J805 install
>>> InstallPath: /applications/j64-805
>>> Contact: www.jsoftware.com
>>> 
>>> Further investigation shows me it was not this way with the 32 bit
> version of j701, so it may be an artifact of moving to 64 bit?
>>> 
>>>  (; datatype) 999.3
>>> ┌┬┐
>>> │1e15│floating│
>>> └┴┘
>>>  (; datatype) .3
>>> ┌┬┐
>>> │1e16│floating│
>>> └┴┘
>>>  (; datatype) 99.3
>>> ┌┬┐
>>> │1e18│floating│
>>> └┴┘
>>>  (; datatype) 999.3
>>> ┌┬┐
>>> │1e19│floating│
>>> └┴┘
>>>  JVERSION
>>> Engine: j701/2011-01-10/11:25
>>> Library: 7.01.088
>>> Platform: Darwin 32
>>> Installer: j701a_mac_intel.dmg
>>> InstallPath: /Applications/j701
>>> 
>>> Cheers, bob
>>> 
>>> 
>>> 
>>> --
>>> For information about J forums see http://www.jsoftware.com/forums.htm
>>> 
>>> 
>>> --
>>> For information about J forums see http://www.jsoftware.com/forums.htm
>> 
>> 

Re: [Jprogramming] Integer-floating type change for large numbers in j805 and j806

[Henry Rich]

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
> Qt IDE: 1.5.3/5.6.2
> Platform: Darwin 64
> Installer: J806 install
> InstallPath: /users/bobtherriault/j64-806
> Contact: www.jsoftware.com
>(; datatype) 999.3
> ┌┬┐
> │1e15│floating│
> └┴┘
>(; datatype) .3
> ┌─┬───┐
> │1│integer│
> └─┴───┘
>(; datatype) 9.3
> ┌──┬───┐
> │10│integer│
> └──┴───┘
>(; datatype) 99.3
> ┌───┬───┐
> │100│integer│
> └───┴───┘
>(; datatype) 999.3
> ┌┬┐
> │1e19│floating│
> └┴┘
>
> Cheers, bob
>
> > On Aug 9, 2017, at 7:54 AM, 'Pascal Jasmin' via Programming <
programm...@jsoftware.com> wrote:
> >
> > in j806,.31 probably the j805
behaviour is preferred.  If only for consistency.  But there may be a good
reason for change.
> >
> >  From: robert therriault 
> > To: Programming forum 
> > Sent: Wednesday, August 9, 2017 10:40 AM
> > Subject: [Jprogramming] Integer-floating type change for large numbers
in j805 and j806
> >
> > I am guessing that the following has something to do with precision of
large numbers in j805 and is also true for j806.
> >
> >   (; datatype) 999.3
> > ┌┬┐
> > │1e15│floating│
> > └┴┘
> >   (; datatype) .3
> > ┌─┬───┐
> > │1│integer│
> > └─┴───┘
> >   (; datatype) 9.3
> > ┌──┬───┐
> > │10│integer│
> > └──┴───┘
> >   (; datatype) 99.3
> > ┌───┬───┐
> > │100│integer│
> > └───┴───┘
> >   (; datatype) 999.3
> > ┌┬┐
> > │1e19│floating│
> > └┴┘
> >   JVERSION
> > Engine: j805/j64/darwin
> > Release: commercial/2016-12-11T08:17:56
> > Library: 8.05.14
> > Qt IDE: 1.5.4/5.6.2
> > Platform: Darwin 64
> > Installer: J805 install
> > InstallPath: /applications/j64-805
> > Contact: www.jsoftware.com
> >
> > Further investigation shows me it was not this way with the 32 bit
version of j701, so it may be an artifact of moving to 64 bit?
> >
> >   (; datatype) 999.3
> > ┌┬┐
> > │1e15│floating│
> > └┴┘
> >   (; datatype) .3
> > ┌┬┐
> > │1e16│floating│
> > └┴┘
> >   (; datatype) 99.3
> > ┌┬┐
> > │1e18│floating│
> > └┴┘
> >   (; datatype) 999.3
> > ┌┬┐
> > │1e19│floating│
> > └┴┘
> >   JVERSION
> > Engine: j701/2011-01-10/11:25
> > Library: 7.01.088
> > Platform: Darwin 32
> > Installer: j701a_mac_intel.dmg
> > InstallPath: /Applications/j701
> >
> > Cheers, bob
> >
> >
> >
> > --
> > 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

--
regards,

GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
--
For information 

Re: [Jprogramming] Integer-floating type change for large numbers in j805 and j806

[bill lam]

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
> Qt IDE: 1.5.3/5.6.2
> Platform: Darwin 64
> Installer: J806 install
> InstallPath: /users/bobtherriault/j64-806
> Contact: www.jsoftware.com
>(; datatype) 999.3
> ┌┬┐
> │1e15│floating│
> └┴┘
>(; datatype) .3
> ┌─┬───┐
> │1│integer│
> └─┴───┘
>(; datatype) 9.3
> ┌──┬───┐
> │10│integer│
> └──┴───┘
>(; datatype) 99.3
> ┌───┬───┐
> │100│integer│
> └───┴───┘
>(; datatype) 999.3
> ┌┬┐
> │1e19│floating│
> └┴┘
>
> Cheers, bob
> 
> > On Aug 9, 2017, at 7:54 AM, 'Pascal Jasmin' via Programming 
> >  wrote:
> > 
> > in j806,.31 probably the j805 behaviour 
> > is preferred.  If only for consistency.  But there may be a good reason for 
> > change. 
> > 
> >  From: robert therriault 
> > To: Programming forum  
> > Sent: Wednesday, August 9, 2017 10:40 AM
> > Subject: [Jprogramming] Integer-floating type change for large numbers in 
> > j805 and j806
> > 
> > I am guessing that the following has something to do with precision of 
> > large numbers in j805 and is also true for j806.
> > 
> >   (; datatype) 999.3
> > ┌┬┐
> > │1e15│floating│
> > └┴┘
> >   (; datatype) .3
> > ┌─┬───┐
> > │1│integer│
> > └─┴───┘
> >   (; datatype) 9.3
> > ┌──┬───┐
> > │10│integer│
> > └──┴───┘
> >   (; datatype) 99.3
> > ┌───┬───┐
> > │100│integer│
> > └───┴───┘
> >   (; datatype) 999.3
> > ┌┬┐
> > │1e19│floating│
> > └┴┘
> >   JVERSION
> > Engine: j805/j64/darwin
> > Release: commercial/2016-12-11T08:17:56
> > Library: 8.05.14
> > Qt IDE: 1.5.4/5.6.2
> > Platform: Darwin 64
> > Installer: J805 install
> > InstallPath: /applications/j64-805
> > Contact: www.jsoftware.com
> > 
> > Further investigation shows me it was not this way with the 32 bit version 
> > of j701, so it may be an artifact of moving to 64 bit?
> > 
> >   (; datatype) 999.3
> > ┌┬┐
> > │1e15│floating│
> > └┴┘
> >   (; datatype) .3
> > ┌┬┐
> > │1e16│floating│
> > └┴┘
> >   (; datatype) 99.3
> > ┌┬┐
> > │1e18│floating│
> > └┴┘
> >   (; datatype) 999.3
> > ┌┬┐
> > │1e19│floating│
> > └┴┘
> >   JVERSION
> > Engine: j701/2011-01-10/11:25
> > Library: 7.01.088
> > Platform: Darwin 32
> > Installer: j701a_mac_intel.dmg
> > InstallPath: /Applications/j701
> > 
> > Cheers, bob
> > 
> > 
> > 
> > --
> > 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

-- 
regards,

GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
--
For information about J forums see http://www.jsoftware.com/forums.htm

Re: [Jprogramming] Integer-floating type change for large numbers in j805 and j806

[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
Qt IDE: 1.5.3/5.6.2
Platform: Darwin 64
Installer: J806 install
InstallPath: /users/bobtherriault/j64-806
Contact: www.jsoftware.com
   (; datatype) 999.3
┌┬┐
│1e15│floating│
└┴┘
   (; datatype) .3
┌─┬───┐
│1│integer│
└─┴───┘
   (; datatype) 9.3
┌──┬───┐
│10│integer│
└──┴───┘
   (; datatype) 99.3
┌───┬───┐
│100│integer│
└───┴───┘
   (; datatype) 999.3
┌┬┐
│1e19│floating│
└┴┘
   
Cheers, bob

> On Aug 9, 2017, at 7:54 AM, 'Pascal Jasmin' via Programming 
>  wrote:
> 
> in j806,.31 probably the j805 behaviour 
> is preferred.  If only for consistency.  But there may be a good reason for 
> change. 
> 
>  From: robert therriault 
> To: Programming forum  
> Sent: Wednesday, August 9, 2017 10:40 AM
> Subject: [Jprogramming] Integer-floating type change for large numbers in 
> j805 and j806
> 
> I am guessing that the following has something to do with precision of large 
> numbers in j805 and is also true for j806.
> 
>   (; datatype) 999.3
> ┌┬┐
> │1e15│floating│
> └┴┘
>   (; datatype) .3
> ┌─┬───┐
> │1│integer│
> └─┴───┘
>   (; datatype) 9.3
> ┌──┬───┐
> │10│integer│
> └──┴───┘
>   (; datatype) 99.3
> ┌───┬───┐
> │100│integer│
> └───┴───┘
>   (; datatype) 999.3
> ┌┬┐
> │1e19│floating│
> └┴┘
>   JVERSION
> Engine: j805/j64/darwin
> Release: commercial/2016-12-11T08:17:56
> Library: 8.05.14
> Qt IDE: 1.5.4/5.6.2
> Platform: Darwin 64
> Installer: J805 install
> InstallPath: /applications/j64-805
> Contact: www.jsoftware.com
> 
> Further investigation shows me it was not this way with the 32 bit version of 
> j701, so it may be an artifact of moving to 64 bit?
> 
>   (; datatype) 999.3
> ┌┬┐
> │1e15│floating│
> └┴┘
>   (; datatype) .3
> ┌┬┐
> │1e16│floating│
> └┴┘
>   (; datatype) 99.3
> ┌┬┐
> │1e18│floating│
> └┴┘
>   (; datatype) 999.3
> ┌┬┐
> │1e19│floating│
> └┴┘
>   JVERSION
> Engine: j701/2011-01-10/11:25
> Library: 7.01.088
> Platform: Darwin 32
> Installer: j701a_mac_intel.dmg
> InstallPath: /Applications/j701
> 
> Cheers, bob
> 
> 
> 
> --
> 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

Re: [Jprogramming] Integer-floating type change for large numbers in j805 and j806

['Pascal Jasmin' via Programming]

in j806,    .31 probably the j805 behaviour is 
preferred.  If only for consistency.  But there may be a good reason for 
change. 

  From: robert therriault 
 To: Programming forum  
 Sent: Wednesday, August 9, 2017 10:40 AM
 Subject: [Jprogramming] Integer-floating type change for large numbers in j805 
and j806
   
I am guessing that the following has something to do with precision of large 
numbers in j805 and is also true for j806.

  (; datatype) 999.3
┌┬┐
│1e15│floating│
└┴┘
  (; datatype) .3
┌─┬───┐
│1│integer│
└─┴───┘
  (; datatype) 9.3
┌──┬───┐
│10│integer│
└──┴───┘
  (; datatype) 99.3
┌───┬───┐
│100│integer│
└───┴───┘
  (; datatype) 999.3
┌┬┐
│1e19│floating│
└┴┘
  JVERSION
Engine: j805/j64/darwin
Release: commercial/2016-12-11T08:17:56
Library: 8.05.14
Qt IDE: 1.5.4/5.6.2
Platform: Darwin 64
Installer: J805 install
InstallPath: /applications/j64-805
Contact: www.jsoftware.com

Further investigation shows me it was not this way with the 32 bit version of 
j701, so it may be an artifact of moving to 64 bit?

      (; datatype) 999.3
┌┬┐
│1e15│floating│
└┴┘
  (; datatype) .3
┌┬┐
│1e16│floating│
└┴┘
  (; datatype) 99.3
┌┬┐
│1e18│floating│
└┴┘
  (; datatype) 999.3
┌┬┐
│1e19│floating│
└┴┘
  JVERSION
Engine: j701/2011-01-10/11:25
Library: 7.01.088
Platform: Darwin 32
Installer: j701a_mac_intel.dmg
InstallPath: /Applications/j701

Cheers, bob



--
For information about J forums see http://www.jsoftware.com/forums.htm

   
--
For information about J forums see http://www.jsoftware.com/forums.htm

[Jprogramming] Integer-floating type change for large numbers in j805 and j806

[robert therriault]

I am guessing that the following has something to do with precision of large 
numbers in j805 and is also true for j806.

   (; datatype) 999.3
┌┬┐
│1e15│floating│
└┴┘
   (; datatype) .3
┌─┬───┐
│1│integer│
└─┴───┘
   (; datatype) 9.3
┌──┬───┐
│10│integer│
└──┴───┘
   (; datatype) 99.3
┌───┬───┐
│100│integer│
└───┴───┘
   (; datatype) 999.3
┌┬┐
│1e19│floating│
└┴┘
   JVERSION
Engine: j805/j64/darwin
Release: commercial/2016-12-11T08:17:56
Library: 8.05.14
Qt IDE: 1.5.4/5.6.2
Platform: Darwin 64
Installer: J805 install
InstallPath: /applications/j64-805
Contact: www.jsoftware.com

Further investigation shows me it was not this way with the 32 bit version of 
j701, so it may be an artifact of moving to 64 bit?

  (; datatype) 999.3
┌┬┐
│1e15│floating│
└┴┘
   (; datatype) .3
┌┬┐
│1e16│floating│
└┴┘
   (; datatype) 99.3
┌┬┐
│1e18│floating│
└┴┘
   (; datatype) 999.3
┌┬┐
│1e19│floating│
└┴┘
   JVERSION
Engine: j701/2011-01-10/11:25
Library: 7.01.088
Platform: Darwin 32
Installer: j701a_mac_intel.dmg
InstallPath: /Applications/j701

Cheers, bob



--
For information about J forums see http://www.jsoftware.com/forums.htm