Bullet Physics in D
A while back, I tried porting Bullet Physics to D, and I decided to resume work on it. I've got the code I've ported so far at sourceforge.net/projects/bulletd. I wrote most of the code when I was early in my D learning experience, so it's fairly rough, and it's nowhere near complete (a rough line count analysis gave well under 5%), but it's a start. If anyone wants to help, it would be appreciated. My main reasons for making a port rather than a binding are that SWIG doesn't like nested classes, so it's useless for Bullet, and I wanted to integrate it with the GC. D and C++ are close enough that getting a port of at least the basic features shouldn't take too long; I'm not sure what I'll end up doing about the OpenCL options and such.
Re: Antti-Ville Tuuainen Passes GSoC Final Evaluation
On Tue, 21 Aug 2012 15:15:48 +0200, dsimcha wrote: Congratulations, Antti-Ville! This project creates a better implementation of precise GC heap scanning than anything that's been created so far for D. The goal is to eventually integrate it into standard D distributions. Any volunteers for beta testing? Code: https://github.com/Tuna-Fish/druntime/tree/gc_poolwise_bitmap The code for this project is a fork of druntime. The master branch was a failed (or less successful) experiment. The version we're going with for integration is the gc_poolwise_bitmap branch. Congratulations! Any numbers on how this is better than the status quo? -- Simen
Re: Dpaste - online compiler and collaboration tool dedicated to D Programming Language.
nazriel: I would like to share with you, Beta version of http://dpaste.dzfl.pl/ At the moment gives a 403 error :-( Bye, bearophile
Re: Antti-Ville Tuuainen Passes GSoC Final Evaluation
Congrats!
Re: NaNs Just Don't Get No Respect
On Tuesday, 21 August 2012 at 08:15:10 UTC, Don Clugston wrote: No, it's the other way around. The IEEE 754 standard defines min(x, NaN) == min(NaN, x) == x. According to the C standard, fmin() should be returning 10, as well. There is a bug in fmin(). However min() and max() are extremely unusual in this respect. Almost everything else involving a NaN returns NaN. I did not know that. It seems like a not-so-useful rule but I guess they have their reasons. Note that in my example, fmin() _did_ return 10 - it was min() that returned NaN...
Re: NaNs Just Don't Get No Respect
On 21/08/12 16:14, renoX wrote: On Tuesday, 21 August 2012 at 12:25:45 UTC, Chad J wrote: On 08/20/2012 11:09 AM, Andrej Mitrovic wrote: On 8/20/12, Walter Bright wrote: On 8/19/2012 6:33 PM, Chad J wrote: How? I remember reading a lot of material on NaNs in D, but I don't recall these. Set the control word for the x87 to turn it on. Probably have to do a little inline assembly. I thought you could do by setting FloatingPointControl in std.math. That looks much more convenient and clean. Gotta make the right thing easy to do, right? Except that it doesn't seem to work as expected (maybe an old compiler's bug..) Yeah, there's a bug in the code generation, at the moment for 80-bit reals it works on AMD but not Intel processors (!)
Re: NaNs Just Don't Get No Respect
On Tuesday, 21 August 2012 at 12:25:45 UTC, Chad J wrote: On 08/20/2012 11:09 AM, Andrej Mitrovic wrote: On 8/20/12, Walter Bright wrote: On 8/19/2012 6:33 PM, Chad J wrote: How? I remember reading a lot of material on NaNs in D, but I don't recall these. Set the control word for the x87 to turn it on. Probably have to do a little inline assembly. I thought you could do by setting FloatingPointControl in std.math. That looks much more convenient and clean. Gotta make the right thing easy to do, right? Except that it doesn't seem to work as expected (maybe an old compiler's bug..) RenoX How thread-local is it?
Antti-Ville Tuuainen Passes GSoC Final Evaluation
Congratulations, Antti-Ville! This project creates a better implementation of precise GC heap scanning than anything that's been created so far for D. The goal is to eventually integrate it into standard D distributions. Any volunteers for beta testing? Code: https://github.com/Tuna-Fish/druntime/tree/gc_poolwise_bitmap The code for this project is a fork of druntime. The master branch was a failed (or less successful) experiment. The version we're going with for integration is the gc_poolwise_bitmap branch.
Re: NaNs Just Don't Get No Respect
On 08/20/2012 11:09 AM, Andrej Mitrovic wrote: On 8/20/12, Walter Bright wrote: On 8/19/2012 6:33 PM, Chad J wrote: How? I remember reading a lot of material on NaNs in D, but I don't recall these. Set the control word for the x87 to turn it on. Probably have to do a little inline assembly. I thought you could do by setting FloatingPointControl in std.math. That looks much more convenient and clean. Gotta make the right thing easy to do, right? How thread-local is it?
Re: NaNs Just Don't Get No Respect
On 20/08/12 22:21, cal wrote: On Monday, 20 August 2012 at 19:28:33 UTC, Peter Alexander wrote: On Sunday, 19 August 2012 at 22:22:28 UTC, Walter Bright wrote: > I find it more likely that the NaN will go unnoticed and > cause rare bugs. NaNs in your output are pretty obvious. For example, if your accounting program prints "NAN" for the amount on the payroll cheques, someone is guaranteed to notice. But if it's a few cents off in your disfavor, it might take you years to discover there's a problem. Critical systems also would find a NaN command a lot easier to detect than an off-by-two command, and would be able to shut down and engage the backup. The problem is that it's easy for even NaN's to be filtered out. float x = 0.0f; float y; // oops float z = min(x, y); // NaN has disappeared, unnoticed! My argument is that conservative compile time errors on uninitialised variables are more likely to catch these errors. I just tried this: float a, b = 10; writeln(min(a, b), ", ", fmin(a, b)); Result: nan, 10 I think that is incorrect - both should give NaN. The scientific viz software I use at work returns NaN for any numerical operation on NaN values, means, smoothing, etc. No, it's the other way around. The IEEE 754 standard defines min(x, NaN) == min(NaN, x) == x. According to the C standard, fmin() should be returning 10, as well. There is a bug in fmin(). However min() and max() are extremely unusual in this respect. Almost everything else involving a NaN returns NaN.
Re: NaNs Just Don't Get No Respect
On Monday, 20 August 2012 at 19:28:33 UTC, Peter Alexander wrote:
[cut]
The problem is that it's easy for even NaN's to be filtered out.
float x = 0.0f;
float y; // oops
float z = min(x, y); // NaN has disappeared, unnoticed!
In theory, one could prevent this by setting the floating point
control word to trigger a trap when reading a NaN which I think
*should* be the default.
Unfortunately it doesn't seem to work, there is an FPE in the
code below, where it shouldn't.
Then again, the online compiler I've tried is very old: dmd-2.042.
import std.stdio, std.math, std.algorithm;
int main()
{
FloatingPointControl fpc;
fpc.enableExceptions(FloatingPointControl.severeExceptions);
float x = 0.0f;
float y; // oops
y=1;
float z = min(x, y);
writeln("min x,y=",z);
return 0;
}
<<
