Re: Recovering D1 Code from .obj or .exe files
jicman wrote: Greetings! I need your help, if so at all possible... I just lost lots of code changes because a computer lock down, but I have a good .exe file with .obj and also .exe files. Is there a possibility to grab the code from those files? Or, is there any way that I can recover what I did this weekend? I have backups as of friday, but I did lots of work this weekend that I would like to get back. Any help would be greatly appreciated. thanks, josé Some time ago I looked at the binaries produced in linux. Template source code was in plain text in the executable. So if you did meta programming, you might recover those, unless they were somehow stripped.
Re: cast(int) getting an unexpected number
On Wed, 04 Nov 2009 06:14:36 -0500, Joel Christensen joel...@gmail.com
wrote:
Input:
import std.stdio;
void main() {
float f=0.01;
writefln(%0.2f-%d,f,cast(int)(f*100f));
}
Output:
0.01-0
Comment:
What!?
hehe. .01 is not exactly represented by float, because it's stored as a
binary value, not a decimal value. Think about how there is no way to
represent 1/3 in decimal.
If you imagined that the computer stored things in decimal, see how the
1/3 example would work
a = 1.0/3; // truncated to 0.333
a *= 3; // 0.999
auto i = cast(int)a; // 0
This is analagous to what you are asking the compiler to do.
To be safe, whenever converting to int, always add a small epsilon. I
think you can use float.epsilon, but I don't have any experience with
whether that is always reasonable.
-Steve
Re: cast(int) getting an unexpected number
Steven Schveighoffer schvei...@yahoo.com wrote:
On Wed, 04 Nov 2009 06:14:36 -0500, Joel Christensen joel...@gmail.com
wrote:
Input:
import std.stdio;
void main() {
float f=0.01;
writefln(%0.2f-%d,f,cast(int)(f*100f));
}
Output:
0.01-0
Comment:
What!?
hehe. .01 is not exactly represented by float, because it's stored as a
binary value, not a decimal value. Think about how there is no way to
represent 1/3 in decimal.
If you imagined that the computer stored things in decimal, see how the
1/3 example would work
a = 1.0/3; // truncated to 0.333
a *= 3; // 0.999
auto i = cast(int)a; // 0
This is analagous to what you are asking the compiler to do.
To be safe, whenever converting to int, always add a small epsilon. I
think you can use float.epsilon, but I don't have any experience with
whether that is always reasonable.
-Steve
why is this not a compiler bug?
because:
import std.stdio;
void main() {
float f=0.01;
writefln(%0.2f-%d,f,cast(int)(f*100f));
writefln(%0.2f-%d,f,cast(int)(.01*100f));
writefln(%0.2f-%f,f,(f*100f));
}
results in:
0.01-0
0.01-1
0.01-1.00
I would say something is dodgy.
-Rory
Re: cast(int) getting an unexpected number
Hello rmcguire,
why is this not a compiler bug?
because:
import std.stdio;
void main() {
float f=0.01;
writefln(%0.2f-%d,f,cast(int)(f*100f));
writefln(%0.2f-%d,f,cast(int)(.01*100f));
writefln(%0.2f-%f,f,(f*100f));
}
results in:
0.01-0
0.01-1
0.01-1.00
I would say something is dodgy.
-Rory
I think this may be case of:
At comple time floating point computations may be done at a higher precision
than run time.
http://www.digitalmars.com/d/2.0/function.html#interpretation
It seems that .01*100f is computed at compile time.
try declarting float f as const or invariant and see what happens (I'm not
sure..)
Re: cast(int) getting an unexpected number
Michal Minich wrote:
Hello rmcguire,
why is this not a compiler bug?
because:
import std.stdio;
void main() {
float f=0.01;
writefln(%0.2f-%d,f,cast(int)(f*100f));
writefln(%0.2f-%d,f,cast(int)(.01*100f));
writefln(%0.2f-%f,f,(f*100f));
}
results in:
0.01-0
0.01-1
0.01-1.00
I would say something is dodgy.
-Rory
I think this may be case of:
At comple time floating point computations may be done at a higher
precision than run time.
Yes, if you do this:
float f = 0.01;
float g = f * 100f;
real r = f * 100f;
writeln(%s, %s, %s, f, cast(int) g, cast(int) r);
you get:
0.01, 0, 1
I believe just writing cast(int)(f*100f) is more or less the same as the
'real' case above.
-Lars
Re: cast(int) getting an unexpected number
Lars T. Kyllingstad wrote:
Michal Minich wrote:
Hello rmcguire,
why is this not a compiler bug?
because:
import std.stdio;
void main() {
float f=0.01;
writefln(%0.2f-%d,f,cast(int)(f*100f));
writefln(%0.2f-%d,f,cast(int)(.01*100f));
writefln(%0.2f-%f,f,(f*100f));
}
results in:
0.01-0
0.01-1
0.01-1.00
I would say something is dodgy.
-Rory
I think this may be case of:
At comple time floating point computations may be done at a higher
precision than run time.
Yes, if you do this:
float f = 0.01;
float g = f * 100f;
real r = f * 100f;
writeln(%s, %s, %s, f, cast(int) g, cast(int) r);
you get:
0.01, 0, 1
I believe just writing cast(int)(f*100f) is more or less the same as the
'real' case above.
-Lars
Can that *really* be the explanation?? I know that float doesn't have
all that much precision, but I thought it was more than 5 or 6
places...and this is, essentially, two places.
Re: cast(int) getting an unexpected number
Charles Hixson wrote:
Lars T. Kyllingstad wrote:
Michal Minich wrote:
Hello rmcguire,
why is this not a compiler bug?
because:
import std.stdio;
void main() {
float f=0.01;
writefln(%0.2f-%d,f,cast(int)(f*100f));
writefln(%0.2f-%d,f,cast(int)(.01*100f));
writefln(%0.2f-%f,f,(f*100f));
}
results in:
0.01-0
0.01-1
0.01-1.00
I would say something is dodgy.
-Rory
I think this may be case of:
At comple time floating point computations may be done at a higher
precision than run time.
Yes, if you do this:
float f = 0.01;
float g = f * 100f;
real r = f * 100f;
writeln(%s, %s, %s, f, cast(int) g, cast(int) r);
you get:
0.01, 0, 1
I believe just writing cast(int)(f*100f) is more or less the same as the
'real' case above.
-Lars
Can that *really* be the explanation?? I know that float doesn't have
all that much precision, but I thought it was more than 5 or 6
places...and this is, essentially, two places.
Yes it does, but that's not what matters.
Say that for floats, the representable number closest to 0.01 is
0.010001. (This is just an example, I don't know the true
number.) Then you have a lot more precision than the two digits you
mention, and multiplying with 100 gives 1.0001. Round this
towards zero (which is what cast(int) does) and you get 1. This is the
'float g = f*100f;' case in my example.
Now, say that for reals, which (I think) is what the compiler uses
internally, the number closest to 0.01 is
0.0099.
Again, just an example, the point is that the precision is higher than
the above, but the closest number is now smaller than 0.01. Multiply
this by 100, and you get
0.99.
This number will be cast to the integer 0, which happens in the OP's case.
I admit I'm no expert in these things, but I suspect this is how it
goes. By the way, I recommend Don's excellent article on floating-point
numbers. It has really cleared things up for me:
http://www.digitalmars.com/d/2.0/d-floating-point.html
-Lars
Re: cast(int) getting an unexpected number
Ok, I messed up my previous comment while moving rmcguire's lines around.
Trying again... Also, I am not sure about the last bit now. :)
rmcguire Wrote:
why is this not a compiler bug?
because:
import std.stdio;
void main() {
float f=0.01;
Just an information: 0.01 is double, there is type conversion there.
writefln(%0.2f-%d,f,cast(int)(f*100f));
results in:
0.01-0
f*100f is represented to be less than 0.
writefln(%0.2f-%d,f,cast(int)(.01*100f));
results in:
0.01-1
.01 * 100f is double and apparently represented as something more than 1.
writefln(%0.2f-%f,f,(f*100f));
results in:
0.01-1.00
If it's like in C, floating point values must be passed as double arguments to
functions. So there is float-to-double conversion before the function call,
effectively representing the argument as double.
Ali
asserts in debug and release code
With respect to the dmd -release compiler switch, are assert statements meant to be compiled in release code? Whilst the D1 spec says The compiler may optionally not evaluate assert expressions at all., my intuition suggests that asserts would/should be evaluated (i.e. compiled in) when using -debug compiler switch and not when using the -release switch (and if neither switch who knows what***) *** And, btw, are -debug and -release mutually exclusive? If one desires asserts to be evaluated only in -debug, is the correct thing to prefix assert with debug as follows? debug assert(cond); Lastly, will assert/switch behaviour change in D2? Thanks for all help, Justin Johansson
Re: asserts in debug and release code
Hello Justin,
With respect to the dmd -release compiler switch,
are assert statements meant to be compiled in release code?
Whilst the D1 spec says The compiler may optionally not evaluate
assert expressions at all.,
my intuition suggests that asserts would/should be evaluated (i.e.
compiled in) when using -debug
-debug turns on debug{} sections
compiler switch and not when using the -release switch (and if neither
switch who knows what***)
-release turns off asserts and bounds checks
*** And, btw, are -debug and -release mutually exclusive?
No
char* to string
HI, I would like to use some pbobos string based functions within an DLL. Unfortunately all I can do is to pass char* parameters from the callee side. Now I want to use f.i. std.regex export extern(windows) char* xxx() //Heck were is Jarret when I need him most ? D2,beside Björn
Re: char* to string
On 05/11/2009 00:11, BLS wrote:
char* xxx()
better
char* xxx(char* a, char* b)
{
string A =
}
gap buffer in D2
yep, mean it... has somebody done it before...to me it seems to be not as trivial as it looks on the very first view. (speed matters)
Re: gap buffer in D2
BLS wrote: yep, mean it... has somebody done it before...to me it seems to be not as trivial as it looks on the very first view. (speed matters) Did one in C once for an editor (of course). Does that count? I might be able to find the code. It might not be pretty I can't remember.
Re: gap buffer in D2
On 05/11/2009 01:04, Spacen Jasset wrote: BLS wrote: yep, mean it... has somebody done it before...to me it seems to be not as trivial as it looks on the very first view. (speed matters) Did one in C once for an editor (of course). Does that count? I might be able to find the code. It might not be pretty I can't remember. YEP,would be nice to have a look. thanks! would be interesting to have a 2 gaps buffer for beyond-end insert (append)
Re: cast(int) getting an unexpected number
To be safe, whenever converting to int, always add a small epsilon. I think you can use float.epsilon, but I don't have any experience with whether that is always reasonable. -Steve Thanks every one for the replies. I still have problems. How do I use epsilon? 'real' helps in my example program but not in my money program. I think there's a function out there that does dollars and cents (eg. .89 - 89c and 1.00 - $1), but I'm interested how to solve this problem.
