Snippet Challenge 1 : techenclave to TE

This is meant to be a fun programming exercise
  • Programming Language no-bar
  • Coding-Style no-bar
  • Lines of code no-bar

You mission
A function / program that takes a single word as an input, and converts all the t's and the e's to caps

eg :
"techenclave" -> TEchEnclavE , "tandoori" -> Tandoori , "the" -> ThE

hack! 8 )
 
Code:
char * convert(char *s)

{

	char *t=s;

	while( *s !='\0' )

	{

		if( *s=='t')

		*s=='T';

		if( *s=='e')

		*s=='E';

		s++;

	}

	return(t);

}

spare small mistakes :p, this is basic C . Assuming valid char * passed to function and having '\0' in the end .
 
I'm not used to these languages, but i wonder if the case conversion can be speeded up by bitwise ORing the values with 20 (hex)

/the only language they taught me in college was ASM. once got dirty looks for using a right shift instead of dividing by 2 :lol:(again to speed stuff up)
 
I know this sucks but still :p

<?php

function replace($str) {

$str = str_replace("e","E",$str);

$str = str_replace("t","T",$str);

echo $str;

}

?>
 
greenhorn said:
I'm not used to these languages, but i wonder if the case conversion can be speeded up by bitwise ORing the values with 20 (hex)

/the only language they taught me in college was ASM. once got dirty looks for using a left shift instead of dividing by 2 :lol:(again to speed stuff up)

1. The compiler is already doing that for you.
2. The compiler will write much more efficient ASM than ASM written by hand(few exceptions apply, as always).

So your approach is funky and is definitely applicable here, in a programming skill showcase but it's not really practical.
 
here's my input in java

Code:
if(String.contains("t") || String.contains("e"))

{

		String=String.replace('t','T');

		String=String.replace('e','E');

}
 
greenhorn said:
I'm not used to these languages, but i wonder if the case conversion can be speeded up by bitwise ORing the values with 20 (hex)

/the only language they taught me in college was ASM. once got dirty looks for using a left shift instead of dividing by 2 :lol:(again to speed stuff up)
Actually left shift MULTIPLIES by 2. Right shift divides. DUDE you should know that!!

Even a poor S3 Mech. Engg. like me knows it :D.
 
My Poor Programming Knowledge.. Just try :p

Code:
<?php

$search = array('t','e');

$replace = array('T','E');

$name = techenclave

echo str_replace($search, $replace, $name);

?>

101%, that's wrong one :D
 
sahilm said:
1. The compiler is already doing that for you.

we didnt have any compilers to do it.We were keying in hex codes directly into an 8086 :p

2. The compiler will write much more efficient ASM than ASM written by hand(few exceptions apply, as always).

some discussion here :p Smart Software: Human vs Computer

So your approach is funky and is definitely applicable here, in a programming skill showcase but it's not really practical.

Yeah, i guess its a bit off topic, but going bitwise is always a good idea if you really want to go all the way to tune code :)
 
Here in mine in C/C++;
Code:
char* fun1(char a[])
{
     
     for(int i=0;a[i]!='\0';i++)
     {
             
             if(a[i]=='t'||a[i]=='e')
             {
                 a[i]=a[i]-32;
             }
     
     }
     return a;
}

@bosky101 if you weren't 24 I would have guessed that you just found out an innovative way to get your homework questions done :p
 
Assembler ( Assemble using MASM from masm32.com ). Its Intel x86 ASM. I am a little rusty. Been a long time since I worked on ASM. Anyway, here is a try:

Code:
Replace_TE proc str:DWORD

xor eax,eax

xor ecx,ecx

mov esi, str

mov edi, esi

loop:

 scasb ; Move one byte pointed by ESI into AL

 cmp al,'t'

 je upper

 cmp al,'e'

 je upper

 cmp al,0

 je end

continue:

 stosb ; Store one byte from AL into address pointed by EDI

 jmp loop

upper:

 sub al,32; Convert to upper case

 jmp continue

end:

 ret esi

EndP

That probably has a few errors. I don't have the patience to download the assembler and test compile it. :) . It will probably not be even a kB when converted to binary. I also have relied on MASM to produce to stack frame for the function :) .

BTW, I don't think any compiler can produce code which is that optimized.

If you say that a compiler can produce smaller code, you haven't tried debugging a windows-program made in C or C++ in a debugger like Ollydbg. If the program is made in assembler, the code is EXACTLY the same as we typed in. The newer assemblers, like the one I linked to even has high-level constructs like IF,ELSE or WHILE implemented using macros, which produce almost the same code as we would have if we had typed it in.

When you make a program in assembler, even 50kB to 100kB is a LARGE program.

Of course, using C and other HLLs have their advantages like being able to compile on different platforms, easy to understand logic etc.

If any of you guys are interested check out: The MASM Forum - Index .
 
