On Saturday, 2 August 2014 at 07:36:34 UTC, Tofu Ninja wrote:
On Saturday, 2 August 2014 at 06:35:33 UTC, Chris Cain wrote:
Well, you can disagree but it doesn't change the fact that
what I meant and what you're saying are two different things.
With
Yes.... I disagreed with you... so yes I am saying something
different. What else is "disagreement" supposed to mean?
this knowledge you can now infer that you are putting forth
effort to intentionally misunderstand me despite me trying to
clarify that there is a difference, which isn't productive.
I understood what you said, I just disagreed with it. Are you
saying I can't disagree???
It depends on what you mean. You can disagree, but you can't
disagree with the fact that what I said and what you seem to
suggest I am saying are two different things.
So, in particular,
So a statement of fact is
simply the communication that the fact exists.
Is something that seems to be suggesting a meaning in my words
that doesn't exist.
Really specifically, I have a problem with "a statement of fact
is simply the communication that the fact exists." -> It's a form
of communication, but since a fact is defined as "something that
is actually the case/exists" and a statement of fact actually
isn't communicating that, then it makes a very real difference in
the potential interpretation of the words. In particular, your
definition of what I'm saying seems to imply that a "statement of
fact" suggests that a proof of that fact must exist before an
assertion is really an assertion, whereas a real statement of
fact doesn't necessarily have a proof of true or false just that
it *could be verified.* Thus an assertion without a proof is
still an assertion and communicating an idea that doesn't
necessarily have to be proven to finalize the communication. It's
just that, in particular, the idea communicated is a statement of
fact iff it were verifiable. Effectively that definition is just
removing extraneous things like beliefs, "god exists", "there
exists parallel universes that cease to exist the instant you
attempt to observe them", etc. Things that you couldn't verify or
falsify.
Basically, because we've had enough problems with what is being
actually being said, trying to take some liberties with what is
being said and trying to subtly change it is completely out of
the question. Until we start coming to an exact understanding of
what each other means, it's probably best if we don't disagree
with what the other person has defined as what they mean and
instead try to figure out what is being said.
If you want to introduce your own definitions and such, make it
clear (that is, don't start your paragraph with "I think what you
are calling a..." because it's prompting me to carefully consider
what you're saying as potentially redefining what I'm saying). It
just seemed to me that you were taking my words and trying to
suggest that I don't understand my own words or something. If
that wasn't what you were trying to do, I'm sorry.
Frankly, it seems we've regressed back to making up
definitions for words and phrases that are well-defined and
those well-defined meanings contradict what you're trying to
suggest. That's not going to help you understand why I think
assert makes sense given the real definition of an assertion.
None of these words or phrases are well defined.... if assert
was
well defined we would not be talking now....
That's not necessarily true. Disagreements exist on well-defined
definitions all the time.
I understand your argument, I just don't think it is correct.
Particularly I don't agree that your interpretation of assert
more closely matches the real meaning of assert. Let me
reiterate
why...
When something is asserted, there is the asserter(the person
making the assertion) and the asserti(s)(the person/people that
are hearing the assertion). Given that any thing that is
asserted
can either be true or false, the asserti has no choice but to
conclude that what is being asserted may or may not be true.
In the context of the programmer(asserter) and the
compiler(asserti). The programer is making an assertion that the
compiler must conclude to be either true or false. Because it
does not know if it is true or not, the only time it is
acceptable for the compiler to optimize as if it is true is to
actually check if it is true.
True, iff the asserter and assertee are human and doubt the
assertion. Assertions are typically taken until someone calls
into question the assertion. The compiler doesn't call into
question anything you do unless it has a proof that what you're
doing is wrong.
In particular, I take much of what you say to be truth, even if I
haven't explicitly asked you to verify it before we accept it as
truth. Furthermore, much of what you say isn't backed up with
proof at all (and yet I still accept it without proof). In fact,
the vast majority of conversations will do so (otherwise
absolutely nothing productive could be accomplished). That said,
if I have a reason to believe you are making an incorrect
assertion, I will either ask you to verify it or prove you wrong
about it. This makes conversations much faster since we often
assume things to be true if asserted true by the other party,
often skipping checks and verifications that would otherwise
potentially be necessary.
Obviously it's starting to sound a lot more like what a compiler
does when optimizing a program. When you assert something to the
compiler, it accepts it as true unless it has a really good
reason to believe it is logically inconsistent (that also
suggests that the compiler even tried to make sure it's logically
consistent, which I think would be a nice feature to have).
The point is that without the check, the assertion is neither
proven or disproven. If the compiler receives bad
input(incorrectly defined input is not bad input), then it knows
it is bad, but the compiler has no way of knowing if an
assertion
is good or bad.
I get your point, but I see asserts in the same class as most
(all?) other mechanisms. If it does not have a proof against what
you say, then it will not step in. You don't have to write proven
programs in general.
Since it doesn't have to prove your assertion (and it can't in
general, so that's a good thing), then it must accept your
assertion as good just like it accepts all of your other code as
logically good unless it has a reason to believe that it's not.
If the compiler receives two asserts that can not both be true,
then there is no way it can know what to do, there is no
resolution. But if the compiler is not smart enough to recognize
that they are contradictory then is just compiled an
uncompilable
program....
I've already covered that I think things that are provably false
might be helpful if the compiler actually pointed out the error.
That said, it's not a trivial problem to solve, so it's not
surprising that it doesn't solve it.
I can understand why you think that, I just don't agree. I don't
agree that an assertion in the english language means that
something will be true, I interpret it as a claim that something
may or may not be true.
Of course. But what point is there in telling a compiler that?
Obviously there's no point unless you're communicating some idea
to the compiler and communicating to the compiler that "here's
something that may or may not be true, so don't do anything about
it" is completely odd, strange, and special (in the sense that
there doesn't exist any other construct that I can think of that
does that... even ASM noops, which literally mean "do nothing",
have a purposeful effect on a program).
I expect a compiler to help me out, but ultimately I expect it to
trust my logic even if it can't verify it. Specifically, I don't
mind it stepping in with counter proofs to my suggestion that I
have a good program. But if it doesn't know whether my program is
good or not, I expect it to assume it is good. I've already shown
that your expectations for `if` statements and function calls are
almost certainly the same as my expectations for all language
features.
That is not an undefined program.... the code you just presented
was completely defined. An an example of an undefined program
with respect to assert is as follows.
assert(x==1);
assert(y==2);
Lets say the compiler was not smart enough to see that these
could not both be true. There is no way the compiler can produce
and thing that is correct because they both cannot be true.
There
will always be sets of conditions that the compiler can not
prove
to be contradictory(because of the halting problem) but that
are.
That is an undefined program...
The "undefined behavior" is that it allows these two to be
equivalent programs.
That is not the undefined behavior
Fine, I see what you mean. But I don't find it persuasive because
I just see it as a bad program no different than one constructed
from any other logic error. It'd be nice to have better
constructs to help prove correctness, but we can't do it in
general.
But in the context of what we actually can do, asserts make sense
to behave as described in this thread.
That is actually the point, no one would be complaining because
there would be nothing wrong. There would be no chance of
undefined behavior. If the check is always there then the
program
will always know that after the assert the condition is true and
would be free to do any optimizations it wants. The undefined
behavior occurs when you optimized as if they are true but do
not
check.
Actually, there would be something wrong. Two *very* different
programs would be compiled between an optimized build with
checked assertions and a program without checked assertions.
The difference of the programs with asserts as described in this
thread would be precisely the asserts themselves, which is
absolutely what you'd expect. No one would expect that removing
asserts could completely change *everything* about the code,
which is what is concluded by the behavior you describe.
Of course, you could suggest that "asserts shouldn't affect
optimization" -> but the problem there is that it matches no
definition of the English language version of assert because it
means "check to see if this is true" which is very, VERY far away
from the definition of "statement of fact forcefully". Hence why
I'm very eager to cast off that definition because it has a
meaning that is no where near the English definition.
