Fixed. Thanks!

Could you email me feqrel then, please?

"Don Clugston" <dac@nospam.com.au> wrote in message news:dfm6r1$2o30$1@digitaldaemon.com...
> I'm delighted to see my name on the changelog, after such a short experience with D -- it's much easier to contribute to than C++ !!
>
> But looking in std.math, I see you've included my draft function,
> precisionEquality(). This was superceded by feqrel(). It should be
> removed in the next update.
>
> Might be worth making iabs public, though.
>
> I have written a few more functions for std.math, but I will submit them
>   together as a block.

"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:dfmkf1$34l$1@digitaldaemon.com...
> Somewhere between my email and the release the number 6 changed to a 3. It should be http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/27684

Fixed.

In article <dfl7ju$1u8b$1@digitaldaemon.com>, Walter Bright says...
>
>
>http://www.digitalmars.com/d/changelog.html
>

Walter thank you for doing the Bugs/4750 fix, but I think it's still a bit broken. Because, if a negative value compares again ulong.min it still gives the wrong result as the example code below shows.

# // negcompare3.d
# private import std.stdio;
#
# int main()
# {
#     long lValue1 = -128;
#     long lValue2 = +128;
#
#     writefln("With -128 in a literal works now.");
#     writefln("main() : (-128 >= 0)=%s, (-128 <= 0)=%s",
#              (-128 >= 0 ? "true" : "false"),
#              (-128 <= 0 ?  "true" : "false"));
#     writefln();
#
#     writefln("With -128 in a variable still works");
#     writefln("main() : (-128 >= 0)=%s, (-128 <= 0)=%s",
#              (lValue1 >= 0 ? "true" : "false"),
#              (lValue1 <= 0 ? "true" : "false"));
#
#     writefln("main() : (128 >= 0)=%s, (128 <= 0)=%s",
#              (lValue2 >= 0 ? "true" : "false"),
#              (lValue2 <= 0 ? "true" : "false"));
#
#     writefln();
#
#     writefln("But where I need it the most, it still does not!");
#     writefln("ulong.min=%d, ulong.max=%d", ulong.min, ulong.max);
#
#     writefln("main() : (-128 >= ulong.min)=%s, (-128 <= ulong.max)=%s",
#              (lValue1 >= ulong.min ? "true" : "false"),
#              (lValue1 <= ulong.max ? "true" : "false"));
#
#     writefln("main() : (128 >= ulong.min)=%s, (128 <= ulong.max)=%s",
#              (lValue2 >= ulong.min ? "true" : "false"),
#              (lValue2 <= ulong.max ? "true" : "false"));
#
#     return 0;
# }

Output:
-------------------------
C:\dmd>dmd negcompare3.d
C:\dmd\bin\..\..\dm\bin\link.exe negcompare3,,,user32+kernel32/noi;

C:\dmd>negcompare3
With -128 in a literal works now.
main() : (-128 >= 0)=false, (-128 <= 0)=true

With -128 in a variable still works
main() : (-128 >= 0)=false, (-128 <= 0)=true
main() : (128 >= 0)=true, (128 <= 0)=false

But where I need it the most, it still does not!
ulong.min=0, ulong.max=18446744073709551615
main() : (-128 >= ulong.min)=true, (-128 <= ulong.max)=true
main() : (128 >= ulong.min)=true, (128 <= ulong.max)=true

C:\dmd>

David L.

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
-------------------------------------------------------------------

MKoD: http://spottedtiger.tripod.com/D_Language/D_Main_XP.html

Walter Bright wrote:
> Could you email me feqrel then, please?

The feqrel() that is in std.math is the correct one.
precisionEquality() was the previous name of the same function,
and is deprecated. Delete lines 842 - 975 from std.math.
(except that you can retain iabs() in line 871-874).

Sorry for the confusion.

