Tim Murphy (29 May 2020 01:02) wrote:
> Integer maths is important at the language level - it will enable
> algorithms that weren't possible before e.g. dividing a list into
> equal halves or a for-loop for which we also need a function that
> generates a range).
Indeed. The only case I can
On Thu, 2020-05-28 at 17:07 -0500, Pete Dietl wrote:
> Thoughts?
I'm fine with these choices, insofar as I can tell. I reserve the
right to change my mind after seeing the full scope of the proposal :).
On Thu, 28 May 2020 at 22:07, Pete Dietl wrote:
> Upon taking a look at gnulib, I found that they have arithmetic wrap
> functions which guarantee wrapping.
> We can use these functions to guarantee that overflow will just wrap
> around.
>
> Let's leave the shift operators out for now.
>
> comp
Upon taking a look at gnulib, I found that they have arithmetic wrap
functions which guarantee wrapping.
We can use these functions to guarantee that overflow will just wrap around.
Let's leave the shift operators out for now.
comp is for complement. ~
In most scheme implementations, providing
On Thu, 2020-05-28 at 22:07 +0200, Jouke Witteveen wrote:
> Here is a thought: The current support for numeric variables is
> limited to unsigned numbers. We could choose to stick with that!
I'm not sure how this would work... it works today because we have no
subtraction and all numbers make can
On Wed, 2020-05-27 at 13:47 -0500, Pete Dietl wrote:
> Technically, the C standard allows for machines which don't use 2's
> complement. So should we consider our LONG_MIN to be -2^63 + 1?
>
> Also, signed arithmetic overflow is undefined behavior, so should we
> also indicate that we have
On Wed, May 27, 2020 at 8:47 PM Pete Dietl wrote:
>
> A few questions.
>
> Technically, the C standard allows for machines which don't use 2's
> complement.
> So should we consider our LONG_MIN to be -2^63 + 1?
>
> Also, signed arithmetic overflow is undefined behavior, so should we also
>
Any suggestions or comments?
On Wed, May 27, 2020 at 1:47 PM Pete Dietl wrote:
>
> A few questions.
>
> Technically, the C standard allows for machines which don't use 2's
> complement.
> So should we consider our LONG_MIN to be -2^63 + 1?
>
> Also, signed arithmetic overflow is undefined
A few questions.
Technically, the C standard allows for machines which don't use 2's complement.
So should we consider our LONG_MIN to be -2^63 + 1?
Also, signed arithmetic overflow is undefined behavior, so should we also
indicate that we have undefined behavior or should we use some
function
On Mon, 2020-05-25 at 15:44 -0500, Pete Dietl wrote:
> As for converting between bases, that could always be a separate
> function like `$(convert-base number,radix)` where radix is one of:
> 2, 8, 10, or 16
I agree it should be a separate function.
Perhaps it would be better to consider a more
> This really annoys me and keeps me on the fence about gnulib, and
> prevents me from completely switching (for example, moving to modern
> glob/fnmatch). I've only pulled in some relatively simple elements so
> far.
>
> So... I'm not sure which way to fall on that.
Apparently gnulib requires
>
> I believe the form being considered is:
>
> $(math OPERATOR,LIST)
I am still partial to `$(math ...)`
with only one argument.
> The only one I'm not sure about is overflow. That will need some
> thought. Gnulib contains a comprehensive set of macros to deal with
> overflow, in various
On Mon, 2020-05-25 at 13:28 -0500, Pete Dietl wrote:
> Question about 64-bit, what happens when compiling make for a 32-bit
> system? I don’t think c90 has `stdint.h`... maybe there’s something
> in gnulib. Anyway, would we want to support 64 bit integers even on
> 32-bit platforms?
32bit
On Mon, 2020-05-25 at 12:07 -0400, Sam Kendall wrote:
> I'd like to raise some questions that I think any proposal ought to
> answer. I'll assume a straw man proposal: there's one function, and
> it takes one of the following forms:
>
> $(math OPERATOR,VALUE1,VALUE2)
> $(math OPERATOR,VALUE1)
I
`long long` was not introduced until c99, neither was `stdint.h`, but
perhaps gnulib can help us out here.
On Mon, May 25, 2020 at 3:44 PM Pete Dietl wrote:
>
> > I was not even considering specifying the base of the the resulting
> > expansion. I was assuming it would always be base 10. I
> I was not even considering specifying the base of the the resulting
> expansion. I was assuming it would always be base 10. I don't have
> any good way to specify the output form.
>
> I was only considering the parsing of input (constant) values: whether
> we wanted to support 0xfff, 0o777,
On Mon, 2020-05-25 at 10:10 +, Edward Welbourne wrote:
> > > Mult-base support: should we support only base 10 integer
> > > constants in
> > > expressions, or also hex/octal constants?
> > I vote for decimal, hex, and binary.
> > Octal if you really want it.
>
> A case for octal and bitwise
On Mon, 25 May 2020 at 18:34, Pete Dietl wrote:
> Question about 64-bit, what happens when compiling make for a 32-bit
> system? I don’t think c90 has `stdint.h`... maybe there’s something in
> gnulib. Anyway, would we want to support 64 bit integers even on 32-bit
> platforms?
>
> If at all
Question about 64-bit, what happens when compiling make for a 32-bit
system? I don’t think c90 has `stdint.h`... maybe there’s something in
gnulib. Anyway, would we want to support 64 bit integers even on 32-bit
platforms?
Sam Kendall (25 May 2020 18:07) observed:
> If you have relational or equality operators, what does the boolean
> result look like? If the result is 1 for true and 0 for false, then
> you get a bad surprise: $(if $(math =,5,6),yes) expands to yes. If the
> answer is some nonempty string for true
I'd like to raise some questions that I think any proposal ought to answer.
I'll assume a straw man proposal: there's one function, and it takes one of
the following forms:
$(math OPERATOR,VALUE1,VALUE2)
$(math OPERATOR,VALUE1)
A binary operator (first form) is one of + - * and /. The only unary
>>> Bit Manipulation:
>>> --
>>> * and
>>> * or
>>> * xor
>>> * complement
>>> * left shift
>>> * right shift
>>
>> Maybe. I have a hard time coming up with uses for these, other than
>> possibly the shift operators (but multiplication/division can be used
>> instead).
Pete
On Sun, 2020-05-24 at 14:09 -0500, Pete Dietl wrote:
> > I think, as I mentioned before, that someone (I guess that's you
> > :)) should write up an actual proposal (maybe, for example, the
> > start of a new manual section) that can be examined and commented
> > on.
>
> Challenge accepted! What
> I think, as I mentioned before, that someone (I guess that's you :))
> should write up an actual proposal (maybe, for example, the start of a
> new manual section) that can be examined and commented on. Endless
> streams of mailing list responses quickly give diminishing returns. My
>
On Sat, 2020-05-23 at 15:43 -0500, Pete Dietl wrote:
> > I understand what Tim is saying but I still prefer to have a single
> > function. I want to reduce the "namespace leakage" for these
> > capabilities. If we decide to add more operations to this in the
> > future I don't want it colliding
> I understand what Tim is saying but I still prefer to have a single
> function. I want to reduce the "namespace leakage" for these
> capabilities. If we decide to add more operations to this in the
> future I don't want it colliding with something else we want to do.
>
> However, sometimes
On Fri, 2020-05-22 at 23:14 -0500, Pete Dietl wrote:
> So we are back to debating between many functions or (one or two)
> functions. Anyone else care to weigh in?
I understand what Tim is saying but I still prefer to have a single
function. I want to reduce the "namespace leakage" for these
> If anyone can provide any use case where >64bit math is needed in a
> makefile I'll be interested to hear about it.
Yeah fair enough :)
Then we can always build in support since the size addition to the
Make binary will be trivially changed.
> > * negate
> > * absolute value
> > * exponentiate
On Wed, 2020-05-20 at 10:34 -0500, Pete Dietl wrote:
> I really like the idea of using GMP to do the math.
No, I'm not willing to make that requirement.
If anyone can provide any use case where >64bit math is needed in a
makefile I'll be interested to hear about it.
But, my position is that if
On Tue, 2020-05-19 at 15:21 +0100, Tim Murphy wrote:
> A question would be do we want to use GMP or are 64 bit ints enough?
> I'm inclined to say ints are ok of they are wide.
Straight 64bit integer arithmetic is fine IMO. I'm definitely not
interested in adding another library dependency.
>
30 matches
Mail list logo
