ENIGMA Forums

General fluff => General ENIGMA => Topic started by: RetroX on February 21, 2009, 05:59:52 PM

Title: XOR DOES NOT WORK
Post by: RetroX on February 21, 2009, 05:59:52 PM
-6 ERROR; FIX IT NOW.
Title: Re: XOR DOES NOT WORK
Post by: Game_boy on February 22, 2009, 10:01:41 AM
Can't you use other boolean operators as a workaround?
Title: Re: XOR DOES NOT WORK
Post by: RetroX on February 22, 2009, 10:11:18 AM
Yes, but xor is cooler.

BTW, the problem is that ENIGMA is converting "xor" into "^^" instead of "^." >_>
Title: Re: XOR DOES NOT WORK
Post by: Game_boy on February 22, 2009, 11:07:33 AM
XOR is extremely cool.
Title: Re: XOR DOES NOT WORK
Post by: score_under on February 28, 2009, 06:18:07 AM
XOR is extremely cool.
Of course, I mean... it spells "rox" backwards, so how can it not rock?
Title: Re: XOR DOES NOT WORK
Post by: Josh @ Dreamland on March 01, 2009, 08:29:11 PM
Bwahahahaha, I thought I went back over that. *shrugs*

I guess I just had no idea what to do with it, so I left it.

You'll probably live. I think I'll replace it with ^ for now, and if that leads to problems, I'll make a function for it. -.-
Title: Re: XOR DOES NOT WORK
Post by: RetroX on March 02, 2009, 06:52:52 PM
A xor function?  That ruins all of the fun.
Title: Re: XOR DOES NOT WORK
Post by: serprex on April 03, 2009, 07:54:30 PM
^ is not ^^. 5^3 should return 0 in that case, but it'll end up as 6. Just use !x!=!y instead of x^^y
Title: Re: XOR DOES NOT WORK
Post by: Josh @ Dreamland on April 20, 2009, 03:24:10 PM
Serpy, I'mma choke you. This is why we work with bools.

If I really must, I could have ENIGMA parse in a logical xor, but it shouldn't be a problem.  Could always do !!x ^ !!y.
Title: Re: XOR DOES NOT WORK
Post by: RetroX on April 22, 2009, 08:51:22 PM
Double negatives are bad.
Title: Re: XOR DOES NOT WORK
Post by: score_under on April 23, 2009, 10:52:42 AM
Double negatives are bad.
Then use tricky asm: (assuming var is in eax)
Code: [Select]
test eax,eax
setnz al
and eax,1
Title: Re: XOR DOES NOT WORK
Post by: serprex on July 27, 2009, 10:39:32 AM
!x^!y == !!x^!!y
Title: Re: XOR DOES NOT WORK
Post by: RetroX on July 27, 2009, 11:08:03 AM
!x^!y == !!x^!!y
true^false == false^true
Title: Re: XOR DOES NOT WORK
Post by: Josh @ Dreamland on July 29, 2009, 01:08:21 AM
What serp said. Probably a good idea.
Title: Re: XOR DOES NOT WORK
Post by: serprex on July 29, 2009, 10:04:21 PM
(!!x^!!y) == (!x^!y) == (!x!=!y)
Title: Re: XOR DOES NOT WORK
Post by: score_under on July 30, 2009, 08:18:33 AM
(!!x^!!y) == (!x^!y) == (!x!=!y)
I know pi to a higher accuracy than my processor. Your argument is invalid.
Title: Re: XOR DOES NOT WORK
Post by: serprex on July 31, 2009, 04:09:06 PM
Processors are pretty inaccurate with pi if that's all you measure them by. Maybe if you could calculate arbitrary lengths of pi faster than your processor given enough memory (Paper is plentiful), I might care
Go blow a goat:
Code: [Select]
>>> f=lambda x,y:((not not x)^(not not y),(not x)^(not y),(not x)!=(not y))
>>> f(False,False),f(False,True),f(True,False),f(True,True)
((False, False, False), (True, True, True), (True, True, True), (False, False, False))
Title: Re: XOR DOES NOT WORK
Post by: RetroX on August 01, 2009, 11:46:38 AM
I know pi to a higher accuracy than my processor. Your argument is invalid.
But is it 32- or 64-bit?
Title: Re: XOR DOES NOT WORK
Post by: serprex on August 03, 2009, 12:05:18 PM
It is quite probable to be 80 bit if it goes along with the 8087's extended precision
In either case, even 128 bits of pi is less accurate than 40 digits of pi. And that's assuming fixed point, not floating point. IEEE 754 128bit floating point only has 113 bits of precision
Title: Re: XOR DOES NOT WORK
Post by: Josh @ Dreamland on August 05, 2009, 11:05:57 AM
Retro: Doubles are always 64 bits anyway. Long doubles are not though, so don't be fooled. I've seen long doubles of size 8, 12, 16... ung.
Serpy: Lambda kills kittens. I saw it. Don't use it.

Oh, and as serpy says, there are 10 byte doubles. But I've never actually seen one. score_under was telling me about an instruction for dealing with those a couple days ago, so I imagine they're somewhere. But since long double is 12 bytes anyway, there's really no need to be troubled with details of a 10 byte one.