-Don.
> 
> "Don Clugston" <dac@nospam.com.au> wrote in message
> news:dfm6r1$2o30$1@digitaldaemon.com...
> 
>>I'm delighted to see my name on the changelog, after such a short
>>experience with D -- it's much easier to contribute to than C++ !!
>>
>>But looking in std.math, I see you've included my draft function,
>>precisionEquality(). This was superceded by feqrel(). It should be
>>removed in the next update.
>>
>>Might be worth making iabs public, though.
>>
>>I have written a few more functions for std.math, but I will submit them
>>  together as a block.
> 
> 
> 

David L. Davis wrote:
> In article <dfl7ju$1u8b$1@digitaldaemon.com>, Walter Bright says...
> 
>>
>>http://www.digitalmars.com/d/changelog.html
>>
> 
> 
> Walter thank you for doing the Bugs/4750 fix, but I think it's still a bit
> broken. Because, if a negative value compares again ulong.min it still gives the
> wrong result as the example code below shows.

I'd say it's just bad style to be comparing longs and ulongs.. If you compare a signed long with a value larger than long.max, the "correct" result is constant anyway, ditto for negative values compared with anything unsigned..


xs0

xs0 wrote:
> David L. Davis wrote:
>> In article <dfl7ju$1u8b$1@digitaldaemon.com>, Walter Bright says...
>> 
>>> http://www.digitalmars.com/d/changelog.html
>> 
>> Walter thank you for doing the Bugs/4750 fix, but I think it's still a bit broken. Because, if a negative value compares again ulong.min it still gives the wrong result as the example code below shows.
> 
> I'd say it's just bad style to be comparing longs and ulongs.. If you compare a signed long with a value larger than long.max, the "correct" result is constant anyway, ditto for negative values compared with anything unsigned..

It actually shouldn't be that difficult to implement correctly.

If one side of the comparison is a compile-time constant, the compiler can determine whether the result is constant on a case-by-case basis, and if it isn't constant, do the compare in the type of the side that isn't constant.

OTOH if you have this

    long l;
    ulong ul;
    ...
    if (l < ul) { ... }

the code that's generated for the if statement would be equivalent to this

    if ((l & long.min) || (cast(ulong) l < ul)) { ... }

Similarly,

    l > ul

would become

    !(l & long.min) && (cast(ulong) l < ul)

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

"David L. Davis" <SpottedTiger@yahoo.com> wrote in message news:dfnfsc$tg6$1@digitaldaemon.com...
> Walter thank you for doing the Bugs/4750 fix, but I think it's still a bit broken. Because, if a negative value compares again ulong.min it still
gives the
> wrong result as the example code below shows.

Unfortunately, that's the C integral promotion rules at work. If either operand is of unsigned type, then the result become an unsigned comparison.

"Hasan Aljudy" <hasan.aljudy@gmail.com> wrote in message news:dflc5g$21n3$1@digitaldaemon.com...
> ----------------------------------------------------------
> D:\Documents and Settings\Aljudy\temp>dmd bug.d E:\dmd\dmd\bin\..\..\dm\bin\link.exe bug,,,user32+kernel32/noi;
>
> D:\Documents and Settings\Aljudy\temp>bug
> -5/3 prints: 1431655763
> -5/2 prints: -3
> -7/3 prints: 1431655763
> -7/4 prints: -2
> -7/7 prints: -1840700271
> -8/7 prints: -1840700271
> -12/6 prints: -1431655768
> 12/6 prints: 2
> -9/7 prints: -1840700271
> -11/8 prints: -2
> -7/9 prints: 1908874353

How embarassing for me. When I fixed the CmpExp constant folding, I neglected to fix the DivExp and ModExp ones too, they have the same bug in it (using the wrong typedef). Anyhow, it's fixed now and will go out in the next update. Sorry about that. These tests are in the test suite now, so they'll stay dead. grrrr!

"Don Clugston" <dac@nospam.com.au> wrote in message news:dfon8m$21lt$1@digitaldaemon.com...
> The feqrel() that is in std.math is the correct one.
> precisionEquality() was the previous name of the same function,
> and is deprecated. Delete lines 842 - 975 from std.math.
> (except that you can retain iabs() in line 871-874).
>
> Sorry for the confusion.

Done. No problem.