segmenting integers

Community Forums/General Help/segmenting integers

RifRaf

(Posted 2009) [#1]

First off, I am sorry if the topic is not well labeled. What I want to do is take a large integer for example 3471 I want to get from it the integer 34 and seperately the integer 71 without converting the original integer into a string. For my purposes the integer will always be in the 1000's , or 4 digits, and I will always want the Numbers split into two integers from the first two Digits and the second two.

Again I can do this by converting to a string.. getting Right$ and Left$ then using those values into an INT again. But its way to slow.

Any insight would be much appreciated.

Oddball

(Posted 2009) [#2]

Using BMax?

Floor(3471*0.01)

3471 Mod 100

plash

(Posted 2009) [#3]

How many operations are you doing?

Me and Ryan did a whole screen buffer using strings and slicing (DOS-like character screen buffer, it was about 30x50).

How fast does this technique work, in place of Right and Left?:

SuperStrict

Framework brl.blitz
Import brl.standardio

Local number:Int = 3471
Local num_left:Int, num_right:Int
Local num_str:String

num_str = String(number)
num_left = Int(num_str[0..2])
num_right = Int(num_str[2..4])

Print("Left: " + num_left + "; Right: " + num_right)

EDIT: Oh, yeah you didn't mention which language you're using..

Floyd

(Posted 2009) [#4]

n Mod 100 keeps the last two digits of an integer while n/100 throws them away.

RifRaf

(Posted 2009) [#5]

Using Blitz3D, thank you Oddbal. works great. And its being used in a mesh based particle engine to dirive two values from one field, and is used per particle per loop.

PGF	(Posted 2009) [#6]

'... per particle per loop'

Unless there is a good reason for this, you should keep separate fields and avoid the overhead.

RifRaf

(Posted 2009) [#7]

Mesh particles require far fewer than quad/tri texture particles to acheive large effects.. With my particle demo of the system I can litterally fill the screen with effects so that the scene is barely viewable because of them and still only have about 300 to 700 particles out there at any one time.

The cost is about 2ms per 1000 particles to do this on my machine (wich is ancient). So I may add the fields, but its a good thing to know anyhow.

Plash, to answer your question. The cost for 1000 particles using left and right is about 30ms on my machine.

Ill pop the particle lib on the code archives when its a little more robust. Right now I dont have anything fancy like attactors or repellers.

However it can attach to a parent (gun, bullet ect) and will self terminate if the parent dissapears, and emitters handle their own sounds on creation,and death, as well as can link creation of new emitters on creation and death, so linking effects for more elaborate visuals is possible.

plash

(Posted 2009) [#8]

Plash, to answer your question. The cost for 1000 particles using left and right is about 30ms on my machine.

Yeah.. you don't have slices, but the overhead of the function calls.