Wednesday, September 19, 2018

Digest for comp.lang.c++@googlegroups.com - 25 updates in 3 topics

Bart <bc@freeuk.com>: Sep 19 11:11AM +0100

On 19/09/2018 08:44, David Brown wrote:
 
> would prefer there to be /no/ promotion other than to a minimum common
> type that spanned both value ranges. (Thus u8 + u8 would be done as u8,
> but u16 + i8 would be done as i32.)
 
That's biased towards mixed-sign operations:
 
u8+u8 => u8 means 255+1 => 0
 
u16+i8 => i32 means 65535+1 => 65536
 
Perhaps u8+u8 should be done as u16.
 
--
bart
boltar@cylonHQ.com: Sep 19 10:12AM

On Wed, 19 Sep 2018 10:57:26 +0100
 
>Of course, if you do: 'v = u-10;' when u<10, then you will always end
>up with a very large unsigned value. There will always be such problems,
>but C as it is makes it worse I think.
 
You shouldn't really be doing mathematical operations with unsigned anything
in the first place. They're really meant for counters and bit/byte operations.
 
Still, look on the bright side, at least C and C++ have unsigned. Thats more
than Java got, which considering it was originally meant as an embedded
language seems an absurd decision to me.
David Brown <david.brown@hesbynett.no>: Sep 19 12:18PM +0200

On 19/09/18 11:57, Bart wrote:
 
> Of course, if you do: 'v = u-10;' when u<10, then you will always end
> up with a very large unsigned value. There will always be such problems,
> but C as it is makes it worse I think.
 
The point is, as you say, there will always be such problems. You can't
get away from that. The C rules are based on the idea that most numbers
fit fine within the range of int, so moving anything smaller into int
will most likely give you the right answer. It won't always be the way
you want it, and might not be the rule you think is best, but it works
fine for much of the time. No other choice of rule would be any
different - it's just the details of what it gets right and wrong that
would differ.
David Brown <david.brown@hesbynett.no>: Sep 19 12:37PM +0200

On 19/09/18 12:11, Bart wrote:
>> but u16 + i8 would be done as i32.)
 
> That's biased towards mixed-sign operations:
 
> u8+u8 => u8 means 255+1 => 0
 
That is what I would want, yes. Actually, sometimes I would want
unsigned types with undefined behaviour for overflow, like their signed
versions (and conversely, I sometimes want signed types with wrapping
overflow. And sometimes I want saturation for both signed and unsigned
types. And sometimes I want types to grow to cover the full range of
possible values. I want a choice of everything!).
 
More to the point, if I am using 8 bit types for arithmetic, I want
8-bit arithmetic.
 
 
> u16+i8 => i32 means 65535+1 => 65536
 
> Perhaps u8+u8 should be done as u16.
 
No, not for me.
 
The point of the example above is that i32 is the smallest type that can
hold all values of u16, and also all values of i8.
 
If you think u8 + u8 should be done as u16, then you should also expect
u32 + u32 to be done as u64, and u64 + u64 to be done as u128.
Bart <bc@freeuk.com>: Sep 19 12:05PM +0100

On 19/09/2018 11:37, David Brown wrote:
> possible values. I want a choice of everything!).
 
> More to the point, if I am using 8 bit types for arithmetic, I want
> 8-bit arithmetic.
 
What would you have for u8+i8?
 
(I've looked at a compiler where I've recently got rid of C-style
promotions to 'int', which introduced all sorts of complications.
 
There, with mixed integer operands (of size and type), I only widen one
to be the same width as the other, with signed always dominant. So
u16+i8 is done as i16. Not i32. And u8+i8 would be i8.
 
There are already so many issues working with such mixed int types, that
65535+1 giving zero here is a minor one. It is just necessary to take
care working with narrow types.)
 
> hold all values of u16, and also all values of i8.
 
> If you think u8 + u8 should be done as u16, then you should also expect
> u32 + u32 to be done as u64, and u64 + u64 to be done as u128.
 
And you would have a similar problem with u64 + i32; you'd need i128.
 
--
bart
David Brown <david.brown@hesbynett.no>: Sep 19 01:13PM +0200

On 19/09/18 13:05, Bart wrote:
 
>> More to the point, if I am using 8 bit types for arithmetic, I want
>> 8-bit arithmetic.
 
> What would you have for u8+i8?
 
