www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 3632] New: modify float is float to do a bitwise compare

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3632

           Summary: modify float is float to do a bitwise compare
           Product: D
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: schveiguy yahoo.com



12:04:05 PST ---
I was trying to test that my array append code is working properly.  In order
to do this, I want to verify that when I set the length to a larger number that
the additional space is filled with T.init

This test works great for most all types except floating point:

assert(a[$-1] is T.init)

It was pointed out that Phobos has isIdentical, but that doesn't work with
literals for some reason:

float a;
assert(isIdentical(a, float.init)) // fails!

But it shouldn't be this hard.  Why does 'is' do a bitwise compare for
everything *except* floating point numbers?  I understand that the spec states
that is converts to == for builtin types, but it seems inconsistent because ==
for all builtin types except floating point *is* a bitwise compare.  It seems
there is no easy way to get a bitwise compare for floating points, and the
method provided doesn't work properly.  It should be braindead simple to get
the compiler to do a bitwise compare.

I propose that for floating point types, x is y be equivalent to a bitwise
compare.  It is easy to say in the spec "x is y does a bitwise compare, which
for all builtin types except for floating point types is equivalent to
equality"

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 18 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3632


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug yahoo.com.au





 It was pointed out that Phobos has isIdentical, but that doesn't work with
 literals for some reason:
 
 float a;
 assert(isIdentical(a, float.init)) // fails!


That's because of the recently discovered NaN bug; the code generated for
uninitialized floats and doubles needs to change. It's not a problem with
isIdentical.


 But it shouldn't be this hard.  Why does 'is' do a bitwise compare for
 everything *except* floating point numbers?



 I propose that for floating point types, x is y be equivalent to a bitwise
 compare.  It is easy to say in the spec "x is y does a bitwise compare, which
 for all builtin types except for floating point types is equivalent to
 equality"


I think this would be a good idea. I've thought that several times myself. I
created the isIdentical() function because I think there's a need for it.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 18 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3632


yebblies <yebblies gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch
                 CC|                            |yebblies gmail.com



Possible implementation.
https://github.com/D-Programming-Language/dmd/pull/126

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 14 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3632


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla digitalmars.com
         Resolution|                            |FIXED



23:20:33 PDT ---
https://github.com/D-Programming-Language/dmd/commit/0d93cf4333df6e167f9027eb1a4b0aa9a940ff19

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 25 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3632


bearophile_hugs eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs eml.cc



Do you know what's missing in the list of bug 3981 ?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 26 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3632


kennytm gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |kennytm gmail.com
         Resolution|FIXED                       |



This is *not yet fixed*. The current implementation in DMD


           real_t v1 = e1->toReal();
           real_t v2 = e2->toReal();
           cmp = !memcmp(&v1, &v2, sizeof(real_t));


will not work, at least on OS X, because while 'real_t' ('long double') is only
a 80-bit floating point number (occupying 10 bytes), with alignment
'sizeof(real_t)' will take 16 bytes. The extra 6 bytes of paddings are often
filled with garbage. This makes even

       4.0 is 4.0

to return 'false'.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 26 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3632


kennytm gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED



https://github.com/D-Programming-Language/dmd/commit/32740

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 27 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3632


yebblies <yebblies gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |



Reopening as the commit above will cause the following assert to fail:
static assert(real.init !is real.nan);

And the padding issue has only been fixed for the compile time evaluation, not
runtime.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 27 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3632




11:32:17 PDT ---


 Reopening as the commit above will cause the following assert to fail:
 static assert(real.init !is real.nan);


This is intended. All nans are regarded as the same (even signalling and
non-signalling).


 And the padding issue has only been fixed for the compile time evaluation, not
 runtime.


You're right.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 27 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3632







 This is intended. All nans are regarded as the same (even signalling and
 non-signalling).


So we have to use std.math.isIdentical() to tell apart floating point values on
the base of the their bit patterns.

Related: I think almost no one uses the NaN payloads because (beside being a
niche need) almost no language gives easy and explicit support to manage those
payloads (while in std.math there are functions like getNaNPayload).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 27 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3632




14:51:23 PDT ---




 This is intended. All nans are regarded as the same (even signalling and
 non-signalling).


 So we have to use std.math.isIdentical() to tell apart floating point values on
 the base of the their bit patterns.


Do you have any need for this?


 Related: I think almost no one uses the NaN payloads because (beside being a
 niche need) almost no language gives easy and explicit support to manage those
 payloads (while in std.math there are functions like getNaNPayload).


