[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120305085135.GC5728@port70.net>
Date: Mon, 5 Mar 2012 09:51:35 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: libm
* Rich Felker <dalias@...ifal.cx> [2012-03-04 13:43:39 -0500]:
> On Sun, Mar 04, 2012 at 03:50:41PM +0100, Szabolcs Nagy wrote:
> > maybe it should be called __rem_pio2_large ?
>
> That's better. Not sure what the best name would be..
>
renamed
> > i wrote it using generic since i couldnt come up with
> > any way to solve it in c99
>
> There's no way to solve it in C99 matching the return types, but if
> you don't care about return types, it's pretty easy (albeit ugly and
> verbose) with ?: conditionals based on sizeof(x).
>
hm i haven't even thought about return types
my problem was calling the double version of a function when the
arg is integral and the float version when the arg is float.
(it can be done with sizeof if we can assume there is a larger
integer type than float, but i thought that was ugly)
even if we don't care about return types and int arguments
it seems tgmath is very ugly
> > complex is missing but it is not hard to add
> > (if you want to wait for it)
>
> Either way.
>
> > the parts i wrote may need some review or testing
> > (it can be done after merging of course)
>
> Yes, I'm okay with that.
>
i can do the merge and then you git pull
or you can do it from libm
the long double ifdefs needs to be fixed
and math.h sorted out
> There's the libc-testsuite git repo, and then cluts. Neither is
> musl-specific. The former is much broader in scope; the latter is
> probably more intensive in the few areas it tests.
>
i know but i'm not content with either of those
imho there should be one libctest repo which is a bit more
organized than libc-testsuit and contains the cluts tests
as well
> > ok so using compound literal
> > i was thinking about this
> > something like this will work
>
> OK.
>
i saw that you removed the compound literal definition of
NAN, INFINITY etc from math.h
if we want to keep the headers c89 friendly then
isnan, isinf,.. cannot be defined without function call
maybe use static __isnanf,.. functions?
(i committed a compound literal based implementatoin for now)
> Yes, at least it would be a major undertaking to convert all the code
> and ensure that no bugs are introduced. I think it's fine leaving it
> how it is for now. I still want the fast isnan, etc. for applications
> to use, though (and for use by other parts of libc like printf).
>
i agree
> The semantics should only be changed if the goal is to consider
> NAN/INF as "large" values too. Of course you also get abs() for free
> using the representation and bitmask. Otherwise, for finite
> comparisons comparing the representations and comparing the
> floating-point values should have the same behavior.
>
hm but float compare will compile to different instruction
so there is at least performance difference
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