The smallest type that can hold both these ranges - i16.
 
 
> There are already so many issues working with such mixed int types, that
> 65535+1 giving zero here is a minor one. It is just necessary to take
> care working with narrow types.)
 
However it is done, there will /always/ be some complications. And
there will always will be times when it is most convenient to have
promotions, and times when it is most convenient not to have promotions,
and unless you widen types enough, there will always be the risk of
overflow.
 
While I might have picked different rules myself for a language, I would
not want to change C's rules. That would just be confusing and break
existing code, no matter how they were changed. A single set of rules
may be imperfect, but it is better than multiple sets of rules!
 
 
 
>> If you think u8 + u8 should be done as u16, then you should also expect
>> u32 + u32 to be done as u64, and u64 + u64 to be done as u128.
 
> And you would have a similar problem with u64 + i32; you'd need i128.
 
Yes.
David Brown <david.brown@hesbynett.no>: Sep 19 01:14PM +0200

On 19/09/18 13:13, David Brown wrote:
>>> u32 + u32 to be done as u64, and u64 + u64 to be done as u128.
 
>> And you would have a similar problem with u64 + i32; you'd need i128.
 
> Yes.
 
At some point, of course, you'd be getting compiler warnings or an error
saying the type sizes are getting ridiculous :-)
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 19 04:15AM -0700

On Wednesday, September 19, 2018 at 3:36:41 AM UTC-4, David Brown wrote:
> For example, if "u" and "v" are "unsigned short" and were promoted to
> "unsigned int" rather than "int", then the expression "u + v - 10 >= 0"
> would always be true - which is clearly nonsense mathematically.
 
The problem there is in using unsigned arithmetic for a calculation
that may become negative. It's a programmer error, not a C error.
 
It's not the compiler's job to hold the developer's hand, but only
to provide them with the resources they need to thrive.
 
--
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 19 04:27AM -0700

On Wednesday, September 19, 2018 at 6:11:27 AM UTC-4, Bart wrote:
 
> u8+u8 => u8 means 255+1 => 0
> u16+i8 => i32 means 65535+1 => 65536
 
> Perhaps u8+u8 should be done as u16.
 
That is the approach CAlive takes, and storage operations are saturated
into their max value:
 
u8 a, b, c;
 
a = 255;
b = 100;
c = a + b;
// c is now 255 in CAlive
 
Operations:
 
01: t1 = promote a to u16
02: t2 = promote b to u16
03: t3 = t1 + t2, tagged as promoted u16 result
04: t4 = sign_saturate_u16_to_u8(t3);
05: c = t4 // c is set to 255, max value
 
CAlive will keep the value as u16 in case of additional operators:
 
a = 200;
b = 219;
if (a + b > 418)
printf("For triple time I'd eat Beanie." );
 
Operations:
 
01: t1 = promote a to u16
02: t2 = promote b to u16
03: t3 = t1 + t2, tagged as promoted u16 result
04: t4 = t3 > 418. // t4 is 1
 
It's as it should be for a language.
 
--
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 19 04:31AM -0700

On Wednesday, September 19, 2018 at 7:05:37 AM UTC-4, Bart wrote:
> What would you have for u8+i8?
 
I call them u8 for unsigned, and s8 for signed. It would be s16.
 
> And you would have a similar problem with u64 + i32; you'd need i128.
 
CAlive uses type bi (big integer, arbitrary precision) for values above
u64 and s64. The smallest bi is 128-bit. And bfp for big floating
point, the smallest bfp is 128-bit as well.
 
--
Rick C. Hodgin
David Brown <david.brown@hesbynett.no>: Sep 19 01:43PM +0200

On 19/09/18 13:27, Rick C. Hodgin wrote:
> b = 100;
> c = a + b;
> // c is now 255 in CAlive
 
Saturation is a /very/ different way of handling overflows. Sometimes
it is a useful way to do it, but you have to be aware of the costs here.
If you have saturation, you no longer have associative arithmetic - "x
+ 1 - 1" is no longer the same as "x". It might be the same in some
circumstances, but different in others, depending on the way the
expression is split up with temporaries - that is not good. It also
involves quite significant run-time costs on most platforms, and gives
results that would be surprising to many programmers.
 
I am fully in favour of saturation as an option, but I would avoid it as
default - I'd have it as a type qualifier or something like that.
 
> 03: t3 = t1 + t2, tagged as promoted u16 result
> 04: t4 = t3 > 418. // t4 is 1
 
