Note, this issue is not specific to based representations. 9223372036854776064 (i.e. INT_MAX+256) also parses to INT_MAX with integer precision. I just used hex in my examples since it makes bit boundaries a lot more obvious.
Raul Miller <[email protected]> wrote: > There are currently three "constants" pages in the wiki: > > https://code.jsoftware.com/wiki/Vocabulary/Nouns > https://code.jsoftware.com/wiki/Vocabulary/Constants > https://code.jsoftware.com/wiki/Guides/Constants > > I have updated the Guides/Constants page, as it already had a segment > on 'based' constants. > > I am not sure about the Vocabulary/Constants page -- it looks like it > needs a lot of work. Perhaps a redirect might be a better option? > > The Vocabulary/Nouns page covers a larger suite of topics and is > probably not the right place for this kind of detail. > > Thanks, > > -- > Raul > > > On Sat, Oct 23, 2021 at 8:59 AM Ian Clark <[email protected]> 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 NuVoc 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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
