That may have been a mistake...
-
Indeed, just compile it at the command line.
:doh: I knew there was a simple solution!
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
-
As some of you may know, I created a Tip/Trick recently about converting numbers to the word equivalent (523 to "Five hundred and twenty three"). With my tongue firmly rammed into my cheek, I suggested that a switch statement would be a good way to do it. Well, it's Saturday, and I thought to myself "A switch has got to be faster than the proper way - I wonder how much faster?" So I thought I'd check. I wrote and tested a proper version and used it to generate the Big Switch code I'd need, writing it to a text file "BigSwitch.cs". Then I could include this and do a side-by-side comparison. Initial testing of the "proper" way to do it suggested that one million iterations should test all code paths and eliminate cached jitter in the results. So, I made my mistake. I double clicked on the "BigSwitch.cs" file I had created. VS2008 started to load it. I'm still not sure if it would have suceeded; I killed the process after 30 minutes. Note to self: Do not attempt to load 82.7 Mb code fragments into VS again... :-O
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
-
:doh: I knew there was a simple solution!
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
-
Two million and six, indented for readability! :-\ (that may have contributed to the load time...:laugh:)
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
-
Two million and six, indented for readability! :-\ (that may have contributed to the load time...:laugh:)
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
-
I suspect that a Web service, backed by a database, might be worth a try...
OOO! Now there is an idea for the "Extra Credit" version - can I steal it? :laugh:
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
-
I don't get paid on Saturdays anyway :(
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
-
As some of you may know, I created a Tip/Trick recently about converting numbers to the word equivalent (523 to "Five hundred and twenty three"). With my tongue firmly rammed into my cheek, I suggested that a switch statement would be a good way to do it. Well, it's Saturday, and I thought to myself "A switch has got to be faster than the proper way - I wonder how much faster?" So I thought I'd check. I wrote and tested a proper version and used it to generate the Big Switch code I'd need, writing it to a text file "BigSwitch.cs". Then I could include this and do a side-by-side comparison. Initial testing of the "proper" way to do it suggested that one million iterations should test all code paths and eliminate cached jitter in the results. So, I made my mistake. I double clicked on the "BigSwitch.cs" file I had created. VS2008 started to load it. I'm still not sure if it would have suceeded; I killed the process after 30 minutes. Note to self: Do not attempt to load 82.7 Mb code fragments into VS again... :-O
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
Maybe your app should have emitted IL code rather than C# code. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
-
Maybe your app should have emitted IL code rather than C# code. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
Luc Pattyn wrote:
hould have emitted IL code
:laugh: :thumbsup: Good idea - but it would have defeated the purpose of the timing tests. I would have written the IL code as assembler: numeric index into jump table, or string pointer table maybe. I was more interested in how the compiler would handle the problem than I was in how I would handle it! PiebaldConsult came up with an idea for a web service backed by a database, so I mocked up the database version (with a SqlCE DB) that works up to 1,000,000 - a total of a 92MB DB - it seems pretty fast and the code is pretty small. Do you think I should post it as a new Tip / Trick: "Numbers to words : the Extra Credit version"? :laugh:
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
-
Luc Pattyn wrote:
hould have emitted IL code
:laugh: :thumbsup: Good idea - but it would have defeated the purpose of the timing tests. I would have written the IL code as assembler: numeric index into jump table, or string pointer table maybe. I was more interested in how the compiler would handle the problem than I was in how I would handle it! PiebaldConsult came up with an idea for a web service backed by a database, so I mocked up the database version (with a SqlCE DB) that works up to 1,000,000 - a total of a 92MB DB - it seems pretty fast and the code is pretty small. Do you think I should post it as a new Tip / Trick: "Numbers to words : the Extra Credit version"? :laugh:
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
OriginalGriff wrote:
it would have defeated the purpose
rather than write code, you should have read this then: Something You May Not Know About the Switch Statement in C/C++[^]. And if you are convinced C# may behave differently, it would deserve a real article.
OriginalGriff wrote:
Do you think I should post it as a new Tip / Trick
Absolutely, a tip or article. And please include an SQL file with the data, so others can set up their own DB.
OriginalGriff wrote:
Five hundred and twenty three
There seems to be one more issue that needs getting settled: should or shouldn't you use a hyphen in those inverted decimal-and-unit combinations? And if both are acceptable, how to let the user choose? :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
-
OriginalGriff wrote:
it would have defeated the purpose
rather than write code, you should have read this then: Something You May Not Know About the Switch Statement in C/C++[^]. And if you are convinced C# may behave differently, it would deserve a real article.
OriginalGriff wrote:
Do you think I should post it as a new Tip / Trick
Absolutely, a tip or article. And please include an SQL file with the data, so others can set up their own DB.
OriginalGriff wrote:
Five hundred and twenty three
There seems to be one more issue that needs getting settled: should or shouldn't you use a hyphen in those inverted decimal-and-unit combinations? And if both are acceptable, how to let the user choose? :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
Luc Pattyn wrote:
should or shouldn't you use a hyphen in those inverted decimal-and-unit combinations?
Thank you for pointing out this problem; you are indeed quite correct and there should be a hyphen between the tens digit and the units digit for all values between 21 and 99, excepting (of course) those integrally divisible by ten. This also applies to such numbers when considered as part of a larger number: "one thousand and sixty-seven" or "three hundred and fourty-eight thousand". In addition, there may be a comma between the magnitude indicator and the lesser value ("one thousand, three hundred and sixty-seven") although this is not compulsory (unless there is a decimal point in the number, in which case it should appear at each three digit position to the right of the decimal). I had completely forgotten this point, and have modified the Tip / Trick accordingly. In my defence, it has been many years since I last wrote a cheque and thus any numbers as words! Even then, to exceed one thousand on a personal cheque was not an everyday occurrence... :laugh: I have corrected this, and provided credit as is only appropriate.:thumbsup:
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
-
Luc Pattyn wrote:
should or shouldn't you use a hyphen in those inverted decimal-and-unit combinations?
Thank you for pointing out this problem; you are indeed quite correct and there should be a hyphen between the tens digit and the units digit for all values between 21 and 99, excepting (of course) those integrally divisible by ten. This also applies to such numbers when considered as part of a larger number: "one thousand and sixty-seven" or "three hundred and fourty-eight thousand". In addition, there may be a comma between the magnitude indicator and the lesser value ("one thousand, three hundred and sixty-seven") although this is not compulsory (unless there is a decimal point in the number, in which case it should appear at each three digit position to the right of the decimal). I had completely forgotten this point, and have modified the Tip / Trick accordingly. In my defence, it has been many years since I last wrote a cheque and thus any numbers as words! Even then, to exceed one thousand on a personal cheque was not an everyday occurrence... :laugh: I have corrected this, and provided credit as is only appropriate.:thumbsup:
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
Thanks for the clarification, and of course the credit. I didn't know at all about the thousands separators turning into comma's (and I hope you really mean "," and not "comma"). How about the ultimate edition, dealing with floating-point numbers? (could be double, float, decimal) :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
-
OriginalGriff wrote:
it would have defeated the purpose
rather than write code, you should have read this then: Something You May Not Know About the Switch Statement in C/C++[^]. And if you are convinced C# may behave differently, it would deserve a real article.
OriginalGriff wrote:
Do you think I should post it as a new Tip / Trick
Absolutely, a tip or article. And please include an SQL file with the data, so others can set up their own DB.
OriginalGriff wrote:
Five hundred and twenty three
There seems to be one more issue that needs getting settled: should or shouldn't you use a hyphen in those inverted decimal-and-unit combinations? And if both are acceptable, how to let the user choose? :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
The beauty of the database solution is that you can easily add globalization -- a new language/culture is simply another column in the table. :cool:
-
The beauty of the database solution is that you can easily add globalization -- a new language/culture is simply another column in the table. :cool:
Yep. And you can outsource it, all it takes is a linguist, not a programmer. Maybe there is a business opportunity here. Or there could soon be a new homework assignment: given a numbers-to-words database in language A, translate it automatically to language B. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
-
Yep. And you can outsource it, all it takes is a linguist, not a programmer. Maybe there is a business opportunity here. Or there could soon be a new homework assignment: given a numbers-to-words database in language A, translate it automatically to language B. :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
Oh, good, so journalism majors can find work. P.S. http://search.dilbert.com/search?w=journalism+major[^]
-
As some of you may know, I created a Tip/Trick recently about converting numbers to the word equivalent (523 to "Five hundred and twenty three"). With my tongue firmly rammed into my cheek, I suggested that a switch statement would be a good way to do it. Well, it's Saturday, and I thought to myself "A switch has got to be faster than the proper way - I wonder how much faster?" So I thought I'd check. I wrote and tested a proper version and used it to generate the Big Switch code I'd need, writing it to a text file "BigSwitch.cs". Then I could include this and do a side-by-side comparison. Initial testing of the "proper" way to do it suggested that one million iterations should test all code paths and eliminate cached jitter in the results. So, I made my mistake. I double clicked on the "BigSwitch.cs" file I had created. VS2008 started to load it. I'm still not sure if it would have suceeded; I killed the process after 30 minutes. Note to self: Do not attempt to load 82.7 Mb code fragments into VS again... :-O
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
Hi, I know you are not totally serious but what is the correct way and why should it not be faster than a large switch? I think the created IL code behaves similar to a very large if-then-elseif construct. Thus the switch-solution will get slower if you increase the range of supported numbers. btw: I would create a "real algorithm" to produce the strings and pair it with a dictionary as a cache. Robert
-
Hi, I know you are not totally serious but what is the correct way and why should it not be faster than a large switch? I think the created IL code behaves similar to a very large if-then-elseif construct. Thus the switch-solution will get slower if you increase the range of supported numbers. btw: I would create a "real algorithm" to produce the strings and pair it with a dictionary as a cache. Robert
There are many ways to do a switch: For example, you could set up a table of delegates (each delegate referring to a method which executes the case block). To implement the switch for a numeric value, you need only use the parameter as an index into the table. No comparisons are required, so executions speed is excellent and the time taken to get to the code for the case block is the same for each case. To implement this with an if-then-else requires a comparison for each case in turn - this is understandably slower, and the execution time differs for each case. There are other ways - the above is only suitable for densely populated cases - but I hope that makes some sense!
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
-
Thanks for the clarification, and of course the credit. I didn't know at all about the thousands separators turning into comma's (and I hope you really mean "," and not "comma"). How about the ultimate edition, dealing with floating-point numbers? (could be double, float, decimal) :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
Luc Pattyn wrote:
How about the ultimate edition, dealing with floating-point numbers?
I think that is the "Pro Ultimate Gold Team Edition for Workgroups Turbo CRXVI-DiD" due for simultaneous release with the "Hades Low Temperature Food Storage Conditions" application. The release date of the later is, unfortunately, beyond my control - but is estimated to be when Microsoft release a bug-free version of Visual Studio.
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
-
Hi, I know you are not totally serious but what is the correct way and why should it not be faster than a large switch? I think the created IL code behaves similar to a very large if-then-elseif construct. Thus the switch-solution will get slower if you increase the range of supported numbers. btw: I would create a "real algorithm" to produce the strings and pair it with a dictionary as a cache. Robert
Robert Rohde wrote:
I think the created IL code behaves similar to a very large if-then-elseif construct. Thus the switch-solution will get slower if you increase the range of supported numbers.
Wrong. IL has a special instruction for switch which the JIT translates into a jump table. Switches of consecutive integer values (so that a table without large holes is possible) don't get slower if you add cases. Switches of strings are implemented using a Dictionary<string, int> and the IL switch instruction on the resulting int.
-
As some of you may know, I created a Tip/Trick recently about converting numbers to the word equivalent (523 to "Five hundred and twenty three"). With my tongue firmly rammed into my cheek, I suggested that a switch statement would be a good way to do it. Well, it's Saturday, and I thought to myself "A switch has got to be faster than the proper way - I wonder how much faster?" So I thought I'd check. I wrote and tested a proper version and used it to generate the Big Switch code I'd need, writing it to a text file "BigSwitch.cs". Then I could include this and do a side-by-side comparison. Initial testing of the "proper" way to do it suggested that one million iterations should test all code paths and eliminate cached jitter in the results. So, I made my mistake. I double clicked on the "BigSwitch.cs" file I had created. VS2008 started to load it. I'm still not sure if it would have suceeded; I killed the process after 30 minutes. Note to self: Do not attempt to load 82.7 Mb code fragments into VS again... :-O
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