> It's as it should be for a language.
 
Don't be so categorical. Consider the various possibilities (undefined
behaviour, wrapping, saturation, throwing an error, increasing the size
of the types, "NaN" values), and their pros and cons. Look at how other
languages handle the situation. Look at C (making sure you have the
correct C rules), Ada, Java, Pascal. Then try to think what would be
best for your language - whether it be one option, or whether you have
type qualifiers or different types with different behaviours. (Avoid
compiler switch options.)
 
What you can be sure of is that if you have one way of handling this
sort of thing, it will be wrong for some code and counter-intuitive to
some developers. There is /no/ right answer here - not with finite
limits on your type sizes. There is no "as it should be for a
language". There is just a matter of picking the rules that give the
smallest risk of problems for developers in the language.
David Brown <david.brown@hesbynett.no>: Sep 19 01:49PM +0200

On 19/09/18 13:15, Rick C. Hodgin wrote:
>> would always be true - which is clearly nonsense mathematically.
 
> The problem there is in using unsigned arithmetic for a calculation
> that may become negative. It's a programmer error, not a C error.
 
I agree that it is a programmer error, not a C error (or sort-of-C
error, since this was with non-standard C promotion rules). C has its
rules for promotions - they cannot be in error, as they are the defining
rules. So any code the programmer writes that does not do what he/she
wants is a programmer error.
 
The issue is what choice of rules for a language would minimise the risk
of the programmer making an error. The C committee picked a set that
they felt minimised the risk (given the type of C used at the time). My
point is that picking different rules - such as using
signedness-preserving promotion - would have changed which expressions
would be correct or incorrect, but it would /not/ have eliminated errors
due to promotions.
 
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 19 07:55AM -0400

On 9/19/2018 7:43 AM, David Brown wrote:
> it is a useful way to do it, but you have to be aware of the costs here.
> If you have saturation, you no longer have associative arithmetic - "x
> + 1 - 1" is no longer the same as "x".
 
In CAlive, saturation only happens on hard assignment. Promotion
is used throughout calculations.
 
 
> Don't be so categorical. Consider the various possibilities (undefined
> behaviour, wrapping, saturation, throwing an error, increasing the size
> of the types, "NaN" values), and their pros and cons.
 
CAlive provides <|decision|> casks for this purpose. Each
possible "thrown" condition can be captured on each line
using those casks:
 
a = 200;
b = 219;
if (a + b <|overflow|my_overflow_func()||> > 418)
printf("Yessiree buddy!");
 
In this case, the logic would be like this:
 
a = 200;
b = 219;
u16 t1 = a + b;
if (t1 > 255)
my_overflow_func();
if (t1 > 418)
printf("Yessiree buddy!");
 
Each cask is it's own self-contained thing, and it can be
injected anywhere in source code, and uses information
relative to where it is for its assignment, and you can
look at the code it generates to see if you put it in
the correct place. The general syntax is:
 
<|type|code||>
 
type = overflow, underflow, nan, etc.
 
> (Avoid compiler switch options.)
 
In my opinion, and I've heard this from several people here
in the C groups ... avoiding compiler switch options is an
absolutely ridiculous idea. I'm amazed people make such
claims. It honestly makes me think you're trying to hobble
my design, along with some of the other advice you give.
And yes I am serious.
 
There have to be ways to turn things on or off. They can
be added as something like a #pragma in source code, but to
limit the ability to add compiler command-line switches,
which allow external tools to use their various settings
however they do to then be translated and conveyed through
a standard protocol ... it's absolutely wrong advice. I'm
amazed any intelligent developer would suggest it, unless
they were on an agenda to give out wrong advice as per that
agenda.
 
--
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 19 08:34AM -0400

On 9/19/2018 7:55 AM, Rick C. Hodgin wrote:
>         my_overflow_func();
>     if (t1 > 418)
>         printf("Yessiree buddy!");
 
I should add, you can override the value in use using a
placeholder variable:
 
a = 200;
b = 219;
==> // Uses "x" as a placeholder variable
==> if (a + b <||x|overflow|my_overflow_func(x)||> > 418)
printf("Yessiree buddy!");
 
In this case, the logic would be like this:
 
a = 200;
b = 219;
u16 t1 = a + b;
if (t1 > 255)
==> t1 = my_overflow_func(t1);
if (t1 > 418)
printf("Yessiree buddy!");
 
