Math with string, but why?
-
You haven't met .net yet, have you? :sigh:
PIEBALDconsult wrote:
You haven't met .net yet, have you?
Meaning? Just to be clear...converting a string to a numeric, multiplying by 10 and then converting back to a string is going to be slower than appending to a string. In all of the languages that I know, including .Net.
-
harold aptroot wrote:
Yes.. but the idea was not to use strings in the first place.
Ah...but of course that wasn't the scenario presented. And not presumable in these days of prevelant GUIs and xml.
-
The scenario is intended to be the same one as in the earlier paragraphs of my post: math with strings for no good reason.
-
PIEBALDconsult wrote:
You haven't met .net yet, have you?
Meaning? Just to be clear...converting a string to a numeric, multiplying by 10 and then converting back to a string is going to be slower than appending to a string. In all of the languages that I know, including .Net.
Yes, but the appendification might not be as quick as just the multiplying by ten.
-
No offense, but I wouldn't say "too lazy to port properly" is a valid excuse to keep that kind of code around.. But it's not as bad as doing it out of lack of understanding - at least there was some actual reason.
There's a lot of code in the DEA algorithm to set bits from seemingly random bits in a source 64 bit block. Thinking about it the string binary might actually be more efficient that bitwise binary. Setting Bit 53 to the value of bit 17 in string binary is a simple byte to byte copy. In Bitwise operations its simple enough to specify in C by what might the assembly code look like? It would have to load the word containing the source bit. Do a TST if the bit is set or not. Branch to separate setting or unsetting logic. Load the destination word. OR the destination bit if setting, AND the compliment of the bit if unsetting. That has got to end up being more intructions than a simple byte to byte transfer. I think that was the whole point of the DEA algorithm, it was to computationally inefficient and time consuming.
-
There's a lot of code in the DEA algorithm to set bits from seemingly random bits in a source 64 bit block. Thinking about it the string binary might actually be more efficient that bitwise binary. Setting Bit 53 to the value of bit 17 in string binary is a simple byte to byte copy. In Bitwise operations its simple enough to specify in C by what might the assembly code look like? It would have to load the word containing the source bit. Do a TST if the bit is set or not. Branch to separate setting or unsetting logic. Load the destination word. OR the destination bit if setting, AND the compliment of the bit if unsetting. That has got to end up being more intructions than a simple byte to byte transfer. I think that was the whole point of the DEA algorithm, it was to computationally inefficient and time consuming.
Now that's a more valid reason. You wouldn't do it with a branch of course, but yes it still kind of sucks. This is how I might write it:
; rcx = destination, rdx = source, for no reason
btr rcx,53
and edx,0x00020000
shl rdx,36
or rcx,rdxSo 3 cycles, not so bad. Still, using strings would be faster for this step.
-
I know what you mean, it does seem that some educators need a swift kick up the bottom. But then, they don't seem to teach the basics of computing any more - it's as if the computer is an irrelevant part of computing! Start 'em with assembler - that'll learn 'em! The one which annoys me most is SQL queries built by string concatenation rather than teaching the little buggers about parametrized queries from day one. Stupid, dangerous, and time-wasting when they try to add binary data to the table...
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
-
Nah - machine code is for people who can cope with front panel switches, and My PC doesn't have those. :-D I could probably still key in the bootstrap loader for a Data General Nova in my sleep - I did that enough times over the years!
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
-
Yes, but the appendification might not be as quick as just the multiplying by ten.
PIEBALDconsult wrote:
Yes, but the appendification might not be as quick as just the multiplying by ten.
I am hoping that you mean that if you start with a numeric, rather than starting with a string. That however isn't what I was comparing it to. If so then I would expect that all languages that the numeric multiplication (starting with a numeric) is faster. By quite a bit.
-
PIEBALDconsult wrote:
Yes, but the appendification might not be as quick as just the multiplying by ten.
I am hoping that you mean that if you start with a numeric, rather than starting with a string. That however isn't what I was comparing it to. If so then I would expect that all languages that the numeric multiplication (starting with a numeric) is faster. By quite a bit.
jschell wrote:
I am hoping that you mean that if you start with a numeric, rather than starting with a string.
Yes.
jschell wrote:
If so then I would expect that all languages that the numeric multiplication (starting with a numeric) is faster. By quite a bit.
Me too. I was casting aspersions on .net.
