Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:128562 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id 67A611A00BC for ; Tue, 26 Aug 2025 17:14:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1756228405; bh=35qXBdLVP6u9X6ooTUKzJxG82BHtpm7U+P8saekLoUc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=m0DfVySL0zSRsMyGL/glrTDsNjcMsLY/TVBBoGBdKyp48v48QetDtlNOf06rxAXol WpqcxlyJ+b+OzmhrN+u0XH/Zwg5+UM0PWdksx8KKN7PZvVJE1VrrF8vPcJ3oHC1Jmn FINE7UI+5LYqbgEf4gqftVsb1k+xucsygvxeT8d32mDV+luDUdqCNOeXsywNo/qj5z DbLYCVqm2pGM1/5j6Yjhup6uRIwDfMiN5yo4BTe+M4InS0eLihNlDHUqTFEdaEbC7B jHkCrfFOPjErF8IDGtSq0GCOuqq4K51/LETWkU+FiIyRmiD8O4pLCx43BRv5+DHb31 BgDxLqivGXevg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B9A621801D4 for ; Tue, 26 Aug 2025 17:13:24 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_20,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 26 Aug 2025 17:13:24 +0000 (UTC) Received: by mail-ed1-f53.google.com with SMTP id 4fb4d7f45d1cf-61c21e50168so5554439a12.3 for ; Tue, 26 Aug 2025 10:14:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756228496; x=1756833296; darn=lists.php.net; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=35qXBdLVP6u9X6ooTUKzJxG82BHtpm7U+P8saekLoUc=; b=jhwlaNQC5iQu8NaR3V2O6eRNKNDB0Quv6WfLlDbD+KtD4V5SMoHCwk4pXSg/bJLOqQ CQ7lxi86qrbq99WY5GyMsPXxFBOH/QfjZTgz2RxIIJvM20ug7QjLs14BHKV0oKJy6KHi +ewt0yJatttLKkOPdtywK0+utjv7xqIEQGWQcKnqCTJQfrRuRsiUyG/2mvqcF+eKMzRC sBpkuFAQYMVXd7A9m74/7CiZ2kuSxcPX03UAbZl7xL6HdWf8KZ5UBZjAjEcldqmkQ04h +MyoSYlZoBzrKd6rkaISOJSRu7NCzNMeeIuIFQzbPkRV1QE99ZBbXAKXsRYfdxxjqVcc mxuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756228496; x=1756833296; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=35qXBdLVP6u9X6ooTUKzJxG82BHtpm7U+P8saekLoUc=; b=lLKheAUjJxu90XrIcZyG/B0TMnd4mgcxWXW9AZ7u9anUZCq4KrR9QNrfyce2/sKNj/ U9Km3+y51cQjBFYdv/cFyY5YSPIHCtFVwSuF3FBSw1wWoSJ9hHUTIxfNpA1XkUMfvFfo NNp+5XmkiesgyEPexwhKE7FJ7gR3jR+zNitErIKADb4b71iBHmFFQk6HVZpuR9ceCqFL sAcwxNx899izqLU4cTYh4zkNJzn/ZDJYj93aGg8SVg6451cMLpzFI+by4Qh5tMLxrNoD 5nOnP39vECKjNrBlCxE8b1g4D4a8WDVYRibi9CgFZAJeFcNpTAivnEfq6YcAhEm42jtq wDHg== X-Gm-Message-State: AOJu0YwkZS/JH50XLOF/MLxxMD+gLaTcgB1UQTAwVi/JURHusQKRLoMN M+cZTJZbKoKIvoNiCRUY4PK+98NTUuYJeVgBNzzm0x9XzzJhsy1PF68A7T746rbVw+jLVGNjkan XPpHH9QrKSWvNTHd16DDU5ixav+pt8uSvrQbA X-Gm-Gg: ASbGncsXvl5+KG8w5z6L47UmTirQrE27xQUlqmcyfpKYOiQ3kOSNymJbH88l/Z5aCXU i1bPFGra+Q9tSsPPpnpGMEDngdIEphtBd9KNfJJfFjaKd/tQ2mWd9+msnIVH9eldt8gylQrFBs2 QuOc4CYmB+iUt/ZY0reB2iLio+9qxmmhf/Zt7mJ8Wo/QkE0h4lAhZDpW3BscSiWBZPZ1c+mtpyt SQjT74MRw+LNeHsDBGU4O+d8md4uQzzqW6w2Reosfv5uU+MS4MmJDMFRXrVljG+qxi00pR6kg== X-Google-Smtp-Source: AGHT+IHbMgo8gA3lmUz40l7z17+hJnjArPJxxS5/xTpzviW3/GyXaRDUNWqvWMxHWfxNiOfG6o72PtMnq6XrPVu7N1o= X-Received: by 2002:a05:6402:21c6:b0:61a:8966:ced6 with SMTP id 4fb4d7f45d1cf-61c1b717eb8mr15250734a12.35.1756228495434; Tue, 26 Aug 2025 10:14:55 -0700 (PDT) Precedence: list list-help: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 26 Aug 2025 19:14:43 +0200 X-Gm-Features: Ac12FXyKw0N4ylQxClbJ-Y4KufE7wiqyKXvez0v4AxdBMKE11oc5UThavQ_AYW4 Message-ID: Subject: Re: [PHP-DEV] [RFC] Add "is_representable_as_float()" and "is_representable_as_int()" functions To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= Cc: PHP internals list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable From: alex.daubois+php@gmail.com (Alexandre Daubois) Hi Tim, Thank you for your thorough review. > 3.14 is not exactly representable as a IEEE-754 double-precision > floating point number. The two nearest representable values are > 3.14000000000000012434 (this one is the nearest) and > 3.13999999999999968026. Returning `true` for > `is_representable_as_float("3.14")` is therefore wrong to me. You're right about mathematical precision. Perhaps the function name is misleading. What the function actually should check is whether a string > float > string roundtrip preserves the value as PHP developers would expect it, not whether it's mathematically exactly representable in IEEE-754. Maybe a more accurate name would better reflect this behavior. Naming is super hard again here. The goal is pragmatic: "will this value survive a type conversion cycle without surprising changes?" > The introduction is also wrong. JSON does *not* specify that numbers > must be representable as IEEE-754 double-precision floating point > numbers. The grammar for =E2=80=9CNumbers=E2=80=9D is independent of any = particular > representation and transmitting numbers > 2^53 is perfectly fine if > every system involved can deal with 64 bit integers. Also just casting a > non-representable value to string will break any consumers that are > strongly typed and expect a number rather than a string. So that doesn't > make sense to me either. Fair point about the JSON specification itself. However, the real-world issue is JavaScript's Number type limitation (safe integers only up to 2^53). The fact that it is fine if "every system involved can deal with 64 bits integers" is true, but nothing guarantees that all systems involved are systematically x64. Many PHP applications need to communicate with JavaScript frontends, and knowing when a numeric ID exceeds JavaScript's safe integer range would improve interoperability. > I also question how meaningful it is knowing that a given number is > exactly representable as a float when (e.g. a power of two) when almost > any operation on it will incur implicit rounding. To me, the code snippet in the RFC introduction illustrates a valid use-case of a numeric identifier that could be dangerous to cast. > Long story short: What actual real-world problem does this RFC attempt > to solve? The list in the =E2=80=9CIntroduction=E2=80=9D section is not p= articularly > meaningful with regard to the real world and the JSON example is wrong > as outlined above. A few examples, as interoperability between with JSON/JavaScript is the main point here, could be: - Snowflake IDs - High-precision timestamps in microseconds - Large auto-increment IDs in mature applications Hope I addressed your concerns. Best, Alexandre Daubois