--
Rick C. Hodgin
David Brown <david.brown@hesbynett.no>: Sep 19 02:36PM +0200

On 19/09/18 13:55, Rick C. Hodgin wrote:
>> + 1 - 1" is no longer the same as "x".
 
> In CAlive, saturation only happens on hard assignment. Promotion
> is used throughout calculations.
 
I don't quite know what you mean by "hard assignment". In most C
compilers, code like this would not involve any storage to memory, but
it would involve turning the results of "a + b" into a u8 type (i.e., a
value 99 in C).
 
> my_overflow_func();
> if (t1 > 418)
> printf("Yessiree buddy!");
 
To be brutally honest, I /much/ prefer a syntax like this second one to
your casks. It is not at all clear to me if the overflow function is
called as well as the passing the "if" test (which might be reasonable
for an overflow, but not for an underflow or if the comparison had been
< 418). With the expanded "C" version, it is clear.
 
 
> the correct place. The general syntax is:
 
> <|type|code||>
 
> type = overflow, underflow, nan, etc.
 
I honestly can't help feeling this is going to be ugly and unclear. I
would want either explicit handling (like your expanded C version
above), or possibly an implicit error handling system (like exceptions
in many languages). Your casks always seem to me to be the wrong place
to put things. I may not be your target audience for your language, but
casks would certainly be a turn-off for me. It's up to you to decide if
you think my opinion would be common amongst other potential users of
your language, or if they would agree with you about the usefulness of
casks. Your language has some new ideas that I like, but this is not
one of them.
 
> claims. It honestly makes me think you're trying to hobble
> my design, along with some of the other advice you give.
> And yes I am serious.
 
No, not at all - you are entirely mistaken.
 
Consider a "brightness" function for pixel colours. If you have
saturation on u8 arithmetic, you could write it as :
 
u8 brightness(u8 red, u8 green, u8 blue) {
return red + green + blue;
}
 
If you had two's complement wrapping on overflow, it would be completely
wrong. Agreed so far?
 
 
One possible way to allow programmers to choose overflow behaviour,
between saturation and wrapping, would be to have a command-line switch.
This may sound like a fine idea, letting programmers choose the default
behaviour they want.
 
But then the same source code does something entirely different
depending on the command-line switch. If you copy-and-paste the same
function source code into a different file, it might result in different
behaviour, depending on the switches used for that compilation. If you
look at the code in isolation, you can't tell if it is right or wrong,
or know that it relies on a particular choice of overflow behaviour.
 
This is /bad/.
 
 
On the other hand, if the function is written:
 
sat u8 brightness(sat u8 red, sat u8 green, sat u8 blue) {
return red + green + blue;
}
 
or :
 
u8 brightness(u8 red, u8 green, u8 blue) {
return sat_add(red, green, blue);
}
 
or :
 
u8 brightness(u8 red, u8 green, u8 blue) {
return red +.sat green +.sat blue;
}
 
Then the code is clear, and it stands by itself. (I have no opinions as
to which syntax is best - you pick.)
 
 
Do you see what I am getting at here?
 
 
Things like optimisation or warning choices are fine for command-line
switches - they affect the quality and efficiency of the generated code,
but not its correctness.
 
(In the interests of fairness and completeness, I should note that I
don't like gcc's code generation options like "-fwrapv" or
"-fno-strict-aliasing". When I need to work with external code that
requires these options, I put them in as pragmas in the code rather than
command-line options, to keep correctness independent from compiler
switches.)
 
 
> amazed any intelligent developer would suggest it, unless
> they were on an agenda to give out wrong advice as per that
> agenda.
 
You know fine that I do not have an agenda of giving out wrong advice.
Regardless of any arguments or disagreements we might have about
non-technical subjects, or on technical aspects of your language, or on
its practicality, you /know/ that I give my opinions honestly and with
the best technical knowledge and experience I can.
Bart <bc@freeuk.com>: Sep 19 01:59PM +0100

On 19/09/2018 13:36, David Brown wrote:
 
>> In CAlive, saturation only happens on hard assignment. Promotion
>> is used throughout calculations.
 
> I don't quite know what you mean by "hard assignment".
 
 
I think he means calculations are done with wider types as necessary,
but when stored to memory via assignment, then saturation is applied if
the destination is narrower.
 
(To me that would be such a rare requirement, and so unexpected in other
cases, that I would use an explicit function call to do that conversion.)
 
