### Bookstore

 Computer Math and Games in Pascal (preview) Lazarus Handbook

### Author Topic: Mathematical question  (Read 3516 times)

• Hero Member
• Posts: 14619
• Sensorship about opinions does not belong here.
##### Re: Mathematical question
« Reply #30 on: February 28, 2024, 06:36:00 pm »
He simply means that bits are bits, Not flags.
bitrate is always calculated like this:sample rate * bitdepth * number of channels.

#### Fibonacci

• Sr. Member
• Posts: 438
##### Re: Mathematical question
« Reply #31 on: February 28, 2024, 06:36:54 pm »
these bitwise operations, they are wrong.

Just look at the second screenshot. "-1" manipulated as Integer vs Multi_Int_XV. Integer is OK, Multi_Int_XV produces wrong result.

Edit: Sorry, I forgot to mention I commented out the exception code in the unit Just that disallowing bitwise operations on negative values is wrong. It shouldnt be checked at all if its negative or positive.

Possible solutions:
1) Dont store "NEGATIVE" boolean flag, instead store "SIGNED" flag
2) Separate types for signed and unsigned
« Last Edit: February 29, 2024, 01:10:57 am by Fibonacci »

#### paule32

• Full Member
• Posts: 233
##### Re: Mathematical question
« Reply #32 on: February 28, 2024, 06:43:18 pm »
but Bit's can be Flag's:

o o o o o o o o  <--- Flag's (all set)  => 255
7 6 5 4 3 2 1 0  <--- Bit's (Position)

=>

o       o o o    o  <--- Flag's (not all set) - can be use for: (Carry Flag, ..)
7 6 5 4 3 2 1 0  <--- Bit's

• Full Member
• Posts: 199
##### Re: Mathematical question
« Reply #33 on: March 01, 2024, 10:46:42 am »
Just that disallowing bitwise operations on negative values is wrong. It shouldnt be checked at all if its negative or positive.
I still don't understand what the problem is.
To make it work, the programmer just has to do ABS on the value, like this:
Code: Pascal  [Select][+][-]
1. V:= Abs(W) << 1;
However, if the programmer inadvertently tries to do a bitwise operation on a negative value, and would want that to be flagged as invalid, then what I'm doing is correct.
If I "fix" the programmer's error, by doing an implicit ABS, that might not be what the programmer wanted, and could cause problems later like undiscovered bugs.
The way I am doing it means the programmer has control.

#### Fibonacci

• Sr. Member
• Posts: 438
##### Re: Mathematical question
« Reply #34 on: March 01, 2024, 11:00:04 am »
So if I want to change 1 bit, you suggest to first call Abs() on the value?

#### paule32

• Full Member
• Posts: 233
##### Re: Mathematical question
« Reply #35 on: March 01, 2024, 12:19:07 pm »
for usually, I use Assembly Code for that.
You can then do:

asm
mov al, 0b   ; set first (0) bit to AL register
mov al, 1b   ; set first (1) bit to AL register

mov al, 10b ; set second bit (1) to AL register, and first bit (0) <-- remark's
end;

remarks:
00 = 0
01 = 1
10 = 2

so:
asm mov al, 10b  end;  is the same as:
asm mov al, 0x02 end;

you can check the flag with:  JZ = Jump Zero (0), ...

asm
@start:
mov al, 00b
jz @zero
; do something, if not zero
@zero:
; do something else, if AL is zero
end;

• Hero Member
• Posts: 14619
• Sensorship about opinions does not belong here.
##### Re: Mathematical question
« Reply #36 on: March 01, 2024, 12:25:21 pm »
That is fine on 8 bit computers but is slow on anything else.
bitrate is always calculated like this:sample rate * bitdepth * number of channels.

#### paule32

• Full Member
• Posts: 233
##### Re: Mathematical question
« Reply #37 on: March 01, 2024, 12:33:49 pm »
This was only an Example.
It give even more Menomic's like:

modern IBM compatible PC's have these old Instruction Set's for backward compatible
with more or lesser complex other Menomic's.

So, modern PC's are indeed very slow - in Context of RISC CPU's.
Because:
AL/AH will be store into AX
AX   will be store into EAX, and
EAX will be store into RAX

This have to do with the Bandwidth of the BUS System.
« Last Edit: March 01, 2024, 12:37:21 pm by paule32 »

#### Fibonacci

• Sr. Member
• Posts: 438
##### Re: Mathematical question
« Reply #38 on: March 01, 2024, 12:49:18 pm »
@paule32: We are talking about Multi_Int_XV type here, not simple integers.

11111111111111111111111111111111 <- this is Integer(-1)
00000000000000000000000000000001 <- this is Abs(Integer(-1))

So should I call Abs() before doing bitwise operations? I guess not.