I've been around numerics for 35 years now, and I've never seen a use for NaN
payloads. I've never seen anyone even propose a use. Until then, I suspect
supporting such would just cause problems.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 27 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3632






 I've been around numerics for 35 years now, and I've never seen a use for NaN
 payloads. I've never seen anyone even propose a use. Until then, I suspect
 supporting such would just cause problems.


This report has always been asking for a bitwise comparion, which is (as far as
I can tell) how every other type is treated by 'is'.

The use case I can remember being discussed is using 'v is float.init' to
determine if a floating point value is uninitialized or is a nan due to the
result of a calculation.

This seems to be the reason float.nan and float.init have different payloads in
the first place.

Currently this fails:

struct A { float f; }
A a;
A b;
b.f = float.nan;
assert((a is b) is (a.f is b.f));

Making 'is' for floating point types consistent with 'is' for other types seems
to me like a better move than introducing a new special case.

Maybe Steven or Don have an opinion on this feature they asked for?
'isIdentical' seems to do a straight bitwise comparison.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 27 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3632




21:08:47 PDT ---


 Making 'is' for floating point types consistent with 'is' for other types seems
 to me like a better move than introducing a new special case.


The current behavior matches template argument matching. Making it different
from such will introduce all kinds of anomalous behavior.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 27 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3632






 The current behavior matches template argument matching. Making it different
 from such will introduce all kinds of anomalous behavior.


Fair enough.  I'm not sure which way is more useful, but they should definitely
match.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 27 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3632










 This is intended. All nans are regarded as the same (even signalling and
 non-signalling).


 So we have to use std.math.isIdentical() to tell apart floating point values on
 the base of the their bit patterns.


 
 Do you have any need for this?


I use it all the time, mainly for distinguishing between +0.0 and -0.0

But I think this has perhaps not been understood in this discussion: bitwise
compare doesn't just affect NaN, it also means that +0.0 !is -0.0.

There definitely seems value in changing 'is' so that 'A is A' is true for any
A. Note that any user-defined type can define == to always return false, so it
isn't true that 'A is B' implies 'A==B', so we don't lose consistency in that
way.

But it's reasonable to argue that '+0.0 is -0.0' should return true, and if you
do that, then 'NaN is NaN' should also return true, regardless of the payload.


 Related: I think almost no one uses the NaN payloads because (beside being a
 niche need) almost no language gives easy and explicit support to manage those
 payloads (while in std.math there are functions like getNaNPayload).


 
 I've been around numerics for 35 years now, and I've never seen a use for NaN
 payloads. I've never seen anyone even propose a use. Until then, I suspect
 supporting such would just cause problems.


NaN payloads were used extensively in Apple's SANE, to distinguish different
error types. Eg,

http://doc.4d.com/4D-Language-Reference-11.6/Error-Codes/SANE-NaN-Errors-1-255.300-206143.en.html

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 28 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3632




02:17:47 PDT ---


 I use it all the time, mainly for distinguishing between +0.0 and -0.0


'is' does distinguish between +0 and -0. Just not -Nan and +Nan, nor the Nan
payloads.


 But it's reasonable to argue that '+0.0 is -0.0' should return true, and if you
 do that, then 'NaN is NaN' should also return true, regardless of the payload.


I believe those are entirely different situations. The sign of 0 has a
mathematical meaning to fp arithmetic, the sign/payload of Nan does not.


 NaN payloads were used extensively in Apple's SANE, to distinguish different
 error types. Eg,
 http://doc.4d.com/4D-Language-Reference-11.6/Error-Codes/SANE-NaN-Errors-1-255.300-206143.en.html


I didn't know that. But it's worth noting that SANE has been dropped.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 28 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3632








 I use it all the time, mainly for distinguishing between +0.0 and -0.0


 
 'is' does distinguish between +0 and -0. Just not -Nan and +Nan, nor the Nan
 payloads.


Then I don't understand the reasoning. I don't think the payload NaN behaviour
is terribly important, but being able to do bitwise compare gives an _enormous_
speed benefit.

Note that it isn't possible to create a NaN with a payload at compile time, so
I don't think that the argument based on template behaviour is relevant -- as I
see it, either behaviour is reasonable.


 But it's reasonable to argue that '+0.0 is -0.0' should return true, and if you
 do that, then 'NaN is NaN' should also return true, regardless of the payload.


 
 I believe those are entirely different situations. The sign of 0 has a
 mathematical meaning to fp arithmetic, the sign/payload of Nan does not.