> }
 
> If you had two's complement wrapping on overflow, it would be completely
> wrong. Agreed so far?
 
Both signed and unsigned would usually give the wrong results.
 
(Actually the example is flawed. A 'luminance' function would return the
weighted sum of R, G, B, which is 255 max. While adding brightness to a
pixel involves add a value to each component, which is where you might
want saturation to occur.
 
But let's say to want u8+u8+u8 to return a u8 saturated value.)
 
> look at the code in isolation, you can't tell if it is right or wrong,
> or know that it relies on a particular choice of overflow behaviour.
 
> This is /bad/.
 
This is the thrust of half my complaints against C.
 
> }
 
> Then the code is clear, and it stands by itself. (I have no opinions as
> to which syntax is best - you pick.)
 
No need to invent operators for something that is so rarely needed; a
function would do.
 
But surely you don't need one to do the additions for you: just do
regular addition, using wide enough values to store the results, then
use a sat function to clamp the result.
 
And actually this example, if the additions are done as i32 or u32, can
simply become:
 
return min(red+green+blue, 255)
 
--
bart
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 19 09:00AM -0400

On 9/19/2018 8:36 AM, David Brown wrote:
> compilers, code like this would not involve any storage to memory, but
> it would involve turning the results of "a + b" into a u8 type (i.e., a
> value 99 in C).
 
"c = a + b;" is a hard assignemnt of the promoted result of "a + b"
to a variable. "if (a + b > 418)" uses the same promoted result as
part of the expression, but does not store it anywhere. As such,
in these examples, c would be 255, and the value used to compare
against 418 would be the sum of a + b as it is, promoted to u16 if
they were u8 to begin with.
 
>> printf("Yessiree buddy!");
 
> To be brutally honest, I /much/ prefer a syntax like this second one to
> your casks ... With the expanded "C" version, it is clear.
 
Code it that way. CAlive allows you to code it the first way
and auto-injects that code for you. Plus, in the GUI editor
the first line shows up like this:
 
if (a + b <|> > 418)
 
And the <|> is in a yellow background with black text, which
contrasts to the foreground color of the editor. It's also
shown in a reduced font size so it looks closer to small
diamond there.
 
All casks have the ability to be expanded or collapsed by a
GUI editor setting, or individually.
 
 
>> <|type|code||>
 
>> type = overflow, underflow, nan, etc.
 
> I honestly can't help feeling this is going to be ugly and unclear.
 
Don't use them. CAlive will still allow code as C does, and
you can code that way to your heart's delight.
 
> }
 
> If you had two's complement wrapping on overflow, it would be completely
> wrong. Agreed so far?
 
I would say the algorithm is wrong already. The colors r,g,b
account for 35%, 54% and 11% relative intensity of light, so
you cannot perform the logic you have above appropriately.
 
It would need to be:
 