If I want to change the sign, I can do it like this:
int := int xor (1 shl 31)

If the type is not Integer but Multi_Int_XV, I cant do this because "you cant do bitwise operations on negative values". Of course if I first call Abs() on the value, it will work, but the value will be completely wrong.

@ad1mt: Again, you can know the real decimal value of the "bits" only if you know how to treat the bits, as signed or not. Currently you store a boolean flag to tell if this value is "negative" or not. Instead, you should store if its SIGNED or not. Bitwise operations operate on bits, the decimal value doesnt matter, if negative, above 100, equal to 33 or whatever.

I didnt read all the code in your 15k LOC unit, I dont know how it actually works. The "decimal value" when returned as String should be built knowing if the expected value is signed or unsigned, not if its negative or not.

Also I dont know why changing 1 bit (the most significant bit in 32bit value) causes "overflow" exception when converting it back to 4 byte Integer.

Code: Pascal  [Select][+][-]
1. var
2.   i: integer;
3.   m: Multi_Int_XV;
4. begin
5.   i := 1;
6.   m := i; // 4 bytes
7.   m := m xor (1 shl 31); // still 4 bytes
8.   i := m; // overflow exception, but its still 4 bytes

If I touch the "sign bit", its overflow.

#### paule32

• Full Member
• Posts: 233
##### Re: Mathematical question
« Reply #39 on: March 01, 2024, 01:00:56 pm »
For Decision's, on negative or positive Number's, I use a Remainder carry Flag.
So, in these there, you have three Options with two Bit's

if carry = 00b then // do positive Action's for unsigned Value's
if carry = 01b then // do negative Action's for signed Value's
if carry = 10b then // abs(carry)  // then carry is always "unsigned"

All is depend on you Application Logic, and Goal.
With the Option's above, you ship around the Limit's of some Type's.

So, you can have a the Size of a signed DWORD like -4 GB, and +4 GB instead only: -2 GB, and +2GB.

Okay, this have a little payload.
But this was only a thinking over Idea from me ...

• Hero Member
• Posts: 14619
• Sensorship about opinions does not belong here.
##### Re: Mathematical question
« Reply #40 on: March 01, 2024, 01:03:53 pm »
This have to do with the Bandwidth of the BUS System.
No it has to do with the native width of the processor.
There are efficient instructions, though, on e.g. Intel, like movb and family, to handle byte sized instructions.
You should use those.
bitrate is always calculated like this:sample rate * bitdepth * number of channels.

#### paule32

• Full Member
• Posts: 233
##### Re: Mathematical question
« Reply #41 on: March 01, 2024, 01:09:23 pm »
I am not a Friend of AT&T Assembly Style like:
movb

I loved, and prefer Intel Assembly Style like:
mov byte ptr

mov.b sounds like Motorolla 68k Assembly for me

#### marcov

• Hero Member
• Posts: 11528
• FPC developer.
##### Re: Mathematical question
« Reply #42 on: March 01, 2024, 03:47:09 pm »
you can check the flag with:  JZ = Jump Zero (0), ...

asm
@start:
mov al, 00b
jz @zero

Afaik mov doesn't affect the flags, so this code doesn't look so good.

Binary notation for literals is a % in FreePascal, hex is \$ and octal is &, all prefixes and including its assembler syntax.

#### paule32

• Full Member
• Posts: 233
##### Re: Mathematical question
« Reply #43 on: March 01, 2024, 05:09:57 pm »
you right.
To correct this:

mov al, 0
cmp al, 0
jz @zero
...

Intel nasm differs from AT&T gas:

Intel:  mov eax, 1        (dst <- src)
AT&T: movl \$1, %eax  (src -> dst)

My fault - sorry.

inline: movl \$1, %%eax

• Full Member
• Posts: 199
##### Re: Mathematical question
« Reply #44 on: March 02, 2024, 06:31:18 pm »
I dont know why changing 1 bit (the most significant bit in 32bit value) causes "overflow" exception when converting it back to 4 byte Integer.

Code: Pascal  [Select][+][-]
1. var
2.   i: integer;
3.   m: Multi_Int_XV;
4. begin
5.   i := 1;
6.   m := i; // 4 bytes
7.   m := m xor (1 shl 31); // still 4 bytes
8.   i := m; // overflow exception, but its still 4 bytes
I was worried that my code might have a bug; and I always welcome bug reports.
So I ran your code, to see what was going on.
After the XOR operation, m = 2147483649
32-bit integer type is signed, and can only accept values between -2,147,483,648 and 2,147,483,647
2147483649 is outside its range, so assigning m to i correctly causes overflow.
If you declare i to be unsigned integer (aka longword, aka uint32), then it works ok, because it can accept values from 0 to 4294967295