• Dan (19/19) Nov 13 2012 I've been trying to wrap my mind around D and come up with my own
• Jonathan M Davis (18/21) Nov 13 2012 Glancing over them, I don't see any major problems. Casting to immutable...
• Dan (19/44) Nov 14 2012 I hope floating points are equal iff their byte representation is

"Dan" <dbdavidson yahoo.com> writes:

I've been trying to wrap my mind around D and come up with my own 
philosophies for how to use it best. I've been getting many 
questions answered on the *learn* forum. I wanted to present some 
thoughts here in the hopes that if the ideas and approaches are 
glaringly wrong the experts will let me know pretty quickly.

For instance, I have my own take on how to address this issue 
discussed here.

http://www.digitalmars.com/d/archives/digitalmars/D/Copying_structs_with_pointers_140951.html
http://www.digitalmars.com/d/archives/digitalmars/D/learn/Confused_about_const_19185.html

Unfortunately, it does not come about until page 18. But 
hopefully some will take the time to read what I have produced 
and set me straight. :-)

The document is at: 
https://github.com/patefacio/d-help/blob/master/doc/canonical.pdf

I'm particularly interested in knowing if my handful of casts in 
this code are as safe as I hope.
https://github.com/patefacio/d-help/blob/master/d-help/opmix/mix.d


Thanks
Dan

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Tuesday, November 13, 2012 21:40:57 Dan wrote:
 I'm particularly interested in knowing if my handful of casts in
 this code are as safe as I hope.
 https://github.com/patefacio/d-help/blob/master/d-help/opmix/mix.d

Glancing over them, I don't see any major problems. Casting to immutable is 
safe as long as there are no other mutable references to the data, and casting 
away const is safe as long as you don't mutate anything after casting const 
away (though ideally you still wouldn't be casting away const).

The one cast that I'd be a bit concerned about would be casting the floating 
point value in deepHash to its representative bytes. I believe that the cast 
itself is okay, but I don't think that it's necessarily the case that the same 
floating point value will always have the same physical representation. At 
minimum, NaN won't. So, it _might_ work with all normal floating point numbers 
(I'm not well enough versed in the exact layout of IEEE floating point numbers 
to be sure), but it _won't_ work with NaN. At minimum, you'll have to special 
case NaN if you want NaN to always result in the same hash. Of course, if a 
hash table were to use == as part of finding the key (I don't think that the 
built-in AAs currently do though), NaN would be pretty screwed anyway (since 
it would never be found even if it were there 50 times), so I don't know how 
big a deal it is. Better safe than sorry though.

- Jonathan M Davis

"Dan" <dbdavidson yahoo.com> writes:

On Wednesday, 14 November 2012 at 06:32:19 UTC, Jonathan M Davis 
wrote:
 The one cast that I'd be a bit concerned about would be casting 
 the floating
 point value in deepHash to its representative bytes. I believe 
 that the cast
 itself is okay, but I don't think that it's necessarily the 
 case that the same
 floating point value will always have the same physical 
 representation.

I hope floating points are equal iff their byte representation is 
exactly the same. If this is true then hash look up will return 
false even for very small epsilon differences in value - but that 
is the deal with floats.

 At
 minimum, NaN won't. So, it _might_ work with all normal 
 floating point numbers
 (I'm not well enough versed in the exact layout of IEEE 
 floating point numbers
 to be sure), but it _won't_ work with NaN. At minimum, you'll 
 have to special
 case NaN if you want NaN to always result in the same hash. Of 
 course, if a
 hash table were to use == as part of finding the key (I don't 
 think that the
 built-in AAs currently do though), NaN would be pretty screwed 
 anyway (since
 it would never be found even if it were there 50 times), so I 
 don't know how
 big a deal it is. Better safe than sorry though.

Per this I am adding a special case for NaN in toHash. I already 
have a special case for NaN in typesDeepEqual (and therefore ==).

Regarding the "copying structs with pointers" thread, your view 
on 20/07/11 was:

"Maybe we actually need a copy constructor of some kind for this 
sort of case.
  I don't see how to get around it with a postblit. This is 
definitely a big
  problem."

With a generalized "dup" function for copying const(T) would you 
agree this is not really an issue?

Thanks,
Dan

 - Jonathan M Davis