u8 brightness(u8 r, u8 g, u8 b) {
return((u8)((f32)r*0.34f + (f32)g*0.54f + (f32)b*0.11f));
 
In the case of the proper algorithm, there's no issue. :-)
 
> between saturation and wrapping, would be to have a command-line switch.
> This may sound like a fine idea, letting programmers choose the default
> behaviour they want.
 
I allow this feature by enclosing the block that is to operate
as C does in a _c {..} block, a _c {{..}} block, or a _c {{..
}(_c)} non-aligning-block.
 
It can be messy in source code, but in the GUI editor it makes
it more tolerable and visual.
 
u8 brightness(u8 red, u8 green, u8 blue) {
_c {
return red + green + blue;
}
}
 
In this case, no auto-promotion, and things will wrap as they
do in C. Other examples:
 
u8 brightness(u8 red, u8 green, u8 blue) {
_c {{
return red + green + blue;
}}
}
 
u8 brightness(u8 red, u8 green, u8 blue) {
_c {{ return red + green + blue; }(_c)}
}
 
The purpose of the {{..}(x)} blocks are to allow mis-aligned
blocks. Here's a contrived example showing C code and CAlive
code blocks overlapping:
 
func example
| params u8 red, u8 grn, u8 blu
| returns u8 color
{
_c {{
color = red + grn + blu;
printf("Overflow value = %d, ", red);
_ca {{ // CAlive block
adhoc get_value { return(red + grn + blu); }
}(_c)}
printf("saturated = %d\n", get_value);
}}
 
In the GUI editor, the code would appear like this:
 
func example
| params u8 red, u8 grn, u8 blu
| returns u8 color
{
_c +--------------------------------------+
|color = red + grn + blu; |
|printf("Overflow value = %d, ", red); |
_ca+--------------------------------------|------+
|adhoc get_value { return(red + grn + blu); } |
+--------------------------------------+ |
| printf("saturated = %d\n", get_value); |
+---------------------------------------------+
 
There are different colored boxes which encapsulate the code.
And within the boxes, certain features are allowed or dis-
allowed based on many factors.
 
> look at the code in isolation, you can't tell if it is right or wrong,
> or know that it relies on a particular choice of overflow behaviour.
 
> This is /bad/.
 
Each source file is compiled using whatever options it should.
CAlive allows a settings input file for options, so they don't
have to be specified individually on a command line, but a single
file with options is provided.
 
> }
 
> Then the code is clear, and it stands by itself. (I have no opinions as
> to which syntax is best - you pick.)
 
I have ways to do this already.
 
 
> Things like optimisation or warning choices are fine for command-line
> switches - they affect the quality and efficiency of the generated code,
> but not its correctness.
 
Of course. And it's as it should be in my opinion.
 
>> they were on an agenda to give out wrong advice as per that
>> agenda.
 
> You know fine that I do not have an agenda of giving out wrong advice.
 
I do not know this. You often give out bad advice. I think
you honestly believe you are giving out your best advice, but
I know you are also deceived by the enemy of God into believing
wrong things, so the things you think are right are wrong, and
the reasons why you believe what you do are not your own, but
you have bought into them because you acquiesce to sin's call
by the evil spirits' leading and prompting you.
 
You've let them in over decades, David, and now they're there
in your mind affecting all of your thoughts, beliefs, actions,
etc.
 
Until you are willing to turn toward Christ, acknowledge your
sin, acknowledge your helpless state over their power because
of the ravages of sin against your very nature in sin, then you
have no hope. You will go through life believing you are right
when you are wrong, believing you are doing everything correctly
when you are being deceived into incorrect things, etc.
 
Jesus takes all of that away, and His Holy Spirit does guide you
rightly from within. It's why I point you to Him.
 
> non-technical subjects, or on technical aspects of your language, or on
> its practicality, you /know/ that I give my opinions honestly and with
> the best technical knowledge and experience I can.
 
I know that you believe you do this. I can only teach you that
you are wrong. I can't make you believe it. You have to have
that inner spark driving you to move, and that only comes from
God, and that only comes to those who are being saved (John 6:44).
 
--
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 19 09:04AM -0400

On 9/19/2018 8:59 AM, Bart wrote:
 
> I think he means calculations are done with wider types as necessary, but
> when stored to memory via assignment, then saturation is applied if the
> destination is narrower.
 
Correct.
 
> (To me that would be such a rare requirement, and so unexpected in other
> cases, that I would use an explicit function call to do that conversion.)
 
CAlive uses promotion on nearly every calculation. It sign-
saturates nearly every result. It does this so the intermediate
calculations can exceed their bit sizes, and still compute their
values correctly should the final result be in range.
 
CAlive looks at data from the point of view of the calculation
and not the limitation of the type representation.
 
You can override the ability to require a promotion by specifying
range information on variables. If a value can only be 0..100,
and another can only be 0..100, then two u8's being added together
would never exceed 255, so no need for promotion.
 
--
Rick C. Hodgin
David Brown <david.brown@hesbynett.no>: Sep 19 03:21PM +0200

On 19/09/18 15:00, Rick C. Hodgin wrote:
>> your casks ... With the expanded "C" version, it is clear.
 
> Code it that way. CAlive allows you to code it the first way
> and auto-injects that code for you.
 
In programming, you spend a fraction of your time writing - and a lot
more time reading. It does not help me if /I/ choose not to use casks,
if other people write code that is full of them. (And if other people
don't use them noticeably, then why would they be in the language at all?)
 
Choices are often a good thing, but not always. And here I could choose
to avoid /writing/ casks, but I could not choose to avoid having to read
them and understand them.
 
(But enough about casks - you know my opinion, I know yours.)
 
 
 
> u8 brightness(u8 r, u8 g, u8 b) {
> return((u8)((f32)r*0.34f + (f32)g*0.54f + (f32)b*0.11f));
 
> In the case of the proper algorithm, there's no issue. :-)
 
The "real" algorithm for brightness is utterly irrelevant to the example.
 
 
> u8 brightness(u8 red, u8 green, u8 blue) {
> _c {{ return red + green + blue; }(_c)}
> }
 
That is just getting more and more obscure, and I cannot see any purpose
in it.
 
 
> There are different colored boxes which encapsulate the code.
> And within the boxes, certain features are allowed or dis-
> allowed based on many factors.
 
All I can say here is that it makes C++ template syntax look clear and
intuitive :-)
 
> CAlive allows a settings input file for options, so they don't
> have to be specified individually on a command line, but a single
> file with options is provided.
 
That is completely missing the point.
 
 
>> Then the code is clear, and it stands by itself. (I have no opinions as
>> to which syntax is best - you pick.)
 
> I have ways to do this already.
 
If you are using code syntax to control the choices of behaviour on
overflow, rather than command-line switches, then we are in agreement.
I may feel that your syntax looks like the cat has sat on the keyboard,
but we are agreed on the principle.
 
>>> agenda.
 
>> You know fine that I do not have an agenda of giving out wrong advice.
 
> I do not know this. You often give out bad advice.
 
I am sure I have been wrong on occasion - but I have never knowingly
given bad advice. You confuse "does not agree with Rick" with "bad".
 
The same applies to advice I give to Bart regarding his language or
variations of C. There are often disagreements there too. But I like
to think that he knows my advice is given with the best of intentions
and based on my knowledge and experience, even when we disagree.
Paavo Helde <myfirstname@osa.pri.ee>: Sep 19 04:27PM +0300

On 19.09.2018 14:05, Bart wrote:
 
> There are already so many issues working with such mixed int types, that
> 65535+1 giving zero here is a minor one. It is just necessary to take
> care working with narrow types.)
 
Interesting. I have an example from the other extreme. We have a
scripting language with similar problems. However, this only concerns
vector arithmetics, there are no int8 scalars or such. So, on the script
level the script writer only writes something like
 
result = image1+2*image2;
 
and does not care about the types at all. The current underlying
implementation finds the best fitting result type dynamically by the min
and max values of the operand vectors and then performs the calculation
in chosen types.
 
This still leaves a choice between signed and unsigned types. A min/max
of 0 and 500 might be placed both in uint16 and int16. Currently
unsigned types are preferred, but this is just because our work
originates from image processing where unsigned types are more common.
 
There is no overflow and no wrapover, if the values do not fit into
int64 or uint64 any more the results will be converted over to double,
and if the values keep increasing eventually they might become inf.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 19 08:22AM -0400

On 9/19/2018 12:45 AM, Ian Collins wrote:
> Seeing as we we can't get past dogma, here's a couple of questions for you:
 
Calling it "dogma" casts it as a generic / diminished thing in
one's thoughts. It makes it more easy to discount the true
validity of the thing. Again, it's a way to side-step the full
realities of truth, labeling them as something they are not,
and then discounting them based on that label rather than on
their true merits.
 
You are consistently being deceived by the enemy in this way,
Ian. If that matters to you ... think about it, and then do
something about it.
 
> If you get sick, do you visit a doctor
 
Of course.
 
> or do you reject the science based
> research that gives us medicines?
 
No true person of faith rejects science. What we reject are
the conclusions that the things we see in "science" are the
result of some random happening. We conclude that God designed
this universe this way, this world this way, the things in the
world the way they are, all for a reason.
 
It's the interpretation of what is seen that is at question,
not the things seen.
 
> If a family member suffered from a mental illness, would you reject the peer
> reviewed studies that lead to a treatment?
 
Of course not.
 
> You use a computer, do you reject the scientific processes that enabled it to
> be built?
 
Of course not.
 
You ask ridiculous questions, indicating the ridiculous premise
from which you proceed regarding faith. The things you've seen
in the past with regards to faith which are ridiculous /ARE NOT
WHAT GOD CALLS US TO BE A PART OF/.
 
God doesn't call us to be ridiculous. He calls us to acknowledge
Him as He is, and honor Him as He is, holding Him rightly to the
place He is at and deserves to be in our lives.
 
-----
If you, Ian, created a great city, I mean literally designed and
built this huge city giving people houses, roads, infrastructure
to support the various things the people living there needed to
do ... wouldn't you expect the people there to honor you in some
way? Would you expect them to deny your existence and think the
city just sprang into existence by random happenings, out of a
Big Bang where nothing expanded out and became everything, and
then later cooled into a soupy goo, and the goo came alive and
made you and me and oranges and palm trees?
 
God does not ask for inappropriate things in our lives. There
is an enemy of God who often convinces people to believe in or
do things that are inappropriate under the flag / banner of being
a servant of God, but those misguided souls are not God, and God
does not guide people to be that way.
 
What God is is proper, in order, righteous, true, always helping
people, always being of benefit to people. He is our greatest
asset, our greatest ally, our greatest resource, and He calls us
into service commensurate with who He is.
 
For those who do wrong things with regards to God, they are under
the guise of the enemy's deceptions, operating falsely under a
belief they are operating rightly. But God gave us the Bible,
and gives us guidance toward rightness and truth by His Holy Spirit
to lead us when we go astray. That leading is backed up by what
He previously gave us in the Bible, so the two are in agreement,
and where they are not it must be rejected.
 
You are believing wrong things about God, Ian, and are dismissing
Him based on those wrong beliefs, rather than on His merits.
 
--
Rick C. Hodgin
David Brown <david.brown@hesbynett.no>: Sep 19 03:03PM +0200

On 19/09/18 14:22, Rick C. Hodgin wrote:
> realities of truth, labeling them as something they are not,
> and then discounting them based on that label rather than on
> their true merits.
 
Ian calls it "dogma" because it is "dogma". The word basically means
things that you think are true because you think they are true. When
you provide evidence and a rational, logical argument that is not
circular, then it will no longer be dogma.
 
You feel that Bible, as you interpret it, is self-consistent and
consistent with things you see around you. That's fine. But it is a
circular argument, and therefore dogma - and it cannot convince anyone
who does not have the same beliefs as you. How do you know the Bible is
the true word of god? Jesus said so. How do you know Jesus said so?
It is in the Bible. This is a circular argument. The same applies to
all your claimed scientific "proof" - it all starts with the assumption
that god made the world in exactly the way it is described in the Bible.
 
If you want anyone to accept your arguments as evidence, or scientific,
or rational, or non-dogmatic, then you need to start with independent
and objective evidence and derive a proof of the Biblical viewpoint from
that - not the other way round.
 
> to support the various things the people living there needed to
> do ... wouldn't you expect the people there to honor you in some
> way?
 
I would not expect worship, nor obedience to arbitrary rules.
 
And I would not give people a single dusty book full of unclear
ramblings, badly out of date, and inconsistent with much of what the
people see around them - and give that as the sole "evidence" of my
existence.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 19 09:11AM -0400

On 9/19/2018 9:03 AM, David Brown wrote:
> things that you think are true because you think they are true. When
> you provide evidence and a rational, logical argument that is not
> circular, then it will no longer be dogma.
 
You believe it is circular logic because you do not have your
sin forgiven, nor do you have your own spirit being led by
God's Holy Spirit.
 
Until this changes, you will forever believe that I am wrong,
not believing properly, believing the things I do arbitrarily
and without cause, etc.
 
There is a hard division between the saved and unsaved, David.
Today you are unsaved, and therefore you cannot know the things
a saved person knows.
 
It's why I ask you to go to local Bible-believing churches and
ask the people who are born again to speak to you of their own
testimonies. You will learn from their separate witnesses, by
people who have no agenda with you / toward you, the truth.
 
Until you do, you'll be forever deceived, all the while believing
you are right.
 
--
Rick C. Hodgin
David Brown <david.brown@hesbynett.no>: Sep 19 03:24PM +0200

On 19/09/18 15:11, Rick C. Hodgin wrote:
 
> You believe it is circular logic because you do not have your
> sin forgiven, nor do you have your own spirit being led by
> God's Holy Spirit.
 
It is circular logic because it goes around in a circle. That does not
mean it is not true, of course - it just means there is no independent
evidence.
Tim Rentsch <txr@alumni.caltech.edu>: Sep 19 06:13AM -0700

>> (unsigned) char.
 
> There's no such thing as a "character type" in C++, as the term
> is used here.
 
C++17 section 6.9.1 includes this sentence in paragraph 1:
 
Plain char, signed char, and unsigned char are three
distinct types, collectively called /narrow character
types/.
 
(The /'s indicate italics in the original, signifying a
definition of the italicized term.)
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)