unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Pip Cet <pipcet@gmail.com>
Cc: rpluim@gmail.com, eggert@cs.ucla.edu, emacs-devel@gnu.org
Subject: Re: Floating-point constant folding in Emacs byte compiler
Date: Mon, 02 Apr 2018 15:50:58 +0300	[thread overview]
Message-ID: <83zi2l6abx.fsf@gnu.org> (raw)
In-Reply-To: <CAOqdjBc7AP49o1A7v9zWpQ7L-pa7kTJZO5NZJO6UonU+4PqyzA@mail.gmail.com> (message from Pip Cet on Mon, 2 Apr 2018 11:42:59 +0000)

> From: Pip Cet <pipcet@gmail.com>
> Date: Mon, 2 Apr 2018 11:42:59 +0000
> Cc: eggert@cs.ucla.edu, rpluim@gmail.com, emacs-devel@gnu.org
> 
> I'm trying to make bytecode reproducible for my code, which uses
> SpiderMonkey's JS::Value type, and in which two same-value floats are
> always equal (because their bit representations are), and standard
> Emacs on a standard GNU/Linux machine, where, as I've just learned,
> two same-value floats are never eq (I'd previously thought that was
> undefined, and actually unpredictable in practice).

Well, maybe what I said could be misinterpreted: they _can_ be EQ iff
they reference the same Lisp_Float object.  If they reference
different objects, they aren't EQ.  When these floats come from Lisp,
it's extremely unlikely for them to reference the same object, though.

> Again, this is the first time I hear that "two floats are never EQ" is
> actually intentional behavior that some code might rely on, rather
> than a mere accident of the current float implementation. Do you
> happen to have any examples at hand for code that relies on this?

Not off the top of my head, no.  But IME such implementation details
tend to leak into the code, and I would be surprised if we didn't have
something like that in Emacs.

> In the case of byte code, what I've seen so far is that the code
> generated is actually suboptimal, and runs fine without duplicated
> float constants in the constants vector.

Comparing FP values for equivalence on the C level is tricky at best,
due to extended precision, guard bits, etc.  What is your plan for
overcoming these obstacles in a predictable and reliable manner?  Did
you consider solving the problem the other way around, i.e. teaching
JS::Value about this issue?  (Caveat: I know nothing about JS.)




  reply	other threads:[~2018-04-02 12:50 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-22 23:04 Floating-point constant folding in Emacs byte compiler Paul Eggert
2018-03-23  1:26 ` Stefan Monnier
2018-03-23  5:22   ` Paul Eggert
2018-03-23  8:24     ` Eli Zaretskii
2018-03-23 20:00       ` Paul Eggert
2018-03-23  8:15   ` Eli Zaretskii
2018-03-23 20:52 ` Pip Cet
2018-03-24  6:25   ` Eli Zaretskii
2018-03-26  9:39     ` Robert Pluim
2018-03-26 15:13       ` Eli Zaretskii
2018-03-26 15:57         ` Robert Pluim
2018-03-26 16:02           ` Eli Zaretskii
2018-03-26 18:23             ` Pip Cet
2018-03-26 18:29               ` Eli Zaretskii
2018-03-27  0:28               ` Paul Eggert
2018-03-27 23:28                 ` Paul Eggert
2018-03-30 16:26                   ` Pip Cet
2018-03-30 16:31                     ` Noam Postavsky
2018-03-30 16:39                     ` Paul Eggert
2018-04-02 10:56                       ` Pip Cet
2018-04-02 11:22                         ` Eli Zaretskii
2018-04-02 11:42                           ` Pip Cet
2018-04-02 12:50                             ` Eli Zaretskii [this message]
2018-04-02 14:50                         ` Stefan Monnier
2018-04-02 15:02                           ` Pip Cet
2018-04-02 12:57                     ` Noam Postavsky
2018-04-02 13:30                       ` Eli Zaretskii
2018-04-02 14:48                         ` Stefan Monnier
2018-04-02 19:20                           ` Paul Eggert
2018-04-02 19:39                             ` Pip Cet
2018-04-02 19:58                               ` Eli Zaretskii
2018-04-02 20:55                                 ` Pip Cet
     [not found]                       ` <<83y3i568i0.fsf@gnu.org>
2018-04-02 13:37                         ` Drew Adams
2018-04-02 14:05                           ` Eli Zaretskii
2018-04-02 14:54                           ` Pip Cet
2018-04-02 15:02                             ` Drew Adams
2018-03-26 17:52         ` Stefan Monnier
2018-03-26 18:30           ` Eli Zaretskii
2018-03-27  0:08           ` Paul Eggert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83zi2l6abx.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=eggert@cs.ucla.edu \
    --cc=emacs-devel@gnu.org \
    --cc=pipcet@gmail.com \
    --cc=rpluim@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).