When dumping out information to (mono-spaced, line-printed) reports, would it get all your numbers to right align? So you get:

   1234
9876543
  51230

and not

1234
9876543
51230

(Reply) (Thread)

It's the obvious thing. Dunno about efficiency, wot Tim arsked abaht.
But if r-align is your first shot, you need a new name for l-align.
I think Tim should benchmark the two ops and see.

(Reply) (Parent) (Thread)

The only thing I could think of re: efficiency is that - assuming you can do everything with MOVE and don't need to MOVEL - it strips out a layer of reformating when you dump out the report. Which, thousands of numbers, hundreds of pages, could be a saving when your computing power is measured in how much coal it consumes.

(Reply) (Parent) (Thread)

You'd use numeric fields for those though. This is just strings.

(Reply) (Parent) (Thread)

You're implying the char*N fields are actually arrays of chars, which though common isn't always the case. Do you know that they are?
If they're statically sized, I don't see that there'd be any necessary inherent performance difference.

(Reply) (Thread)

Do you use fields to store integers or is there a separate type for that? If you had an integer in a field, maybe using the default MOVE behaviour makes it easier to tell if a digit represents tens, hundreds or whatever?

(Reply) (Thread)

ie what caramel_betty said.

(Reply) (Parent) (Thread)

It's a different type for numbers. This is just strings.

(Reply) (Parent) (Thread)

It must to be to make things more human-readable without extra processing.

(Reply) (Parent) (Thread)

I have a (very) vague recollection that comparing a number to zero is quicker than comparing it anything else.

If that is true, a loop counting down to move the corresponding bytes/characters is theoretically quicker than a loop counting up - i.e. it might be more efficicent to copy from right to left.

Of course, this may well be complete sh!te.

(Reply) (Thread)

The loop could count down in both cases, you just change the formula for choosing where in the array to stick a character.
Where's hoiho? He knows what goes on inside these languages.
Tim, are you using an implicit cast from Int to Char here? THAT might make a diff, if you do it with modulo arith, you get the right most chars out first.

(Reply) (Parent) (Thread)

Nope, this is all strings.

(Reply) (Parent) (Thread)

Could be a big/little-endian thing?

(Reply) (Thread)

The first thing that occurs to me is filling in zeros. Someone or some application might come along and fill in zeros for the blank spaces. You would want the extra zeros to be on the left rather than the right, so as not to change the values.

(Reply) (Thread)

Yeah, now I see I totally misunderstood what you were asking. It must be something to do with the architecture of the machines the language was originally designed for.

(Reply) (Parent) (Thread)

My guess would be formatting, too - specifically currency amounts to two decimal places so the decimal point lines up.

(Reply) (Thread)

I refer the honourable gentleman to my earlier reply.

(Reply) (Parent) (Thread)

Could it be that the language designers made the numeric fields move from the right for the reasons the others have mentioned, and then made strings work the same way for consistency, because they thought they might be used as base-(number of characters in character set) numbers, or because they were used to moving from the right and didn't think about it very hard?

(Reply) (Thread)