Re: Very strange problem with comparing floating point numbers
On Monday, 1 October 2012 at 21:23:31 UTC, monarch_dodra wrote: What I was saying is that for built in types such a floats, "is" is (should be) no different from "==". But you catch something interesting: the fact that it provides different results is (IMO), a bug. Looking at it, I'd say the bug is probably that "==" is overly sensitive to extended precision. I've filed a BR: http://d.puremagic.com/issues/show_bug.cgi?id=8745 Please feel free to add anything to it. We'll see if Walter will react to it for a more definite answer. It looks like dmd uses x87 comparison instructions which are inexact comparing to is. So, similarity of is and == operators on built-in and user-defined types may be subject to float/double/real exception.
Accessing CoInit [is Troubleshooting Linker error]
I've made the changes needed to get past the linker error, but
have run into an Access Violation when using CoInitializeEx
Once again I've returned to 2.057 (without changing ole32.lib)
and this will compile and run.
pragma(lib, "ole32.lib");
extern(Windows)
int CoInitializeEx(void*, uint dwCoInit);
void main() {
CoInitializeEx(null, 0x2);
}
So while this function is also defined as STDAPI in ObjBase.h it
is working with windows linkage. Fastforward to dmd 2.060 with
the a library update. The code does not link. I change it to
extern(C) and linking is fine. However run-time is now an access
violation.
So I'm not really sure what I'm should be doing with this. And
Richard, I'm not having different results with coffimplib
generated library.
When are we getting coff support? Thanks all.
Re: Troubleshooting Linker error (Symbol Undefined)
On Monday, 1 October 2012 at 05:04:32 UTC, Andrej Mitrovic wrote: Find oleaut32.dll in your Windows folder, and run implib on it: $ implib oleaut32.lib oleaut32.dll /s Put the import lib in the same folder as the project and change linkage to extern(C). It works for me this way. Thank you, making these changes did do the trick, bunches of linkages changes needed in the Juno library though... and I wonder how many more I won't find just from compiling the lib... Still very confused why it ever compiled. Oh well.
Re: Very strange problem with comparing floating point numbers
On Monday, 1 October 2012 at 13:08:07 UTC, Maxim Fomin wrote:
2012/10/1 monarch_dodra :
On Monday, 1 October 2012 at 11:36:43 UTC, Maxim Fomin wrote:
On Sunday, 30 September 2012 at 17:07:19 UTC, monarch_dodra
wrote:
As a rule of thumb, NEVER use opEqual with floating point
types aniways.
You need to use some sort of comparison with leway for
error, such as
std.math.approxEqual.
It is possible to compare exactly floating point types by
binary
comparison, if it provides some benefits.
import std.stdio;
import std.math;
@property float getFloat()
{
return sqrt(1.1);
}
void main()
{
writeln(getFloat is getFloat); // doesn't fail
}
I think that what you are comparing here is the functions (the
address), and
not the results of the call. Try
writeln(getFloat() is getFloat()); //*May* fail
http://dpaste.dzfl.pl/1f94c0b1
[SNIP]
Hum, yes, I guess I was wrong about the comparison of functions.
Sorry!
Also, "is" works like opEqual on built in types, AFAIK, it
doesn't use any
"binary" magic or anything like that.
I don't understand what you are trying to say. Is operator at
runtime
compares two objects without calling opEquals functions (if
applied on
user-defined types). For built-in and derived types it is
similar to
== operator. Although, I am suprised that TDPL and spec doesn't
mention it (focused only on CT usage), there is a paragraph
(http://ddili.org/ders/d.en/null_is.html) from Turkish D book
which
clearly shows such usage - so, I think this a valid D feature.
Object
comparison at low-level (repz cmpsb) means binary comparison.
What I was saying is that for built in types such a floats, "is"
is (should be) no different from "==".
But you catch something interesting: the fact that it provides
different results is (IMO), a bug. Looking at it, I'd say the bug
is probably that "==" is overly sensitive to extended precision.
I've filed a BR:
http://d.puremagic.com/issues/show_bug.cgi?id=8745
Please feel free to add anything to it. We'll see if Walter will
react to it for a more definite answer.
Re: Using Cairo library bindings on Windows
On 10/1/12, KillerSponge wrote: > I just tested the examples and built my own small test project > with your bindings, they are working great! Thank you so much! :) > Cool, I'm glad it works for you. Btw there is a new version of Cairo out but I think CairoD hasn't yet been updated. If that's an issue feel free to file a bug so we don't forget to upgrade sometime later: https://github.com/jpf91/cairoD
Re: Troubleshooting Linker error (Symbol Undefined)
On Monday, 1 October 2012 at 15:22:20 UTC, Jesse Phillips wrote: On Monday, 1 October 2012 at 05:04:32 UTC, Andrej Mitrovic wrote: Find oleaut32.dll in your Windows folder, and run implib on it: $ implib oleaut32.lib oleaut32.dll /s Thanks, I'll to play with this more because my first attempt did not resolve the issue and instead has resulted in even more missing symbols. I didn't change export type or anything else so we'll see. From what i recall, i think i worked around this issue by using coffimplib.exe on the version of oleaut32.lib from the platform sdk, rather than trying to generate a lib from the dll.
Re: Troubleshooting Linker error (Symbol Undefined)
On Monday, 1 October 2012 at 05:04:32 UTC, Andrej Mitrovic wrote: Find oleaut32.dll in your Windows folder, and run implib on it: $ implib oleaut32.lib oleaut32.dll /s Thanks, I'll to play with this more because my first attempt did not resolve the issue and instead has resulted in even more missing symbols. I didn't change export type or anything else so we'll see.
Re: Very strange problem with comparing floating point numbers
2012/10/1 monarch_dodra :
> On Monday, 1 October 2012 at 11:36:43 UTC, Maxim Fomin wrote:
>>
>> On Sunday, 30 September 2012 at 17:07:19 UTC, monarch_dodra wrote:
>>>
>>> As a rule of thumb, NEVER use opEqual with floating point types aniways.
>>> You need to use some sort of comparison with leway for error, such as
>>> std.math.approxEqual.
>>
>>
>> It is possible to compare exactly floating point types by binary
>> comparison, if it provides some benefits.
>>
>> import std.stdio;
>> import std.math;
>>
>> @property float getFloat()
>> {
>>return sqrt(1.1);
>> }
>>
>> void main()
>> {
>>writeln(getFloat is getFloat); // doesn't fail
>> }
>
>
> I think that what you are comparing here is the functions (the address), and
> not the results of the call. Try
> writeln(getFloat() is getFloat()); //*May* fail
>
http://dpaste.dzfl.pl/1f94c0b1
It works with -m32 too.
_Dmain:
0x0806d0e4 <+0>: push %ebp
0x0806d0e5 <+1>: mov%esp,%ebp
0x0806d0e7 <+3>: sub$0x10,%esp
0x0806d0ea <+6>: push %esi
0x0806d0eb <+7>: push %edi
0x0806d0ec <+8>: call 0x806d0d4 <_D4test8getFloatFNdZf>
0x0806d0f1 <+13>:fstps -0x10(%ebp)
0x0806d0f4 <+16>:lea-0x10(%ebp),%esi
0x0806d0f7 <+19>:call 0x806d0d4 <_D4test8getFloatFNdZf>
0x0806d0fc <+24>:fstps -0xc(%ebp)
0x0806d0ff <+27>:lea-0xc(%ebp),%edi
0x0806d102 <+30>:mov$0x4,%ecx
0x0806d107 <+35>:xor%eax,%eax
0x0806d109 <+37>:repz cmpsb %es:(%edi),%ds:(%esi)
0x0806d10b <+39>:je 0x806d112 <_Dmain+46>
0x0806d10d <+41>:sbb%eax,%eax
0x0806d10f <+43>:sbb$0x,%eax
0x0806d112 <+46>:neg%eax
0x0806d114 <+48>:sbb%eax,%eax
0x0806d116 <+50>:inc%eax
0x0806d117 <+51>:call 0x806d164
<_D3std5stdio14__T7writelnTbZ7writelnFbZv>
0x0806d11c <+56>:call 0x806d0d4 <_D4test8getFloatFNdZf>
0x0806d121 <+61>:fstps -0x8(%ebp)
0x0806d124 <+64>:lea-0x8(%ebp),%esi
0x0806d127 <+67>:call 0x806d0d4 <_D4test8getFloatFNdZf>
0x0806d12c <+72>:fstps -0x4(%ebp)
0x0806d12f <+75>:lea-0x4(%ebp),%edi
0x0806d132 <+78>:mov$0x4,%ecx
0x0806d137 <+83>:xor%eax,%eax
0x0806d139 <+85>:repz cmpsb %es:(%edi),%ds:(%esi)
0x0806d13b <+87>:je 0x806d142 <_Dmain+94>
0x0806d13d <+89>:sbb%eax,%eax
0x0806d13f <+91>:sbb$0x,%eax
0x0806d142 <+94>:neg%eax
0x0806d144 <+96>:sbb%eax,%eax
0x0806d146 <+98>:inc%eax
0x0806d147 <+99>:call 0x806d164
<_D3std5stdio14__T7writelnTbZ7writelnFbZv>
0x0806d14c <+104>: call 0x806d0d4 <_D4test8getFloatFNdZf>
0x0806d151 <+109>: sub$0x4,%esp
0x0806d154 <+112>: fstps (%esp)
0x0806d157 <+115>: call 0x806d588
<_D3std5stdio14__T7writelnTfZ7writelnFfZv>
0x0806d15c <+120>: xor%eax,%eax
0x0806d15e <+122>: pop%edi
0x0806d15f <+123>: pop%esi
0x0806d160 <+124>: leave
0x0806d161 <+125>: ret
> Also, "is" works like opEqual on built in types, AFAIK, it doesn't use any
> "binary" magic or anything like that.
I don't understand what you are trying to say. Is operator at runtime
compares two objects without calling opEquals functions (if applied on
user-defined types). For built-in and derived types it is similar to
== operator. Although, I am suprised that TDPL and spec doesn't
mention it (focused only on CT usage), there is a paragraph
(http://ddili.org/ders/d.en/null_is.html) from Turkish D book which
clearly shows such usage - so, I think this a valid D feature. Object
comparison at low-level (repz cmpsb) means binary comparison.
Re: Very strange problem with comparing floating point numbers
On Monday, 1 October 2012 at 11:36:43 UTC, Maxim Fomin wrote:
On Sunday, 30 September 2012 at 17:07:19 UTC, monarch_dodra
wrote:
As a rule of thumb, NEVER use opEqual with floating point
types aniways. You need to use some sort of comparison with
leway for error, such as std.math.approxEqual.
It is possible to compare exactly floating point types by
binary comparison, if it provides some benefits.
import std.stdio;
import std.math;
@property float getFloat()
{
return sqrt(1.1);
}
void main()
{
writeln(getFloat is getFloat); // doesn't fail
}
I think that what you are comparing here is the functions (the
address), and not the results of the call. Try
writeln(getFloat() is getFloat()); //*May* fail
Also, "is" works like opEqual on built in types, AFAIK, it
doesn't use any "binary" magic or anything like that.
Re: Very strange problem with comparing floating point numbers
On Sunday, 30 September 2012 at 17:07:19 UTC, monarch_dodra wrote:
As a rule of thumb, NEVER use opEqual with floating point types
aniways. You need to use some sort of comparison with leway for
error, such as std.math.approxEqual.
It is possible to compare exactly floating point types by binary
comparison, if it provides some benefits.
import std.stdio;
import std.math;
@property float getFloat()
{
return sqrt(1.1);
}
void main()
{
writeln(getFloat is getFloat); // doesn't fail
}
Re: Is it possible to force CTFE?
On 27/09/12 15:01, bearophile wrote: Tommi: 2) Is it possible to specialize a function based on whether or not the parameter that was passed in is a compile time constant? I am interested in this since some years. I think it's useful, but I don't know if it can be implemented. I don't remember people discussing about this much. Bye, bearophile It has been discussed very often, especially around the time that CTFE was first introduced. We never came up with a solution.
