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
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.
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
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.
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 bina
On Monday, 1 October 2012 at 04:10:25 UTC, Ivan Agafonov wrote:
On Sunday, 30 September 2012 at 06:20:56 UTC, jerro wrote:
The second one uses fstp twice, then fld twice. I don't know,
maybe
this could be a bug.
You're right the lack of one fst/fld in the first case is a
bug. x87 floating po
On Sunday, 30 September 2012 at 06:20:56 UTC, jerro wrote:
The second one uses fstp twice, then fld twice. I don't know,
maybe
this could be a bug.
You're right the lack of one fst/fld in the first case is a
bug. x87 floating point registers are 80 bit. This:
fstpdword [ebp-0CH]
Conver
Technically (AFAIK), IEEE754 does need require reproducibility,
ergo determinism.
It actually requires more than that:
"Algebraic operations covered by IEEE 754, namely + , - , * , / ,
square root and Binary <-> Decimal Conversion with rare
exceptions, must be Correctly Rounded to the prec
On Sunday, 30 September 2012 at 20:47:41 UTC, jerro wrote:
I don't really agree with that. floating point operations are
just inexact, regardless of optimizations. That's how they
work, period.
It is true that they are inexact, but inexact and
non-deterministic are not the same thing. Floatin
I don't really agree with that. floating point operations are
just inexact, regardless of optimizations. That's how they
work, period.
It is true that they are inexact, but inexact and
non-deterministic are not the same thing. Floating point
operations are deterministic. Doing the same operat
On 9/30/12, Tommi wrote:
> On Sunday, 30 September 2012 at 01:48:04 UTC, Andrej Mitrovic
> wrote:
>>
>> Dissasembly:
>> __Dmain:; Function begin, communal
>> enter 12, 0 ;
>> _ C8, 000C, 00
>> call_D4test8getFloatFNdZf
On Sunday, 30 September 2012 at 18:31:17 UTC, so wrote:
On Sunday, 30 September 2012 at 17:07:19 UTC, monarch_dodra
wrote:
On Sunday, 30 September 2012 at 01:29:24 UTC, Ivan Agafonov
wrote:
// Tell me about this sutation, may be it is a bug?
[SNIP]
// all of this fails!!!
asser
On Sunday, 30 September 2012 at 17:07:19 UTC, monarch_dodra wrote:
On Sunday, 30 September 2012 at 01:29:24 UTC, Ivan Agafonov
wrote:
// Tell me about this sutation, may be it is a bug?
[SNIP]
// all of this fails!!!
assert (a.length == a.length); // This is really shocking
On Sunday, 30 September 2012 at 01:29:24 UTC, Ivan Agafonov wrote:
// Tell me about this sutation, may be it is a bug?
[SNIP]
// all of this fails!!!
assert (a.length == a.length); // This is really shocking
assert (a.length == a3.length);
[SNIP]
This is just a fact of
On 09/30/2012 04:06 AM, Tommi wrote:
> On Sunday, 30 September 2012 at 01:48:04 UTC, Andrej Mitrovic wrote:
>>
>> Dissasembly:
>> __Dmain:; Function begin, communal
>> enter 12, 0 ; _ C8, 000C, 00
>> call _D4test8getFloatFNdZf ; 0004 _ E8,
>> (rel)
>> ...
>
> Can I tell DMD to produce
On Sunday, 30 September 2012 at 01:48:04 UTC, Andrej Mitrovic
wrote:
Dissasembly:
__Dmain:; Function begin, communal
enter 12, 0 ;
_ C8, 000C, 00
call_D4test8getFloatFNdZf ; 0004
_ E8,
(rel)
...
Can I tel
The second one uses fstp twice, then fld twice. I don't know,
maybe
this could be a bug.
You're right the lack of one fst/fld in the first case is a bug.
x87 floating point registers are 80 bit. This:
fstpdword [ebp-0CH]
Converts the value in ST0 to single precision float and stores it
On 09/29/2012 06:48 PM, Andrej Mitrovic wrote:
> The second one uses fstp twice, then fld twice. I don't know, maybe
> this could be a bug. My ASM is weak but I see some difference here..
I saw similar differences but my asm is even weaker. :)
I am writing to confirm that I can reproduce the pr
18 matches
Mail list logo
