Math efficiency

[Mosaic]

Is it better to calc. X * 41/256 rather than X * 16/100 once the error is acceptable in Oshon?
I seem to observe better performance by using multiplication to encourage binary compatible divisions.

Edit: for integer calcs.

 

[Sceadwian]

Integer calcs? All simulation software I'm aware of using floats for everything... even perceived integers.. calculating the true error... is up to statistical sampling of the calculated data set based on pure math (not bit limited math) and the observed one.

If you saw the math the code actually used you'd probably be sick to your stomach, most floating point implementations are platform unique and will show math errors over time. Even something like Medical MRI's will show different computational results on different systems because of the platform specific methods for handling high resolution floats.

 

[Mosaic]

Integer calcs? All simulation software I'm aware of using floats for everything... even perceived integers.. .

I don't think that is correct.
Here is the code for the routines used to do the calcs.

 Word Multiplication Routine
M001:	MOVLW 0x10
	MOVWF R4L
	CLRF R0H
	CLRF R0L
M002:	RRF R3H,F
	RRF R3L,F
	BTFSS STATUS,C
	GOTO M003
	MOVF R1L,W
	ADDWF R0L,F
	MOVF R1H,W
	BTFSC STATUS,C
	INCFSZ R1H,W
	ADDWF R0H,F
M003:	RRF R0H,F
	RRF R0L,F
	RRF R2H,F
	RRF R2L,F
	DECFSZ R4L,F
	GOTO M002
	RETURN
; Word Division Routine
D001:	MOVLW 0x10
	MOVWF R3L
	CLRF R2H
	CLRF R2L
D002:	RLF R0H,W
	RLF R2L,F
	RLF R2H,F
	MOVF R1L,W
	SUBWF R2L,F
	MOVF R1H,W
	BTFSS STATUS,C
	INCFSZ R1H,W
	SUBWF R2H,F
	BTFSC STATUS,C
	GOTO D003
	MOVF R1L,W
	ADDWF R2L,F
	MOVF R1H,W
	BTFSC STATUS,C
	INCFSZ R1H,W
	ADDWF R2H,F
	BCF STATUS,C
D003:	RLF R0L,F
	RLF R0H,F
	DECFSZ R3L,F
	GOTO D002
	RETURN
; Word ShiftRight Routine
SR01:	BCF STATUS,C
	RRF R0H,F
	RRF R0L,F
SR00:	ADDLW 0xFF
	BTFSC STATUS,C
	GOTO SR01
	RETURN

 

[jpanhalt]

I haven't used Oshon, but using a PIC and MPLab with Assembly, it was faster to set up the problem to allow integer division like you suggest. I have read "tips and tricks" that suggest the same approach to avoid having to use floating point for calculations.

John

 

[Sceadwian]

My mistake, for some reason I was thinking you were talking about a simulator that used spice.

 

[Ian Rogers]

Is it better to calc. X * 41/256 rather than X * 16/100 once the error is acceptable in Oshon?
I seem to observe better performance by using multiplication to encourage binary compatible divisions.

Edit: for integer calcs.

I've read this a few times now.....I don't see your point.... Are we talking about fixed point math in general....The code produced by Vladimir is a standard shift algorithm, the same code is used with both those equations.... why would one be better than the other... The first using int's and the second would be using int's aswell.

 

[Sceadwian]

Because the 41/256 the divisor is a bit perfect binary number, it will always shift fewer times than then 16/100 because 100 is not a perfect binary number. So using perfect binary numbers will result in much faster executing code if properly done. There is always some grey area in the speed of execution of code vs accuracy.

This is why I always use 16 or 32 pieces on the counting scale at work, because there can't be an extra math error introduced from a set of numbers that would introduce a repeating error because I wasn't using the right system.

 

[Mosaic]

makes sense to me....the math was part of a frequently called (120Hz) closed loop control that is smoother when using the binary divisions.

The lessons learned in asm can make for more efficient programming in the higher level languages.

 

[Ian Rogers]

With the shifting of multiplication ALL sixteen digits are shifted in each case. Just because they are divisions of 8 doesn't speed it up or make it precise..

The only time "binary divison / multiplication" comes into its own, is if you left or right shift.. ie.. 4100>>8 IS faster than 4100 / 256, but Vladimir doesn't check the number before processing.. They are all treated as a variable..

 

[Mosaic]

So if i have a x/256 I should use x>>8 ?

 

[Ian Rogers]

So if i have a x/256 I should use x>>8 ?

A lot quicker.. x = shiftright(x,8), in Oshonsoft...