Re: DConf 2013 official car/room sharing thread
On Monday, 29 April 2013 at 12:28:33 UTC, deadalnix wrote: Due to last minute issue, I find myself in an hotel in mountain view. 3km/2miles away from the caltrain, so I'll need someone to grab me if that is possible. I promise to be good company on the road :D deadalnix, I can pick you up, because I'll be in Mountain View, too.
Re: DConf 2013 official car/room sharing thread
I'll need to rent a car for the trip. So, I can pick anyone up along the way from Mountain View.
Re: Why are some casts from floating point to integral done differently
bearophile Wrote: > Aldo Nunez: > > I'll file a bug, but... > > If you don't like this you can add a comment after it: > http://d.puremagic.com/issues/show_bug.cgi?id=3970 > > Bye, > bearophile Thanks, bearophile! I just did.
Re: Why are some casts from floating point to integral done differently
Don Wrote: > The cast(uint) case is clearly a bug. Please file it in Bugzilla. I'll file a bug, but... > This happens because there are no built-in functions for converting from > float to unsigned. Values between int.max and uint.max need to be > treated specially. > > You're right, but why isn't it done for (float, double -> ulong) like it's done for (real -> ulong), where it's a simple conversion to long plus a fixup. It's not like (float -> real -> ulong) will introduce more precise non-zero bits (or will it?). Then there's the case of (float, double, real -> uint). Why isn't this done like (float, double, real -> ushort), where a simple conversion to int is done, and then the result is truncated to ushort? Wouldn't it work the same to do a simple conversion to long, and then truncate the result to uint? I'm just trying to understand why these simple, yet seemingly just as accurate methods weren't used.
Why are some casts from floating point to integral done differently from others?
I was testing evaluating cast expressions for a debugger I'm working on, when I came across this bit of behavior that hopefully Walter or someone else can explain. Most conversions in D from floating point to integer are done with the help of the x87 FP instructions: load FP number, store as integer. This is understandable. The following conversions are done differently: - float, double, real -> uint - float, double -> ulong They are done with the help of runtime functions called DBLULNG and DBLULLNG respectively. They work completely with x86 non-FP instructions. What I don't like about them is that they produce results that are inconsistent with the way the other conversions are handled. For example, (cast(uint) -1.0) becomes 0, whereas (cast(ulong) -1.0L) becomes 0x and (cast(ushort) -1.0L) becomes 0x.
