> Greetings,
> I would vote to drop the macro, because supporting it for future
> use-cases can be a nightmare. What to use for ceiliing in those
> calculations is another matter... we could always just add 1 -
> FLT_EPSILON and call it a day.
I agree with you in drop the macro, and because nobody
You kids have heard about testing, right?
(Yes, that was incendiary)
The right way to deal with things like this is to make a few obvious
test cases and test. It's hard, because testing in C just sucks, but
that's another story.
cheers
aes
* FRIGN 2014-06-24 17:07
> Damn, you are right -.-. Back to the drawing board.
FWIW
CEILmy(x) ((int)(x) + ((x) - (int)(x) > 0))
the porblem with CEIL(3.01) remains, though.
--s.
On Tue, Jun 24, 2014 at 07:32:10PM +0200, FRIGN wrote:
> We are dealing with floats with at most 2 decimal places. I propose we
> just go for
>
> CEIL(x) ((int)(x) + ((x) > 0 && (int)(x) != (x)))
>
Well, if we know that much already then the easiest to read version
would be:
#define CEIL(x) ((i
2014-06-24 23:16 GMT+04:00 Roberto E. Vargas Caballero :
>> But who'd specify a scaling factor of 1.9 or sth.?
>> BTW: Casting to int yields the exact same results for both CEIL and
>> ceilf in my setup.
>
> There is an implicit casting because xw.cw and xw.ch are integers,
> so the explicit ca
> But who'd specify a scaling factor of 1.9 or sth.?
> BTW: Casting to int yields the exact same results for both CEIL and
> ceilf in my setup.
There is an implicit casting because xw.cw and xw.ch are integers,
so the explicit casting is redundant. This macro is used only in one place,
xloadfo
On Tue, Jun 24, 2014 at 01:54:00PM -0500, Eric Pruitt wrote:
> [1]:
> http://www.linuxquestions.org/questions/slackware-14/underline-_-in-xterm-invisible-4175434364/page2.html
I linked to the wrong page. The correct URL is as follows:
http://www.linuxquestions.org/questions/slackware-14/underli
On Tue, Jun 24, 2014 at 08:19:34PM +0200, FRIGN wrote:
> But who'd specify a scaling factor of 1.9 or sth.?
I have a height scaling factor of 1.0001 in my configuration file, and
the only reason I even bothered to implement the kerning patch in the
first place was to work around a rendering is
On Tue, 24 Jun 2014 19:47:34 +0200
Martti Kühne wrote:
> There are insignificant differences to results with this number
> (256.9), but it's a significantly faster than glibc's ceilf (which
> takes about 200%).
But who'd specify a scaling factor of 1.9 or sth.?
BTW: Casting to int yields
FRIGN wrote:
> We are dealing with floats with at most 2 decimal places.
Heyho,
in this case you could also argue, that this macro is only used to get an upper
bound for the character size in st and not for the least upper bound and then
use the even simpler version with CEIL(3.0) == 4.
But, as
On Tue, Jun 24, 2014 at 7:47 PM, Martti Kühne wrote:
> On Tue, Jun 24, 2014 at 7:32 PM, FRIGN wrote:
>>
>> CEIL(x) ((int)(x) + ((x) > 0 && (int)(x) != (x)))
>>
>
> There are insignificant differences to results with this number
> (256.9), but it's a significantly faster than glibc's ceilf (wh
On Tue, Jun 24, 2014 at 7:32 PM, FRIGN wrote:
>
> CEIL(x) ((int)(x) + ((x) > 0 && (int)(x) != (x)))
>
There are insignificant differences to results with this number
(256.9), but it's a significantly faster than glibc's ceilf (which
takes about 200%).
cheers!
mar77i
On Tue, 24 Jun 2014 18:27:57 +0200
"Roberto E. Vargas Caballero" wrote:
> This solution begins to be too much complex. In this case I begin to
> agree with Martti, and I think the best solution is to use ceil.
We must think if it is really necessary to do the
FLT_EPSILON-check.
We are dealing w
> CEIL(x) ((int)(x) + ((x) > 0 && ((x) - (int)(x)) > FLT_EPSILON))
This solution begins to be too much complex. In this case I begin to
agree with Martti, and I think the best solution is to use ceil.
Regards,
--
Roberto E. Vargas Caballero
On Tue, 24 Jun 2014 18:27:57 +0200
"Roberto E. Vargas Caballero" wrote:
> > CEIL(x) ((int)(x) + ((x) > 0 && ((x) - (int)(x)) > FLT_EPSILON))
>
> This solution begins to be too much complex. In this case I begin to
> agree with Martti, and I think the best solution is to use ceil.
*ceilf
To the
On Tue, Jun 24, 2014 at 5:34 PM, Jakob Kramer wrote:
>
> On 2014-06-24 Jakob Kramer wrote:
>> Finally, I don't think that reimplementing a function that already is
>> in the standard library for "more efficiency" makes any sense.
>> Correctness is most important, and I rather trust my C library
>>
Am 24.06.2014 16:46, schrieb Eric Pruitt:
On Tue, Jun 24, 2014 at 03:33:10PM +0200, FRIGN wrote:
However, I favor Martti's verson, which is just plain genius:
CEIL(x) ((int)(x) + ((x) > 0))
Perhaps I'm missing something here, but this completely fails whenever
(x) is already a whole number
On Tue, 24 Jun 2014 17:16:08 +0200
Martti Kühne wrote:
> #define CEIL(x) ((int)(x) + ((int)(x) > 0) * ((x - (int)(x)) > FLT_EPSILON))
FLT_EPSILON is very smart. I'll not withdraw your nomination for the
award.
However, why * and not &&? The latter would stop at x > 0 and not do
the diff-check in
On Tue, Jun 24, 2014 at 05:16:08PM +0200, Martti Kühne wrote:
> True.
> Hence, and following other sources about this topic [0], I suggest
>
> #define CEIL(x) ((int)(x) + ((int)(x) > 0) * ((x - (int)(x)) > FLT_EPSILON))
>
> cheers!
> mar77i
>
> [0]
> http://randomascii.wordpress.com/2012/02/25/com
>
> True.
> Hence, and following other sources about this topic [0], I suggest
>
> #define CEIL(x) ((int)(x) + ((int)(x) > 0) * ((x - (int)(x)) > FLT_EPSILON))
>
On another note, I'd even use && instead of * there, but that would
require another pair of parentheses.
On Tue, Jun 24, 2014 at 5:03 PM, FRIGN wrote:
> On Tue, 24 Jun 2014 09:46:33 -0500
> Eric Pruitt wrote:
>
>> CEIL(x) ((int)(x) + ((x) > 0))
>>
>> Perhaps I'm missing something here, but this completely fails whenever
>> (x) is already a whole number; CEIL(3.0) => 4.0 which is not the correct
>> b
On Tue, 24 Jun 2014 09:46:33 -0500
Eric Pruitt wrote:
> CEIL(x) ((int)(x) + ((x) > 0))
>
> Perhaps I'm missing something here, but this completely fails whenever
> (x) is already a whole number; CEIL(3.0) => 4.0 which is not the correct
> behaviour.
Damn, you are right -.-. Back to the drawing
On Tue, Jun 24, 2014 at 03:33:10PM +0200, FRIGN wrote:
> However, I favor Martti's verson, which is just plain genius:
>
> CEIL(x) ((int)(x) + ((x) > 0))
Perhaps I'm missing something here, but this completely fails whenever
(x) is already a whole number; CEIL(3.0) => 4.0 which is not the correct
On Tue, 24 Jun 2014 16:30:16 +0200
Jakob Kramer wrote:
> Finally, I don't think that reimplementing a function that already is in
> the standard library for "more efficiency" makes any sense. Correctness
> is most important, and I rather trust my C library implementation on that.
Jakob, this i
I don't really get why using would make the program more
complex, add to SLOC, make it slower... I don't think it is a big loss
to use -lm, as it is mostly a problem with the libc you might be using
if you have to link with an extra library for math functions.
Also, specifying something as a
On Tue, Jun 24, 2014 at 3:19 PM, FRIGN wrote:
> On Tue, 24 Jun 2014 09:13:11 +0200
> Martti Kühne wrote:
>
>> #define CEIL(x) ((int)(x) + ((x) > 0))
>
> Martti, you definitely are a candidate for the best macro-hack of
> 2014 ;).
>
Here's another one. Non-branching sign extraction...
#define SG
On Tue, 24 Jun 2014 08:50:01 +0200
"Roberto E. Vargas Caballero" wrote:
> I think a correct version may be:
>
> CEIL(x) ((int) (x) + ((x) > 0 ? 1.0 : 0.0))
>
This is not quite right, given we want to return an int (according to
xw.ch, xw.cw and common sense (ceilf doesn't make sense)), i
On Tue, 24 Jun 2014 09:13:11 +0200
Martti Kühne wrote:
> #define CEIL(x) ((int)(x) + ((x) > 0))
Martti, you definitely are a candidate for the best macro-hack of
2014 ;).
Cheers
FRIGN
--
FRIGN
> #define CEIL(x) ((int)(x) + ((x) > 0))
Wow, good solution. The only problem I can see is the return type, that
in your solution is integer. I think it is not a big problem because
this value will be used in some expression where the type convertion
will be done.
The original author of the comm
On Tue, Jun 24, 2014 at 8:50 AM, Roberto E. Vargas Caballero
wrote:
> CEIL(x) ((int) (x) + ((x) > 0 ? 1.0 : 0.0))
>
> Positive:
> CEIL(3.3) => 3 + (3.3 > 0 ? 1.0 : 0.0) => 4.0
>
> Negative:
> CEIL(-3.3) => -3 + (-3.3 > 0 ? 1.0 : 0.0) => -3
>
here's a shorter equivalent:
#
> No, this is wrong.
> Check cwscale and chscale in config.h, which are floats.
>
> xw.cw = CEIL(dc.font.width * cwscale);
> xw.ch = CEIL(dc.font.height * chscale);
>
> dc.font.width and dc.font.height are integers, but CEIL exlusively
> deals with floats.
Uhmmm, you are right (a
On Mon, 23 Jun 2014 09:32:09 +0200
"Roberto E. Vargas Caballero" wrote:
> For me it is ok to, but I think we are losing the point here. Why st has a
> macro called CEIL instead of using ceil?, because it is used only with
> integers, and in this case is faster use CEIL instead of calling ceil (wi
Markus Teich dixit:
> [0] http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html
Great read, thanks!
- Alex
> > 67 Bytes are nothing.
>
> Its bigger than a whole executable has to be[0]. ;)
>
> Apart from that I think it's absolutely fine to use the math library for math.
For me it is ok to, but I think we are losing the point here. Why st has a
macro called CEIL instead of using ceil?, because it is
Heyho,
FRIGN wrote:
> 67 Bytes are nothing.
Its bigger than a whole executable has to be[0]. ;)
Apart from that I think it's absolutely fine to use the math library for math.
--Markus
[0] http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html
On Sat, 21 Jun 2014 19:08:49 +0200
FRIGN wrote:
> Just pull in math.h ffs!
> It's part of the standard library, so basically nothing is lost both
> for dynamically linked programs and statically linked ones.
Okay, so I pulled it in using ceilf and the binary-size changed:
180514 Bytes -> 180581
On Sat, 21 Jun 2014 11:59:27 -0500
Eric Pruitt wrote:
> I have no problem with it, and that's what I would normally do, but
> there seems to be a lot of obsession of SLOC numbers in suckless
> projects, so I didn't want to pull in the math library for a single
> function.
Just pull in math.h ffs
On Sat, Jun 21, 2014 at 04:56:14PM +0200, Jakob Kramer wrote:
> What's the problem with ceil(3)? It is C89.
I have no problem with it, and that's what I would normally do, but
there seems to be a lot of obsession of SLOC numbers in suckless
projects, so I didn't want to pull in the math library f
Am 21.06.2014 16:05, schrieb Eric Pruitt:
On Sat, Jun 21, 2014 at 09:58:16AM +0200, Roberto E. Vargas Caballero wrote:
I do not understand why CEIL should return an integer value. From my
point of view it should return a value of any type that is the ceil
of the parameter. Can you explain a bit
On Sat, Jun 21, 2014 at 09:58:16AM +0200, Roberto E. Vargas Caballero wrote:
> I do not understand why CEIL should return an integer value. From my
> point of view it should return a value of any type that is the ceil
> of the parameter. Can you explain a bit better why you think result
> must be i
On Wed, Jun 18, 2014 at 09:09:19AM -0500, Eric Pruitt wrote:
> This patch ads explicit casting for the result of the CEIL macro. Since
> the only place it's currently used for assignments is with variables
> declared as ints, this shouldn't result in any change in behaviour in
> the existing code,
This patch ads explicit casting for the result of the CEIL macro. Since
the only place it's currently used for assignments is with variables
declared as ints, this shouldn't result in any change in behaviour in
the existing code, but it ensures the macro actually does exactly what
it says on the ti
42 matches
Mail list logo
