On Tue, 11 Oct 2011, Carsten Haitzler (The Rasterman) wrote:

> On Tue, 11 Oct 2011 08:40:33 +0200 (CEST) Vincent Torri <vto...@univ-evry.fr>
> said:
>
>>
>>
>> On Tue, 11 Oct 2011, Carsten Haitzler (The Rasterman) wrote:
>>
>>> On Tue, 11 Oct 2011 08:14:47 +0200 (CEST) Vincent Torri
>>> <vto...@univ-evry.fr> said:
>>>
>>>>
>>>>
>>>> On Mon, 10 Oct 2011, Enlightenment SVN wrote:
>>>>
>>>>> Log:
>>>>> use lround() for map coord rounding to avoid silly things like
>>>>>  15.999999999999999998 rounding down to 15... whihc leads to
>>>>>  sometimes... odd off-by-1 expected results.
>>>>
>>>> lround is C99 compliant and does not exist on Windows.
>>>>
>>>> why not using the macro
>>>>
>>>> #define round(x) (x<0?ceil((x)-0.5):floor((x)+0.5))
>>>
>>> because 1. i dont have a manual page for what is NOT supported in windows's
>>> dev envs (that's why we have you!).
>>
>> in google : "msdn the_function"
>>
>> Also, did you read the man page of lround ?
>
> i did.
>
> ...
>       long long int llroundl(long double x);
>
>       Link with -lm.
>
>   Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
>
>       All functions shown above:
>           _XOPEN_SOURCE >= 600 || _ISOC99_SOURCE ||
>           _POSIX_C_SOURCE >= 200112L;
>           or cc -std=c99
> ...
> CONFORMING TO
>       C99, POSIX.1-2001.
> ...
>
> nothing in the manual page on ubuntu requires any special compile flags other
> than -lm (as per usual) for linking. the manual differs from the one you quote
> below.

that manual is better than most of the manual I read. I also use the 
opengroup one too.

> note that the manula i have seems more complete. as such the standard
> for efl is c99 as an assumed base.

I thought it was POSIX...

>
>> See
>>
>> http://linux.die.net/man/3/lround
>>
>> did you read the line "Compile with -std=c99" ? Is that flag passed to the
>> compiler ? Note that i added an m4 macro that checks if a flags is
>> supported by the compiler
>>
>>   2. floor and ceil return doubles, not
>>> integers. lround returns a long int (long).
>>
>> so (long)ceil(15.999999999999999) does not return 16 ?
>
> correct. in some cases where 15.9999999999999 cannot in fp be represented as
> a value >= 16.0, this it gets slightly rounded down, and thus ends up being 15
> when dropped down to an integer. that is the whole crux of the problem.

the almost all the code using ceil() and floor() is broken, as the result 
of these functions is almost always casted to an int...

> so that means non-c99 platforms will have rendering bugs. there has to be a
> better way.

I don't know any. If someone has a clue...

Vincent

>
>> then
>>
>> #ifndef HAVE_LROUND
>> # define lround ****
>> #endif
>>
>> Vincent
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure contains a
>> definitive record of customers, application performance, security
>> threats, fraudulent activity and more. Splunk takes this data and makes
>> sense of it. Business sense. IT sense. Common sense.
>> http://p.sf.net/sfu/splunk-d2d-oct
>> _______________________________________________
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
>
>
> -- 
> ------------- Codito, ergo sum - "I code, therefore I am" --------------
> The Rasterman (Carsten Haitzler)    ras...@rasterman.com
>
>

------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to