Just read the tutorials here-
http://www.vedicmaths.org/Group%20Files/tutorial/tutorial.asp

And take a look at this too.
http://www.magicalmethods.com/

You can do calculations shit fast with vedic maths.
This algo applied in computer code can make math go real fast especiallin case of long integers.

You can do calculations as big as this - 28323 X 53246 in 15 secs with your mind. Think how fast it will be on a comp.

And oh yea all mulitiplication is done in a sinlge step in Vedic Maths.
Posted on 2002-12-18 05:44:35 by clippy
Sorry to disagree with you.

Vedic maths are excellent for some mental calculations and may seem fast when applicable. However, none of them is really a single step process when you consider it from an algo point of view.

Let's take the square of a number ending with 5 as an example. Mentally, it is easy to disregard the ending 5. An algo would have to divide by 10 to disregard that 5. Then, the remaining number has to be increased by one (easy mentally but still an inc or add in the algo) before doing the multiplication. That result must then be multiplied by 100 (again easy mentally) before writing (i.e. adding) the terminating 25!

I strongly believe that an algo such as:
mul eax,eax
would be very difficult to improve on.

Raymond
Posted on 2002-12-18 19:08:12 by Raymond
gladiator:
Raymond is right, your brain is doing a bunch of little stuff (remember that your brain is composed of billions of parallel processors).

Raymond:
Microchip has with their PIC18Cxxx line that has a single step hardware 8x8 multiply.
Posted on 2002-12-19 00:59:56 by eet_1024
I think gladiator is partly right. I have been developing cpus in my spare time (only drawing the schematics), and multiplication can be sometimes faster if using vedic maths. The process of multiplication of 8-bit integers consists of 7 shl & 8 add -s. Vedic maths can speedup twice the mult. only of 8-bit integers, making the algo: converting to BCD, do vedic , convert to binary. The BCD convertion and manipulation is the tricky part, the area where brain beats cpu.
Posted on 2002-12-21 22:34:33 by Ultrano
hold yer horses!!! :grin:

how about number strings? by applying vedic math, you don't need to convert the strings to decimal then do the operation then convert it back to string...

just an idea that came up, dunno if it works... :grin:
Posted on 2002-12-21 23:56:39 by stryker
.DATA


[color=blue]num DB 0, 0, 0, 0, 0, "700"[/color]
base DB 39h, 39h, 39h, 39h, 39h, 39h, 39h, 3Ah
final DB 30h, 30h, 30h, 30h, 30h, 30h, 30h, 30h

.DATA?

buffer DB 8 DUP(?)

.CODE

start:

movq MM0, QWORD PTR [base]
movq MM1, QWORD PTR [num]
psubb MM0, MM1
movq MM1, QWORD PTR [final]
paddb MM0, MM1
movq QWORD PTR [buffer], MM0

mov ecx, 7

__carry:

test ecx, ecx
jz __exit
cmp BYTE PTR [buffer+ecx], 3Ah
jne __skip
mov BYTE PTR [buffer+ecx], 30h
add BYTE PTR [buffer+ecx-1], 1

__skip:

sub ecx, 1
jmp __carry

__exit:

invoke MessageBox, 0, OFFSET [buffer+5], 0, 0
:grin:

Too sleepy to explain... I'm sick, feeling nauseated and dizzy... so I have to rest. :-X :-X :-X

REAL MEN DOESN'T NEED EXPLANATIONS. :grin:
Posted on 2002-12-22 03:18:59 by stryker

I think that the era of no comments is finally finished.

Real Men want lotsa misleading comments in the code. :grin:

For example:


CALL FormatHardDisk ; this prints a string. Warning: DO NOT REMOVE IT!!!!
CALL PrintMessage ; this creates the DirectSound object
Posted on 2002-12-22 03:28:44 by Maverick



CALL PrintMessage ; this creates the DirectSound object


Aha! Thats why I've never been able to make the DSound example work, I thought I had to play with COM... :alright:
Posted on 2002-12-22 04:33:53 by scientica

REAL MEN DOESN'T NEED EXPLANATIONS. :grin:


Why is that? :grin:
Posted on 2002-12-22 10:37:33 by jademtech
I'm applying the first tutorial from the link above: ALL FROM 9 AND THE LAST FROM 10
[size=9].686

