organizing inputs alphabetically and numbers from big to small

[daantje]

-Is there any way to have for example 4 different inputs , and then print them alphabetically?
-Or to print (random) numbers from smallest to biggest?
-Or, if there are 100 numbers, print the smallest, or the 3 biggest?

I put those 3 questions together because I think they are comparative, please don't put too much effort in answering and  just give me a hint or something, that will get me on the right path,

many thanks already,
Daan

[rain_storm]

you could use RayFryers fairly fast z buffer sort, it can be found at Jims Repository

Heres the source code:

Code: [Select]

// By Fryer - Please Upload.
// Fast linear z-sort for large numbers of values.
//
// currently set up for 20 bit positive integers.
// sorts list by 4 bits on each pass with 6 passes but
// can be customised to suit ranges and memory.
// MUST HAVE even No. of passes and last pass MUST
// be above range for values (in this case bits 21 to 24
// are always 0)
//
// set No. of values and allocate memory
// if mx is less than 11 display sorted list
  //mx=10000
  //i = ran(65536) // random seed
  mx = 256
  dim c(15),oc(15),sort(mx*32),z(mx)

'create random list and put unsorted order into sort array
  for i=1 to mx
    z(i)=int(ran(65536))
    sort(i)=i
  next i

'initialise sort variables (only required once)
  store=mx*16+1
  retrieve=1
  final=1/16/16/16/16/16/16

'start timer
  t1$=time$

'sort
  bit=1
  c(0)=mx+1
  repeat
    for i=0 to 15 oc(i)=c(i)
      c(i)=store+mx*i next i
    for i=0 to 15 p=retrieve+mx*i
      oc=oc(i)
      while(p<oc) sort=sort(p)
        b=and(15,z(sort)*bit)
        c=c(b)
        sort(c)=sort
        c(b)=c+1
        p=p+1 wend next i
    bit=bit/16
    t=retrieve
    retrieve=store
    store=t until(bit=final)

'stop timer
  t2$=time$

'check and display results
ocs=0:scs=0
fail=0
for i=1 to mx
if mx<11 print "  "+str$(z(sort(i)))+"  "+str$(z(i))
z=z(sort(i))
ocs=ocs+z(i)
scs=scs+z(sort(i))
if i>1 then
if z<oz fail=fail+1
fi
oz=z
next i
cs=ocs-scs



i = 1
for a = 0 to (mx-16)/16
    b$ = upper$(hex$(i-1))
    while(len(b$) < 2) b$ = "0" + b$ wend
    for b = 0 to 15
        a$ = upper$(hex$(z(sort(i))))
        while(len(a$) < 4) a$ = "0" + a$ wend
        b$ = b$ + " " + a$
        i = i + 1
    next b
    print b$
next a
print "   sorted "+str$(mx)+" values"
print "   failure="+str$(fail)
print "   Checksum="+str$(cs)
//print" sorted "+str$(mx)+" values"
//print" failure="+str$(fail)+"   Checksum="+str$(cs)
//print" from "+t1$
//print"   to "+t2$

It works like this:
[1] start with the most significant bit in the number descend to the least significant
[2] for each item in the array
[3] if this bit is set move this item towards the start of the sorted array
[4] otherwise move this item towards the end of the array
[5] move on to the next item in the array and repeat steps 3,4,5
[6] shift the bit mask to the right one bit and repeat steps 2,3,4,5,6

So the first pass sorts the array into two halves
the next pass it sortes the array into quarters
then eighths, then sixteenths, etc
until you are at the least significant bit, at which point you are only looking at whether or not the number is even or odd.

This may sound slow (and it is somewhat slow) but its fast enough to be used in realtime. I have used this Z Buffer routine with success in real time 3D renderings.

[combatking0]

Using the chr$() command, you could convert the first character of a string into an ASCII reference number, and then compare the resulting numbers from your converted strings.

If the two numbers match, use chr$(mid$(string,start,end)) to get the value of the second, third, fourth, etc character until a difference is found. Be careful not to go past the end of a string though, for example, when comparing "can" and "cannot", you will need to limit the check to the length of the shortest string.

[rain_storm]

In the context of yabasic you can ignore that precaution with comparing strings of different lengths. All strings are zero terminated so asc() will return zero for the terminator as well as any queries beyond the terminator. Yet another reason why interpretive languages rock.