Remember, guys.

Xor is just one half of a addition without overflow (the other part is AND)

xor does not destroy information. it just mixes-up information.
therefore for swapping integers it works just as good as addition except
that xor does not overflow.


In this context it's identical, somewhat... well... ehm... hard to
explain.... don't get me started about galious-fields, where xor may
suddenly becomes multiply ect.


For software-guys xor is just a niffy thing. hardware-guys (hello vhdl)
do know that you can hardly live without it... Basic building block of
everything. most software-people just don't know.


Nils

On Apr 29, 11:18*am, andrew.neste...@softhome.net wrote:
Hi,
The last mathematicians way of doing was good thought.Though its
simple and quite obvious,generally atleast to me it wont strike to do
that way of doing the code.I would go for a programmers way of
doing.That explains somewhat where I can try to think different!
By the way as a matter of interest where did you come across this
piece?

Regards,
s.subbarayan

On Apr 29, 7:18 am, andrew.neste...@softhome.net wrote:
I'd have thought the "programmer" would have gone for

x ^= 3;

or at least

x = x == 1 ? 2 : 1;

(I'm not advocating these.)

stephen

b=(a+b)-(a=b);

In message <95Kdna-PB5q--IXVnZ2dnUVZ_uWdnZ2d@giganews.com>, Joel
<joelbenway@gmail.com> writes
Remind me how that works....

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

"Joel" <joelbenway@gmail.com> wrote in message
news:95Kdna-PB5q--IXVnZ2dnUVZ_uWdnZ2d@giganews.com...
must try harder - theres nothing that requires the a=b assignment to happen
after the access to a in (a+b).

peter

In message <9C%Rj.2004$WA5.1006@newsfe6-gui.ntli.net>, Peter Dickerson
<firstname.lastname@REMOVE.tesco.net> writes
It is quite possible that both A and B will equal B

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

On Apr 29, 11:00 pm, ssubbarayan <ssu...@gmail.com> wrote:
It may look a bit outdated now... I came across a russian translation
circa 197x from an earlier english book somewhere in 1987. My then
girlfriend (she was a radio-chemicist) used to use it as a stand for a
tea-pot, in order to do not harm a kitchen's table...

The original text title is (if my memory serves me correct, and please
take into account that I am back translating) "Errors and pitfalls in
Fortran
programming". Don't remember who is the author, sorry...

So it was dedicated to Fortran of that time. This may be used as an
excuise
to why the (2) did not use

C construction. The same with "x ^= 3;", since Fortran did not define
bitwise
ops in a standardized way...

Cheers,

Andrew

andrew.nesterov@softhome.net wrote:
I don't know why you call it "solution", since it's obviously incorrect.

That would be a beginner/inexperienced programmer.

A "programmer" would most likely opt for the '?:' operator in this case.

In reality that would the solution for a _good_ programmer.

--
Best regards,
Andrey Tarasevich

Andrey Tarasevich wrote:
Better yet and less and less understandable :

x = x%2 + 1;

On Fri, 02 May 2008 11:23:13 -0700, Andrey Tarasevich
<andreytarasevich@hotmail.com> wrote:

x^=3; // explain wtf this is doing right here
Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com

On May 2, 8:44*pm, Lanarcam <lanarc...@yahoo.fr> wrote:
<snip>

Rocky

Spehro Pefhany schrieb:

Toggeling the lowest two bits...

It's a WTF not to understand that this toggles just the two lowest bits.

Ok - I agree toggeling two bits can mean anything. It always depends on
the context.



The magic happends if you deeply understanand that an innocent xor is
half of an addition (the carry/overflow part) and half of an
multiplication (in galois-space at least) at the same time, along with
the consequences that this implies.

XOR rocks! I've optimized quite a bit of arithmetic with it, and it
wasn't always obvious. I sat there more than once in the middle of the
night, starred at a truth-table only to find out that x = A ^ (B+1) or
something similar was the fastest way to express an arithmetic expression.

Love it! Excellent! Binary arithmetic can be so beautiful.

Nils

Andrey Tarasevich wrote:
I vote for:
if (1 == x) x = 2;
else x = 1;

which is clear, and has no undefined states. Self-healing code.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.


** Posted from http://www.teranews.com **

In article <7tpm14h3ih2s46mnmul6qjpn8ck32e64ve@4ax.com>, Spehro Pefhany
says...
Changing a 2 to a 1 and a 1 to a two obviously I have noted though
that besides trying for the most obscure code to prove their worthiness
to program no-one has actually verfied the inputs are in range.

Robert
** Posted from http://www.teranews.com **

andrew.nesterov@softhome.net wrote:


So who writes this one?

x = x["0\02\01"];

--

On 2008-05-02, Robert Adsett <sub2@aeolusdevelopment.com> wrote:
<rant>

And? I don't know about everyone else but I find the constant
checking of prerequisites an annoying distraction when working on
code and a waste of time and space in final production code. I
can understand some extra sanity checking in debug code but these
should be in moderation and preferably protected by #ifdef DEBUG
or whatever.

If function f(x) is defined over the domain x = {1,2} and is
documented as such then there is no reason for f to check that the
parameter is a member of this domain. It is the responsibility of
the caller to ensure that this is the case and f is entitled to
return whatever it likes (or indeed not return) if this is not so.
Of course, for debugging it is useful to know straight away if x
is something different so a debug test may be appropriate but it
should be precisely that - a debug test and not in final code.

I have seen too many times code where the caller does a series of
sanity checks before calling the function which then repeats those
same checks. Does that strike you as remotely sensible? That
isn't smart or intelligent design - it actually indicates a poor
design process because you haven't made a decision as to where the
tests should be - in essence the function interface is poorly
documented regardless of any statement that may have been made
about the input domain.

Why place the burden on the caller? Well to begin with what if the
function returns a basic type - how do you indicate the error
condition in general? Also the caller has a much better understanding
of the circumstances in which the fucntion is being called. It is
often possible to reason that the caller simply cannot pass an
invalid value to the callee simply by the way it works.

I am not diminishing the importance of testing _external_ inputs
here - that is indeed necessary. But constantly checking the
results of other elements with your own program is a complete waste
of time. It doesn't matter how far you go, ultimately you have to
trust that the rest of your program works as intended.

</rant>

--
Andrew Smallshaw
andrews@sdf.lonestar.org

In article <slrng1rj7g.c0f.andrews@sdf.lonestar.org>, Andrew Smallshaw
says...
I don't think we are tremendously far apart really. I just observed
that no-one considered the possibility that the numbers might not be in
range. No asserts, no comments about acceptable range, nothing. That
combined with the search for obscure techniques I find a telling
cultural observation.

We could go on about the details of when and how to error check and I'm
not a paragon of checking either.

However, the fact that no one considered that the inputs could be out of
range (and for that matter your reaction to the observation) is an
interesting commentary on how we view this practice we call programming.
We seem to default to the assumption that the input values to our
current problem will be in the range we expect.

I wouldn't be surprised if obscure coding techniques and insufficient
range checking go together. And to be fair I think most contributions
to the obscure examples have been tongue in cheek.

Robert
** Posted from http://www.teranews.com **

Robert Adsett wrote:
So you didn't bother reading my reply?

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

** Posted from http://www.teranews.com **

Andrew Smallshaw schreef:
The assert() macro (or a homebrew equivalent)) offers a reasonably
concise way to achieve that, and can be considered to be a way of
documenting the pre- and postconditions of the code.

My experience is that a bit of defensive programming saves far more time
than it costs. Not only because catching errors early can save days of
debugging and (re-)testing, but more importantly because it forces one
to think about the pre- and postconditions and make them explicit.