Dear all -
About four years ago, I started this project
'Vocabulary/Constants' for I have felt a need to
collect all those forum sprinkles (and gems) at a
central place where they could be easily found,
in a more more concise manner. My intention has
been to provide a solid starting base for
seasened newbies like me from where to explore further.
Due to severe health problems I wasn't able to
contribute in regular intervals any more as my
capacity to concentrate on stuff dwindeled.
(During all that time I have [however silently] followed forum activities.)
Since a couple of month I am slowly getting
better. But still not to a stage to presently
tackle complete sections like 'Foreign Bases (b)'
and others which are still missing. As Raul aptly
pointed out, the page looks like it needs a lot of work.
As for the section 'Further Reading', yes, the
stub there has been a placeholder for pointers to
more in-depth treatments of the subject, and I
guess it is high time to get it replaced with the
links suggested. (To have links concentrated here
might even help to incorporate part of their
content more easily in the future.)
Thank you all for your help over the last years.
-M
At 2021-10-23 12:58, you wrote:
I was just about to say that, Henry.
Ancillary pages are intended to be linked from multiple NuVoc pages. I
thought there might be a need for a new one to address the matter of this
thread. But [[Vocabulary/Constants]]
https://code.jsoftware.com/wiki/Vocabulary/Constants
seems to be its natural home for now.
Note that the last section:
https://code.jsoftware.com/wiki/Vocabulary/Constants#Further_reading
promises to answer Raul's question, but links to a missing page
or is it a
placeholder?
Some NuVocc pages link into Pipermail, as a temporary measure, until someone
has the time to draw threads together.
For forum members who haven't used Pipermail, the link to the present
thread is:
https://www.jsoftware.com/pipermail/general/2021-October/038701.html
On Sat, 23 Oct 2021 at 13:44, Henry Rich <[email protected]> wrote:
> Constants
> Henry Rich
> On Sat, Oct 23, 2021, 2:03 PM Raul Miller <[email protected]> wrote:
> > I guess the question is: which wiki page should this be documented in?
> >
> > (If it's not already -- I guess another question is what should I
> > search on to attempt to find such documentation?)
> >
> > Thanks,
> >
> > --
> > Raul
> >
> > On Sat, Oct 23, 2021 at 5:44 AM Henry Rich <[email protected]> wrote:
> > >
> > > You might have a point, but I don't think it's worth taking the risk of
> > > breaking existing code to make the change. If you want a float, add a
> > > decimal point.
> > >
> > > Numbers close to IMAX are always troublesome because of tolerance.
> > >
> > > Henry Rich
> > >
> > > On 10/23/2021 4:13 AM, ethiejiesa via General wrote:
> > > > The issue I find surprising is that integer literals in the range
> > > > 16b8000000000000000 to 16b80000000000004ff, i.e. INT_MAX+1 to
> > INT_MAX+1024, all
> > > > parse into the integer precision 9223372036854775807, i.e. INT_MAX.
> > This is not
> > > > the same thing as (<:2^63) which has floating precision.
> > > >
> > > > My expectation was that non-exact representations for (2^63x) and
> > above---
> > > > e.g. 16b8000000000000000---would parse into floating precision
> numbers.
> > > >
> > > > As it stands, this means that integer precision values equal to
> > > > 16b7fffffffffffffff cannot be trusted and must be handled specially,
> as
> > > > demonstrated nicely in Raul's examples below.
> > > >
> > > > Henry Rich <[email protected]> wrote:
> > > >> 16b8000000000000401 cannot be exactly represented. There is a band
> > of floats near 2^63 that are converted to (<:2^63).
> > > >>
> > > >> Henry Rich
> > > >>
> > > >>
> > > >>
> > > >> On 10/23/2021 1:42 AM, Raul Miller wrote:
> > > >>> I do not see why I should expect these to be the same number:
> > > >>>
> > > >>> 2^.92233720368547768323
> > > >>> 66.3219
> > > >>> 2^.16b8000000000000401
> > > >>> 63
> > > >>>
> > > >>> One is larger than can be represented using a 64 bit integer, and
> so
> > > >>>
> > > >>> datatype 92233720368547768323
> > > >>> floating
> > > >>>
> > > >>> That said, I do think that there's a problem with the other one.
> That
> > > >>> one is also larger than can be represented using a 64 bit signed
> > > >>> integer:
> > > >>>
> > > >>> (2^63x)-16b8000000000000401
> > > >>> 1
> > > >>> (2^63x)-16b8000000000000000
> > > >>> 1
> > > >>> (2^63x)-16b7fffffffffffffff
> > > >>> 1
> > > >>>
> > > >>> So there's a certain range of numbers here which get treated ...
> > oddly.
> > > >>>
> > > >>> Thanks,
> > > >>>
> > > >
> > > >
> ----------------------------------------------------------------------
> > > > For information about J forums see
> http://www.jsoftware.com/forums.htm
> > >
> > >
> > > --
> > > This email has been checked for viruses by AVG.
> > > https://www.avg.com
> > >
> > > ----------------------------------------------------------------------
> > > For information about J forums see http://www.jsoftware.com/forums.htm
> > ----------------------------------------------------------------------
> > For information about J forums see http://www.jsoftware.com/forums.htm
> >
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
