|
seems parenthesized right to me there's an extra set around the X for no reason but the conversion looks right
|
# ? Jul 24, 2009 04:35 |
|
|
# ? May 28, 2024 15:54 |
|
sex offendin Link posted:seems parenthesized right to me there's an extra set around the X for no reason but the conversion looks right The extra set is to maintain order of operations. E.g. SIN( x + 30 ) would expand to sin( x + 30 * M_PI / 180 ) without the extra parens, versus sin( (x + 30) * M_PI / 180 ) with.
|
# ? Jul 24, 2009 04:42 |
|
Yeah, on a second look I read the parens wrong
|
# ? Jul 24, 2009 05:07 |
|
Avenging Dentist posted:The sine function generally does not range from -0.0174532778 to 0.0174532778. The only thing I can find wrong with it is that it uses degrees instead of gradians.
|
# ? Jul 24, 2009 05:20 |
|
Scaevolus posted:The only thing I can find wrong with it is that it uses degrees instead of gradians. Why would a system that uses 400 units for the angle of a circle be better?
|
# ? Jul 24, 2009 05:22 |
|
Avenging Dentist posted:Why would a system that uses 400 units for the angle of a circle be better? Why would a 404 help your point?
|
# ? Jul 24, 2009 05:25 |
|
Scaevolus posted:Why would a 404 help your point? If you can't be bothered to figure out what the URL should be, perhaps you should go and hit the books?
|
# ? Jul 24, 2009 05:26 |
|
Avenging Dentist posted:If you can't be bothered to figure out what the URL should be, perhaps you should go and hit the books mayhaps? 3 char extensions should be good enough for anyone!
|
# ? Jul 24, 2009 05:27 |
|
Scaevolus posted:3 char extensions should be good enough for anyone! You know, if you got a 3-char extension maybe you wouldn't be a 2-bit poster anymore!
|
# ? Jul 24, 2009 05:28 |
|
This is why macros are bad, they kick sand in everyone's vaginas and happens
|
# ? Jul 24, 2009 05:28 |
|
Avenging Dentist posted:You know, if you got a 3-char extension maybe you wouldn't be a 2-bit poster anymore! 0_0
|
# ? Jul 24, 2009 05:28 |
|
Gradian: The GNU radian
|
# ? Jul 24, 2009 12:44 |
|
Otto Skorzeny posted:Yeah, on a second look I read the parens wrong
|
# ? Jul 24, 2009 14:46 |
|
Mustach posted:Gradian: The GNU radian
|
# ? Jul 24, 2009 16:36 |
|
code:
|
# ? Jul 24, 2009 17:54 |
|
Mick posted:
It's almost as if there used to be a line of code under "foo".
|
# ? Jul 24, 2009 19:39 |
|
geetee posted:It's almost as if there used to be a line of code under "foo". People have an unhealthy obsession with switch statements though (especially in languages like C# or Java). I mean ok, sure, in C/C++ with a sub-optimal compiler, a switch statement might be faster than if/elses by implementing it as a jump table (a smart compiler should be able to figure this out too for if/elses), but that sort of thing isn't going to work with string comparisons.
|
# ? Jul 24, 2009 20:35 |
|
Avenging Dentist posted:People have an unhealthy obsession with switch statements though (especially in languages like C# or Java). I mean ok, sure, in C/C++ with a sub-optimal compiler, a switch statement might be faster than if/elses by implementing it as a jump table (a smart compiler should be able to figure this out too for if/elses), but that sort of thing isn't going to work with string comparisons. I went to search Google for some statistics on when C#'s compile-string-switches-to-a-hashtable approach becomes more/less efficient than a chain of if/elses, and I found something else that belongs in this thread: shoehorning in a functional lambda-based switch construct that accomplishes the same thing as a bunch of ifs, but uglier! code:
The best part is that you would think that you could say "Oh that's almost kinda cool, I could create this switch object and pass it around", but you can't because it abuses collection initializers and executes each case immediately in the IEnumerable.Add method.
|
# ? Jul 24, 2009 20:48 |
|
Flobbster posted:I went to search Google for some statistics on when C#'s compile-string-switches-to-a-hashtable approach becomes more/less efficient than a chain of if/elses I would hope that the compiler would notice that you're using a chain of if/elses and transform them into a switch statement in the IL.
|
# ? Jul 24, 2009 21:07 |
|
Avenging Dentist posted:People have an unhealthy obsession with switch statements though (especially in languages like C# or Java). I mean ok, sure, in C/C++ with a sub-optimal compiler, a switch statement might be faster than if/elses by implementing it as a jump table (a smart compiler should be able to figure this out too for if/elses), but that sort of thing isn't going to work with string comparisons. Here is a small peek into the mind of someone who loves switch statements. I found this today: code:
|
# ? Jul 24, 2009 22:07 |
|
Avenging Dentist posted:I would hope that the compiler would notice that you're using a chain of if/elses and transform them into a switch statement in the IL. Not all if/else chains translate into a switch/case block, and if they do you just wasted a lot more time typing it out like that. Also there's no good way to represent two consecutive labels with no break statement in between within a switch/case block if you type it out as an if/else chain.
|
# ? Jul 24, 2009 23:46 |
|
BattleMaster posted:Not all if/else chains translate into a switch/case block, and if they do you just wasted a lot more time typing it out like that. Do you really have that hard a time writing else if(foo== compared to break? BattleMaster posted:Also there's no good way to represent two consecutive labels with no break statement in between within a switch/case block if you type it out as an if/else chain. They don't have the boolean-or operator where you're from? Switch statements are useful, but people use them a lot of times because they think it makes them clever. Unless you're writing Duff's Device (and you shouldn't), you're not being clever. See the above example for a good misuse of switches, since I guess using boolean arithmetic just wasn't enough fun.
|
# ? Jul 25, 2009 00:02 |
|
BattleMaster posted:Also there's no good way to represent two consecutive labels with no break statement in between within a switch/case block if you type it out as an if/else chain. code:
|
# ? Jul 25, 2009 00:18 |
|
Cool, extraneous function calls and code duplication. That works out really well when you have to fit your program into a few KB of flash memory. Hint: Not everyone programs for desktop/server/laptop computers. A lot of embedded devices have compilers that aren't so hot at optimization. For example, MPLAB C18 for PIC microcontrollers never generates jump tables out of if/else chains. It instead turns it into a big chain of comparisons. Small Device C Compiler doesn't either, though its jump-table generation for switch/case is pretty bad as it is.
|
# ? Jul 25, 2009 01:31 |
|
Goat Bastard posted:code Alternatively, if duplicated function calls murdered your father and raped your mother: code:
|
# ? Jul 25, 2009 01:31 |
|
Zhentar posted:Alternatively, if duplicated function calls murdered your father and raped your mother: That works but then the compiler might not understand what you're trying to do and will not optimize it into a jump table. Not that any of the C compilers I work with will do that anyways.
|
# ? Jul 25, 2009 01:34 |
|
BattleMaster posted:Hint: Not everyone programs for desktop/server/laptop computers. A lot of embedded devices have compilers that aren't so hot at optimization. For example, MPLAB C18 for PIC microcontrollers never generates jump tables out of if/else chains. It instead turns it into a big chain of comparisons. Small Device C Compiler doesn't either, though its jump-table generation for switch/case is pretty bad as it is. A year later the inefficiency from forcing things into difficult to maintain code is going to dwarf the overhead of extra conditional branches.
|
# ? Jul 25, 2009 01:36 |
|
Zhentar posted:A year later the inefficiency from forcing things into difficult to maintain code is going to dwarf the overhead of extra conditional branches. Maybe, but a more immediate concern is crappy compilers and extremely limited RAM/ROM where you quite literally have to count bytes. I don't find switch/case much harder to modify than if/else myself, though.
|
# ? Jul 25, 2009 01:37 |
|
switch is awful and is the wrong thing to use 95% of the time
|
# ? Jul 25, 2009 01:42 |
|
If you have one variable which may have one of several discrete values, switch is a perfectly fine way to make decisions based on that value, assuming you aren't some sort of OOD zombie that laments daily the sad passing of Smalltalk
|
# ? Jul 25, 2009 01:49 |
|
BattleMaster posted:That works but then the compiler might not understand what you're trying to do and will not optimize it into a jump table. Not that any of the C compilers I work with will do that anyways. What's that quote about premature optimization?
|
# ? Jul 25, 2009 02:16 |
|
CanSpice posted:What's that quote about premature optimization? What's that quote where I said that I work with devices that have bytes of RAM, kilobytes of flash memory and the compilers suck? It's not premature optimization when you go to burn in a program and the debugger tells you the target doesn't have enough memory and somehow need to make it fit. Edit: Seriously, I work with an architecture where you can define a 16 bit "near" pointer or a 24 bit "far" pointer, and the reason that they let you choose is because you might need that byte for something else. BattleMaster fucked around with this message at 02:22 on Jul 25, 2009 |
# ? Jul 25, 2009 02:19 |
|
CanSpice posted:What's that quote about premature optimization? "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." - Tony Hoare The quote was popularized by Knuth. People (not Knuth, who spoke pretty clearly in the article where he first quoted Hoare that nobody bothers to read and everyone ignores) fail to realize that Hoare was referring to counting cycles. Accounting for known limits of your compiler by translating one simple structure into another that is also semantically valid for what you're doing is nothing like 'premature optimization'.
|
# ? Jul 25, 2009 02:23 |
|
BattleMaster posted:Edit: Seriously, I work with an architecture where you can define a 16 bit "near" pointer or a 24 bit "far" pointer, and the reason that they let you choose is because you might need that byte for something else. What arch are you working on again? I thought segmented memory was a thing of the past even in embedded environments.
|
# ? Jul 25, 2009 02:25 |
|
Otto Skorzeny posted:What arch are you working on again? I thought segmented memory was a thing of the past even in embedded environments. Microchip PIC18 microcontrollers, which have one contiguous flash memory addressing space but segmented RAM. 16-bit Near ROM pointers refer to a position within the first 64KB of flash memory, and 24-bit far ROM pointers can access the entire 21-bit range. Most devices have much less than 64KB of flash memory and nothing comes anywhere close to the addressing limit so I've never actually had to use a far pointer before. A far RAM pointer is 16-bit and refers to a spot in the entire 12-bit memory addressing space while an 8-bit near RAM pointer refers to a location in a special bank that is accessible at all times no matter what bank is selected.
|
# ? Jul 25, 2009 02:32 |
|
BattleMaster posted:What's that quote where I said that I work with devices that have bytes of RAM, kilobytes of flash memory and the compilers suck?
|
# ? Jul 25, 2009 02:42 |
|
A real man would use the GCC frontend with LLVM to compile to (optimized) C and then compile with the old-n-busted compiler you've got.
|
# ? Jul 25, 2009 02:47 |
|
I really should give that a try some day and see if it breaks anything. C18 and SDCC are really wacky and nonstandard though.
|
# ? Jul 25, 2009 02:49 |
|
If the compilers support functions, if statements, and gotos you'll probably be ok.
|
# ? Jul 25, 2009 02:54 |
|
|
# ? May 28, 2024 15:54 |
|
Avenging Dentist posted:If the compilers support functions, if statements, and gotos you'll probably be ok. Durr hurr I was thinking more along the lines of memory poo poo that other compilers wouldn't understand.
|
# ? Jul 25, 2009 03:08 |