1. RE: not_bits() not_working()
Al Getz wrote:
> I've found that Euphorias not_bits() function doesnt really work
> correctly.
>
> For example:
>
> atom a,x
> a=2
>
> x=not_bits(a)
>
> --now x equals -3, which isnt correct.
> --x should be equal to the 8 digit hex equivalent of -3,
> --right?
Actually, it is. not_bits() works exactly as it says it does (although
it does seem odd):
"Results are treated as signed numbers. They will be negative when the
highest-order bit is 1." -- Refman
So the bits are correct. The quickest way to convert to unsigned (if
that's what you want) seems to be to have 4-bytes allocated and do a
poke4/peek4u after not_bits. (I just tested this vs adding 2^32 and vs
using xor_bits against a constant equal to 2^32-1). (These were tested
with Win2K, P3, 1.1GHz)
If you printf with %x (hex formatting) or use int_to_bits, you'll see
that the bits are correct.
Matt Lewis
2. RE: not_bits() not_working()
Carl W. wrote:
>
>
> Al Getz wrote:
>
> > atom a,x
> > a=2
> >
> > x=not_bits(a)
> >
> > --now x equals -3, which isnt correct.
> > --x should be equal to the 8 digit hex equivalent of -3,
> > --right?
>
> The *_bits() functions all return negative if the high bit of the result
>
> is 1. They use signed 32-bit ints internally I presume.
>
> try:
>
> function not_bitsU(atom a) -- U = Unsigned
> return #FFFFFFFF - a
> end function
>
> or better (but slower):
>
> constant B32m1 = power(2,32)-1
> function not_bitsU(atom a) -- U = Unsigned
> return B32m1 - and_bits(a, B32m1)
> end function
>
> Carl
>
> --
> [ Carl R White == aka () = The Domain of Cyrek = ]
> [ Cyrek the Illogical /\ www.cyreksoft.yorks.com ]
>
>
Hello there Carl,
I have been using poke4 and peek4u right after the not_bits(),
but i'll also take a look now at your subtraction functions.
I think 'a' in my use will always be positive, but ill have to
double check first.
Thanks for the ideas,
Al
3. RE: not_bits() not_working()
Matt Lewis wrote:
>
>
> Al Getz wrote:
>
> > I've found that Euphorias not_bits() function doesnt really work
> > correctly.
> >
> > For example:
> >
> > atom a,x
> > a=2
> >
> > x=not_bits(a)
> >
> > --now x equals -3, which isnt correct.
> > --x should be equal to the 8 digit hex equivalent of -3,
> > --right?
>
> Actually, it is. not_bits() works exactly as it says it does (although
> it does seem odd):
>
> "Results are treated as signed numbers. They will be negative when the
> highest-order bit is 1." -- Refman
>
> So the bits are correct. The quickest way to convert to unsigned (if
> that's what you want) seems to be to have 4-bytes allocated and do a
> poke4/peek4u after not_bits. (I just tested this vs adding 2^32 and vs
> using xor_bits against a constant equal to 2^32-1). (These were tested
> with Win2K, P3, 1.1GHz)
>
> If you printf with %x (hex formatting) or use int_to_bits, you'll see
> that the bits are correct.
>
> Matt Lewis
>
Hello Matt,
I have been using poke4 and peek4u to convert because it seems
to be the most reliable way to do it with only three ops, however
now ill have to check out Carls idea too. There is a chance that
my argument will always be positive.
I just cant help wondering why not_bits() doesnt work the way
the other _bits functions work, or did i miss something?
Is there any real use for getting a return value of -3 for
not_bits(2) out there? anyone?
Take care,
Al
4. RE: not_bits() not_working()
rolf at rschr.de wrote:
>
>
> Al Getz wrote:
>
> > atom a,x
> > a=2
> >
> > x=not_bits(a)
> >
> > --now x equals -3, which isnt correct.
>
>
> It is correct! look at this (or try it yourself):
> ---------------------------------------------------
> printf(1,"%08x\n", 2 ) -- 00000002
> printf(1,"%08x\n", not_bits(2) ) -- FFFFFFFD
> ---------------------------------------------------
>
> Please notice also:
>
> 0000 0000 0000 0000 0000 0000 0000 0010 = 2 = #00000002
> 1111 1111 1111 1111 1111 1111 1111 1101 = -3 = #FFFFFFFD
>
> Have a nice day, Rolf
>
Hi Rolf,
I think you will find that the results of the printf statement
using the '%x' hex formatter is very very misleading.
Just because it 'displays' the correct hex value doesnt mean
it's stored internally in a form that is correct for using
with the other _bit functions. Strange for sure 
In order to be certain, you have to print the number out
two times: once using the '%x' formatter and once using the
'%d' formatter (or just '?').
Try that and note what the results are and how they differ.
Take care for now,
Al
5. RE: not_bits() not_working()
Derek Parnell wrote:
>
>
> ----- Original Message -----
> From: "Al Getz" <Xaxo at aol.com>
> To: "EUforum" <EUforum at topica.com>
> Subject: not_bits() not_working()
>
>
> > Hello,
> >
> > I've found that Euphorias not_bits() function doesnt really work
> > correctly.
> >
> > For example:
> >
> > atom a,x
> > a=2
> >
> > x=not_bits(a)
> >
> > --now x equals -3, which isnt correct.
> > --x should be equal to the 8 digit hex equivalent of -3,
> > --right?
> >
>
> Sorry Al, but it does exactly what I'd expect it to do. Each bit in the
> 32-bit value is reversed. If it didn't work this way a number of
> functions
> in win32lib would fail.
>
> --
> Derek
>
>
Yes it is working, but didnt appear to be working because
printf with the %d formatter prints it as a negative number
sometimes, and when you use the %x formatter it prints as
a regular hex number.
Al
6. RE: not_bits() not_working()
- Posted by rforno at tutopia.com
Jun 27, 2003
The bit functions are in Eu (and Assembly, C, etc.) to use individual bits,
not their "global" meaning. So, you can compress 31 yes - no data in a
single integer, for example.
Assume you have a big file, each record containing an identifier from 1 to
1,000,000,000.
You want to scan the file and find which identifiers are missing and which
are duplicated.
Using a sequence occupying ~ 256Mb, you can get the job done by reading the
file only once, if you flag each identifier by means of the corresponding
bit in the sequence.
Regards.
----- Original Message -----
From: Al Getz <Xaxo at aol.com>
To: EUforum <EUforum at topica.com>
Sent: Thursday, June 26, 2003 4:07 PM
Subject: RE: not_bits() not_working()
>
>
> Matt Lewis wrote:
> >
> >
> > Al Getz wrote:
> >
> > > I've found that Euphorias not_bits() function doesnt really work
> > > correctly.
> > >
> > > For example:
> > >
> > > atom a,x
> > > a=2
> > >
> > > x=not_bits(a)
> > >
> > > --now x equals -3, which isnt correct.
> > > --x should be equal to the 8 digit hex equivalent of -3,
> > > --right?
> >
> > Actually, it is. not_bits() works exactly as it says it does (although
> > it does seem odd):
> >
> > "Results are treated as signed numbers. They will be negative when the
> > highest-order bit is 1." -- Refman
> >
> > So the bits are correct. The quickest way to convert to unsigned (if
> > that's what you want) seems to be to have 4-bytes allocated and do a
> > poke4/peek4u after not_bits. (I just tested this vs adding 2^32 and vs
> > using xor_bits against a constant equal to 2^32-1). (These were tested
> > with Win2K, P3, 1.1GHz)
> >
> > If you printf with %x (hex formatting) or use int_to_bits, you'll see
> > that the bits are correct.
> >
> > Matt Lewis
> >
>
> Hello Matt,
>
> I have been using poke4 and peek4u to convert because it seems
> to be the most reliable way to do it with only three ops, however
> now ill have to check out Carls idea too. There is a chance that
> my argument will always be positive.
>
> I just cant help wondering why not_bits() doesnt work the way
> the other _bits functions work, or did i miss something?
> Is there any real use for getting a return value of -3 for
> not_bits(2) out there? anyone?
>
> Take care,
> Al
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
>