junkiedogg said:
BTW, I don't think any compiler can produce code which is that optimized.

If you say that a compiler can produce smaller code, you haven't tried debugging a windows-program made in C or C++ in a debugger like Ollydbg. If the program is made in assembler, the code is EXACTLY the same as we typed in.
1. If you embed assembly in a C program, the compiler is not going to touch it.
2. I'm talking about C code parsed into assembly automatically by the compiler.
3. The compiler generates very obfuscated object code but it's not meant to be read by a human.
4. Compiler generated object code is far far more optimized than any human can write(barring a few exceptions).
5. As written in the above line, when a programmer encounters such an exception(where his code will be much more efficient than the compiler) and is willing to sacrifice readability, he embeds his own ASM.
6. An example of such a case would be the linux kernel. Almost all of the kernel is written in C, except for a few(relatively) lines of ASM.
 
sahilm said:
1. If you embed assembly in a C program, the compiler is not going to touch it.
2. I'm talking about C code parsed into assembly automatically by the compiler.
3. The compiler generates very obfuscated object code but it's not meant to be read by a human.
4. Compiler generated object code is far far more optimized than any human can write(barring a few exceptions).
5. As written in the above line, when a programmer encounters such an exception(where his code will be much more efficient than the compiler) and is willing to sacrifice readability, he embeds his own ASM.
6. An example of such a case would be the linux kernel. Almost all of the kernel is written in C, except for a few(relatively) lines of ASM.

We can argue all day and still not come to a conclusion :) .

The code written by a coder with enough knowledge about a platform will ALWAYS be better than one produced by a compiler.

If you check the code generated by a compiler for a simple IF-ELSE or e a FOR-loop .. or maybe a little complex floating point arithmetic.

The number of lines of assembler generated by the compiler ( yes the binary EXE generated by ANY compiler actually contains opcodes for individual assembly instructions. It maybe obfuscated .. if necessary using a packer but still IT IS ASSEMBLER converted directly to binary opcodes. Its the assembler that runs directly on the processor. ) will be a LOT more than what we would get when done manually. I have myself seen many examples of this.

If you look at my code example, each line will be converted to a single binary opcode of 2-6 bytes depending on the instruction.

If you take any of the other .. say C examples, for a simple IF you will be amazed how much code a compiler produces. There will be lots of irrelevant code and in the middle of all that there will be a small CMP instruction, whereas I got away with just the CMP.

I know .. in the real world, using assembly is not very practical, where platform portability etc. matters.

But it IS possible to write readable assembler and no machine-generated code will match one that was written by a human coder.
 
a high level language is just easier to write. thats why they ( and their compilers) were made in the first place :p

but Assembly is still alive and kicking ( though not for the faint hearted :p) , and used in cases where performance is absolutely critical

One time was in college, where we had a slow microcontroller and a slower DAC . the dac had to wait for 40 or so clocks after you selected the input for the signal to stabilize so that you could do a read. and then the processing took an equivalent amount of time, in the end, it was just too slow. then we figured, instead of doing the processing after the read, we decided to do it during the wait period :p Got more than 50% increase in the throughput. Some optimizations, a machine cant do :D

I've seen it at the other end too. Some of the stuff I've had to deal with at work involves assembly written for mainframes, rather than COBOL which they usually use

in between, for languages which most people are familiar with - C++, C , java etc and X86 processors , i guess it may not make a difference
 
sahilm said:
4. Compiler generated object code is far far more optimized than any human can write(barring a few exceptions).

No compiler in general use these days is intelligent enough to understand what your high level code is trying to do and optimize it.

The compiler is just built to analyze for small commonly occurring patterns in code and replace them with alternative versions which work more efficiently. Its just a dumb but useful operation designed to save you from the task of making small optimizations. That is to say, its just a facility provided to help you avoid the small and mundane tweaks while writing code.

True efficiency can only be achieved when the person or program doing it understands what you are trying to achieve in the first place.

If you write inefficient code in the first place, the compiler will not magically translate it into the most efficient code. I would go as far as to say that an avg programmer is more efficient at tuning his code than the most sophisticated optimizing compiler is.
 
Anyway here's my version in simple C code.

Code:
void Convert(char *str)

{

    while (*str) *str++ = (*str == 't' || *str == 'e') ? *str ^ 0x20 : *str;

}
 
sahilm said:
Where did that come from?

I mean to say that the scope of the compiler generated optimizations is limited. It will do small things like removing an unused variable, or self assignment or changing or rearranging small code fragments for better execution speed.

It does not fully understand the code or something to be able to drastically optimize code. If you start with a poorly written logic, the compiler will not magically translate it into efficient code. The optimizations done if any are negligible compared to the ones you can do yourself. Its just an aid, not a replacement for programmer made optimizations.
 
Back
Top