Yes, but my argument was the other way around: if you're going to special
trouble with -0, you should deal with NaNs as well. But now, if you haven't
given -0 special treatment, why slow down 'is' for the sake of the incredibly
obscure NaN payload case?

Why not just say, "it does a bitwise compare, which is fast but may give
unexpected answers in the case of negative zero and NaNs"?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 28 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3632




04:56:43 PDT ---


 The use case I can remember being discussed is using 'v is float.init' to
 determine if a floating point value is uninitialized or is a nan due to the
 result of a calculation.
 


[snip]

 
 Maybe Steven or Don have an opinion on this feature they asked for?
 'isIdentical' seems to do a straight bitwise comparison.


Quite simply, the above (v is float.init) is my use case.  In some parts of the
code, the runtime is responsible for default initializing data.  I wanted to
verify that my code was properly initializing the data to T.init.

This is impossible without casting the value to a ubyte[] array to do a
comparison (and even then, it's not quite right, because you can have garbage
data in some cases).

But it makes no sense to me for is to ever do anything but a bitwise compare.

In other words, given any type T (and I mean any type T):

foo(T t)
{
assert(t is t);
}

should always pass.  It makes no sense to me for is to do anything else -- it's
low-level bitwise comparison that bypasses any operators.

To make this true for every type *except* floating point types seems like a
huge inconsistency.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 28 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3632




05:02:11 PDT ---


 Reopening as the commit above will cause the following assert to fail:
 static assert(real.init !is real.nan);


If they are not the same bit pattern, I think this is fine.  is should be a
bitwise compare.  I don't know enough about floating point to know whether they
are the same bit pattern.

In my understanding of floating point, this means that:

if(x is typeof(x).nan) ...

is not wise code -- it may fail if the exact nan bitpattern is different (my
understanding is that nan has multiple representations).  While it may be
unintuitive, that is no fault of D -- floating point is sometimes very
unintuitive.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 28 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3632




06:37:46 PDT ---




 Reopening as the commit above will cause the following assert to fail:
 static assert(real.init !is real.nan);


 
 If they are not the same bit pattern, I think this is fine.  is should be a
 bitwise compare.  I don't know enough about floating point to know whether they
 are the same bit pattern.


I think I misread the above.  If the above assert fails, and they are different
bit patterns, this is definitely a problem.  Two different bit patterns should
fail to compare as equal.

== can do the intelligent standards-conforming thing, but 'is' should do
bitwise comparison.  If it doesn't, then you cannot use it as a tool to verify
low-level manipulation (such as allocating memory with a pre-defined value) is
working.  And I don't see the point of using 'is' on floating points otherwise,
it's misleading.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 18 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3632


yebblies <yebblies gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull
         AssignedTo|nobody puremagic.com        |yebblies gmail.com



New pull for this issue:

https://github.com/D-Programming-Language/dmd/pull/724

Walter, please reconsider your position - I really believe that the advantages
of 'is' always being a straight bitwise comparison outweigh the downsides.  As
you've pointed the inconsistency between how floats are handled with 'is' and
when determining if template value parameters match, I've changed that too to
make it consistent.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 15 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3632







 - I really believe that the advantages
 of 'is' always being a straight bitwise comparison outweigh the downsides.


This is what I was asking in the closed down issue 3981

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 16 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3632






 This is what I was asking in the closed down issue 3981


I know, that's why I closed issue 3981 with a comment saying that part was
covered by this report...

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 16 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3632




Commit pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/b558967f56b3702557e5c70132e77dd05561f2e3


Issue 3632 - modify float is float to do a bitwise compare

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 17 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3632




17:22:43 PST ---
change reverted - does not work

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 17 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3632




New pull to revert the revert.

https://github.com/D-Programming-Language/dmd/pull/730

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 17 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3632




Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/f9c21c2a77e32d310c8cb9d6c23f517d410cbec6
Reintroduce the fix for issue 3632, without the dependency on fixing issue
1824.


cleanly.

https://github.com/D-Programming-Language/dmd/commit/5da38bd430246d82e06d5581bb15325094821ca5


Reintroduce the fix for issue 3632, without the dependency on fixing issue
1824.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 27 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3632




15:43:54 PDT ---
Reverted because their tests failed.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 27 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3632




New (and hopefully last) pull
https://github.com/D-Programming-Language/dmd/pull/1499

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 16 2013