Meant to deep-link to the constants in question. I defined them here 
<https://github.com/elixir-lang/elixir/compare/master...christhekeele:float-is-close#diff-c4c664fa7c11c3a7041558138e6c3e7297d3aa74ef923749caeb4b57de254462R49-R56>,
 
derived from the Java constants that the author used (documented here 
<https://docs.oracle.com/javase/8/docs/api/java/lang/Float.html#MAX_VALUE>, 
here 
<https://docs.oracle.com/javase/8/docs/api/java/lang/Float.html#MIN_NORMAL>, 
and here 
<https://docs.oracle.com/javase/8/docs/api/java/lang/Float.html#MIN_VALUE>).



On Thursday, May 20, 2021 at 8:12:20 PM UTC-7 Christopher Keele wrote:

> > It doesn't behave very well with pattern matching. This could of course 
> be rectified by making it usable as a function clause ala:
> > def float_stuff(x, y) when nearly_equal?(x, y, 5), do ...
>
> I wanted to see if the algorithm described in the linked article 
> <https://floating-point-gui.de/errors/comparison/> was possible to 
> implement as a guard, and indeed it is 
> <https://github.com/elixir-lang/elixir/compare/master...christhekeele:float-is-close#diff-c4c664fa7c11c3a7041558138e6c3e7297d3aa74ef923749caeb4b57de254462R65-R75>!
>  
> (More readable non-guard version here 
> <https://github.com/elixir-lang/elixir/commit/2ba695ae954841c5c0c739a148fea3cea8fda2f9#diff-c4c664fa7c11c3a7041558138e6c3e7297d3aa74ef923749caeb4b57de254462R65-R80>
> .)
>
> Mind you I approached this as a fun guard exercise and it needs way more 
> scrutiny:
>
>    - We should review other langs and algos deeper.
>    - My choices of function and variables names were not thought through.
>    - I cribbed both the constants and the test suite straight from the 
>    Java implementation linked in the article.
>       - That means that if the constants are not correct for the BEAM, 
>       the tests would not necessarily reveal this;
>       - Someone more BEAM-float-literate than I would need to verify them.
>    
> ---
>
> The author also tantalizingly alludes to another more accurate approach, 
> that requires
>
> > the programming language to support conversion between floating-point 
> values and integer bit patterns
>
> Of course, we do, so I might check out the fairly long linked paper and 
> play with that approach! It might not be possible to implement as a guard 
> though, have to do more reading.
> On Thursday, May 20, 2021 at 6:09:20 AM UTC-7 Allen Madsen wrote:
>
>> Python has a pretty nice PEP for this 
>> https://www.python.org/dev/peps/pep-0485/
>>
>> Allen Madsen
>> http://www.allenmadsen.com
>>
>>
>> On Thu, May 20, 2021 at 3:31 AM José Valim <[email protected]> wrote:
>>
>>> Thanks Eamonn for sharing! The article and its references led to very 
>>> interesting reading.
>>>
>>> In principle I don't see an issue with adding such a function, but I 
>>> believe we need to survey other languages and see what they are calling it 
>>> and which edge cases they consider too.
>>>
>>> Using the code above may be ok at the end, it is under Creative Commons, 
>>> but we need to survey around before. :)
>>>
>>> On Thu, May 20, 2021 at 12:21 AM Eamonn O'Brien <[email protected]> 
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> My first post here, so hello all and thanks for all the great work on 
>>>> Elixir so far! 
>>>>
>>>> This is a relatively simple proposal. Many of the Float functions 
>>>> already take precisions and, floating point arithmetic being what it is a 
>>>> comparison function that takes some sort of epsilon value is almost 
>>>> required for a lot of floating point work.
>>>>
>>>> As https://floating-point-gui.de/errors/comparison/ outlines writing 
>>>> such a function is both tricky and error prone so adding an implementation 
>>>> of that function to the core library makes sense.
>>>>
>>>> I would propose a spec something like:
>>>>
>>>> @spec nearly_equal?(float, float, precision) :: bool
>>>>
>>>> Using an epsilon value instead of a precision might make more sense in 
>>>> some contexts but since the rest of the functions in Float use a precision 
>>>> value that is probably more consistent.
>>>>
>>>> Arguments for:
>>>>
>>>> The documentation for Float already links to the above article 
>>>> discussing why such a function might be needed. Adding an implementation 
>>>> probably makes sense.
>>>>
>>>> It is a sufficiently widely used function that a default implementation 
>>>> in the standard library is not going to be clutter.
>>>>
>>>> It is a tricky function to get right and providing a default 
>>>> implementation would be beneficial.
>>>>
>>>> Having it available might make devs more likely to use it instead of 
>>>> comparison or pattern matching floats.
>>>>
>>>> Arguments against:
>>>>
>>>> The function can already be written using the tools provided in the 
>>>> core language. Implementation of such a function is not necessary and 
>>>> arguably is something domain specific that should be written per project.
>>>>
>>>> It doesn't behave very well with pattern matching. This could of course 
>>>> be rectified by making it usable as a function clause ala:
>>>>
>>>> def float_stuff(x, y) when nearly_equal?(x, y, 5), do ...
>>>>
>>>> There may be a copyright issue with just writing a version of the code 
>>>> linked.
>>>>
>>>> Alternatives:
>>>>
>>>> Using the same spec but calling the function equal? and defaulting 
>>>> precision to 15 might make more sense.
>>>>
>>>> -- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "elixir-lang-core" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to [email protected].
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/elixir-lang-core/23f8e3a6-0aa6-426c-bb67-497a6bd7bf66n%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/elixir-lang-core/23f8e3a6-0aa6-426c-bb67-497a6bd7bf66n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "elixir-lang-core" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to [email protected].
>>>
>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2Bt6Qj6HnR9%2BvmGjAnLFwe4hjsYJgdwXWYb9njUirWggg%40mail.gmail.com
>>>  
>>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2Bt6Qj6HnR9%2BvmGjAnLFwe4hjsYJgdwXWYb9njUirWggg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elixir-lang-core/abf636ad-09d0-4a9a-b8c3-102547129fa5n%40googlegroups.com.

Reply via email to