.MMX
.MODEL FLAT, STDCALL
OPTION SCOPED
OPTION CASEMAP:NONE

INCLUDE \dev\include\windows.inc
INCLUDE \dev\include\kernel32.inc
INCLUDELIB \dev\lib\kernel32.lib
INCLUDE \dev\include\user32.inc
INCLUDELIB \dev\lib\user32.lib
INCLUDE \dev\include\masm32.inc
INCLUDELIB \dev\lib\masm32.lib


.DATA

;the padding is important, since we are using MMX instructions to calculate
;for the math operation and MOVQ requires a QWORD size value.
;
; # padding = 8 - strlen(stringnumber)
;
; E.G.: In our code below
;
; |-> 220 is 3 characters
; # padding = 8 - 3
; # padding = 5
;
; the padding value can be any value

; P A D D I N G
num DB 0, 0, 0, 0, 0, "220"


;VEDIC MATH: ALL FROM 9 AND THE LAST FROM 10
;
;Remember the values representing the string numbers: 1 == 30h ... 9 == 39h, 10(which is actually a ':' ) == 3Ah

from9_10 DB 39h, 39h, 39h, 39h, 39h, 39h, 39h, 3Ah
backtostr DB 30h, 30h, 30h, 30h, 30h, 30h, 30h, 30h

.DATA?

buffer DB 8 DUP(?)


.CODE

start:

;MM0 = 3A39393939393939

movq MM0, QWORD PTR [from9_10]

; 0 2 2 == 220
;MM1 = 3032320000000000
; |-> Padding

movq MM1, QWORD PTR [num]

;MM0 = 3A39393939393939
;MM1 = 3032320000000000
; ----------------
;MM0 = 0A07073939393939

psubb MM0, MM1

;MM1 = 3030303030303030

movq MM1, QWORD PTR [backtostr]

;MM0 = 0A07073939393939
;MM1 = 3030303030303030
; ----------------
;MM0 = 3A37376969696969

paddb MM0, MM1

; 7 7 : or 10(we'll just treat it as 10)
;buffer = 696969696937373A

movq QWORD PTR [buffer], MM0

;if the last digit == 3Ah then there should be a carry

cmp BYTE PTR [buffer+7], 3Ah
jne __exit

;set the last digit to '0'

mov BYTE PTR [buffer+7], 30h

;add 1 to the next lsd (least significant digit)

add BYTE PTR [buffer+6], 1

;check if there are other values that needs a carry

mov ecx, 6

__carry:

jz __exit
cmp BYTE PTR [buffer+ecx], 3Ah
jne __skip
mov BYTE PTR [buffer+ecx], 30h
add BYTE PTR [buffer+ecx-1], 1

__skip:

sub ecx, 1
jmp __carry

__exit:

;buffer + # padding

invoke MessageBox, 0, OFFSET [buffer+5], 0, 0
invoke ExitProcess, 0

end start[/size]
I'm not claiming this is a faster method but it's fun applying the techniques... :)




Ya! happy now with the comments?... :grin:
Posted on 2002-12-22 11:52:41 by stryker

Ya! happy now with the comments?... :grin:


;No, but I haven't tested the code you posted so I can't comment it's functionally or speed, but are you happy with this comment or shall I... ? :stupid:
Posted on 2002-12-22 15:24:30 by scientica
but are you happy with this comment or shall I... ?
huh? :grin:

much better
movq    MM0, QWORD PTR [from9_10]

movq MM1, QWORD PTR [num]
psubb MM0, MM1
movq MM1, QWORD PTR [backtostr]
paddb MM0, MM1
movq QWORD PTR [buffer], MM0
sub ecx, ecx
add ecx, 7
__carry:
jz __exit
cmp BYTE PTR [buffer+ecx], 3Ah
jne __exit
mov BYTE PTR [buffer+ecx], 30h
add BYTE PTR [buffer+ecx-1], 1
sub ecx, 1
jmp __carry
__exit:
there's only 1 gripe I have on this kind of a method... -> Try something < 1000 but >= 900... :)

but it's still fun... :)
Posted on 2002-12-22 16:35:42 by stryker
:stupid: :alright:
Posted on 2002-12-22 16:54:32 by scientica