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

6 ERROR; FIX IT NOW.

Can't you use other boolean operators as a workaround?

Yes, but xor is cooler.
BTW, the problem is that ENIGMA is converting "xor" into "^^" instead of "^." >_>

XOR is extremely cool.

XOR is extremely cool.
Of course, I mean... it spells "rox" backwards, so how can it not rock?

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. .

A xor function? That ruins all of the fun.

^ 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

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.

Double negatives are bad.

Double negatives are bad.
Then use tricky asm: (assuming var is in eax)
test eax,eax
setnz al
and eax,1

!x^!y == !!x^!!y

!x^!y == !!x^!!y
true^false == false^true

What serp said. Probably a good idea.

(!!x^!!y) == (!x^!y) == (!x!=!y)

(!!x^!!y) == (!x^!y) == (!x!=!y)
I know pi to a higher accuracy than my processor. Your argument is invalid.

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:
>>> 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))

I know pi to a higher accuracy than my processor. Your argument is invalid.
But is it 32 or 64bit?

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

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.