(Also, how important is efficiency, and why?)
I don’t know that they’re thinking enough to be worried. I think they just do it because they had it pounded into their heads that pedestrians walk facing traffic, but they never had it pounded into their heads that bicyclists are traffic and not pedestrians. I don’t know that I’d know any bicycle safety rules if it wasn’t for perpetual debates on message boards over whether bicyclists or car drivers are worse. And at any time before learning those rules, I could have decided “well, bikes, those sound quite fun” and bought one and started riding wherever.
Okay, I found this example of how to do a Fibonacci=like sequence non-recursively.
All I gotta say is: Why in all hells would you want to do it this way?
What does “efficient” mean exactly? I figure it means number of calculations required. How many more calculations are required by the recursive version? Why is this bad? How often does a program’s inefficiency in this sense get in the way of solving a problem in a timely fashion?
Continuing to answer my own questions, I found this discussion forum thread in which the merits of recursive and non-recursive approaches are discussed. It is also explained there that some devices we use have small enough memory that it can make a real difference which approach you use.
So I can see how it would be important to understand how to do things both ways at least.
Are we talking slow moving traffic in a city? Riding with traffic can work in that situation. Or faster moving traffic on the outskirts or outside of cities?
If you are somewhere where the traffic is fast and visibility may be an issue, you can either put your trust completely in the drivers swerving around you from behind, or you can have some say in whether you live or not. Either way they will swerving around you. There will not be total chaos, nor horns blaring. Swerving around a cyclist near the shoulder is the same to a driver whether they are presented with a bicyclist face or ass first.
At the lower level in most C-like languages (depending on the compiler, I suppose) function calls involve something known as “growing the stack”, this involves:
[ul]
[li]Before calling a function, allocating memory and saving your local variables in memory if they’re in caller-saved registers (including saving the return address of your caller).[/li][li]After a function is called, allocating memory and saving local variables from the previous function in memory if they’re in callee-saved registers[/li][li] Allocating more memory to store any local variables of the new function that cannot be in a register (either due to having too many local variables, the value being greater than the register word size, the value being made of multiple values such as a string of text, or some other reason).[/li][li] After performing these operations, unrolling the previous steps. Meaning you have to restore callee-saved registers, and caller-saved registers to their previous states. [/li][/ul]
Saving and loading data from between register and memory is more or less the slowest basic operation you can do at the assembly level (in this case allocation usually isn’t a problem since the memory you’re allocating is probably already reserved for you by the OS, you’re usually just incrementing two or three pointer values). Not to mention it eats up memory to a ridiculous degree. As I recall, in Java if you don’t increase the maximum memory limit, with recursion you encounter an out of memory error before the integer overflow limit doing something as simple as a factorial.
However, it should be said that in a large number of cases, iterative versions of recursive problems require the use of a stack or queue data structure. For instance, graph searches (Dijkstra’s, A*, Breadth/Depth-First Search, and so on) use stacks/queues/priority queues when done iteratively. Conceptually it’s almost exactly the same as a recursive solution (except for a little extra hacking required to “rebuild” the path when you find the goal), except omitting the recursive call so it saves a lot on memory and register saving nonsense.
However on my however, none of this applies to languages like Haskell, which are optimized for recursion (and, in fact, iteration is literally impossible given that there is no syntax for a for/while loop in those languages).
Even with all this, it depends on what you’re trying to do. I’d only optimize out recursion if the problem is bound to go into deep recursion. If it’s only 5-6 calls deep and the recursive code looks much nicer, I’ll just use recursion. It’s only when the problem is already a slow memory hog that’s liable to go 100-calls deep that I kludge it into an iterative one.
Riding against traffic is insane. It’s particularly bad on one-way streets. I’ve almost run into bicyclists when making a left hand turn. You are checking for pedestrians in the crosswalk and bicycles squeezing in on your left, you are not expecting to have a bicycle to come into your path from in front.
If I’m parked, I’ll check my side mirror before opening a door to make sure that I don’t open it into a bicyclist. I won’t be looking ahead as well.
In a city environment or in any environment?
As both a driver and a cyclist I disagree. I am not speculating here–it is not the same at all. In a suburban area where the speed limit is generally 35 MPH, I ride my bike at 15 (and drive at 35-40). So if I am riding with traffic and a car approaches from behind going in my direction, the closing speed is 20-25. But I were to ride against traffic the closing speed would be 50-55. That’s a pretty big difference and gives a driver much less time to react smoothly, and makes for a worse outcome for the cyclist in case of contact. And in no case should a driver have to “swerve” to avoid a cyclist.
My reasoning was that if I was riding along and spotted a hole or broken glass in front of me,
a) if I was facing traffic I would know whether it was safe to swerve around the obstacle without slowing down, while
b) if traffic was coming from behind me I might swerve out into the path of a car that was sneaking up behind me.
Swerving to go around the obstacle would of course be preferable to stopping and then having to get started again with the bike in high gear.
Fire Control had two computers on the boat. I found it extremely annoying that these were referred to as #0 and #1.
How does riding toward the cars make any difference? It’s not like you take up any more space heading toward them than you do heading away from them.
Imagine yourself in a car, approaching a bicyclist in your lane. What do you do? Answer: just as you would when approaching any other slower-moving vehicle: Slow down, until it’s safe for you to pass.
Now, imagine yourself in a car, approaching a bicyclist in your lane coming toward you. What do you do?
I await your answer.
I’m driving along a country road, I see a bicyclist up ahead in my lane along the shoulder, I give him some extra room and drive around him. That is if I see him. If I’m distracted, or it’s dark, I may accidentally run into him and kill him.
Now, if you’re the cyclist, wouldn’t you rather have a sense of what is going to happen, before I reach you? Better to drive into the ditch than be smashed by a car. Facing away, you don’t have that option.
Now let’s take your scenario: you slow down, but the bicyclist, since he is facing towards you, keeps coming closer. That leaves the cyclist the options of a) passing you in the same lane if there is room to do so, b) moving to the shoulder to pass you, or c) moving into the ditch to avoid you. Any of these are infinitely preferable to being smashed and killed from behind.
If anyone can’t understand that, then it is one of those things I can’t fathom people not understanding.
That’s what I’m saying! Following the rules of the road and being predictable is how one stays safest on a bicycle; just doing whatever the hell you want is trouble.
No. The way people drive, it’s far safer to be able to see the idiot coming, rather than have them coming up behind you. It’s a survival tactic.
If you never rode a bike on dangerous streets, you probably can’t fathom it. One very important thing, you can see the eyes of the driver. Which really matters.
I concede your point that the environment could well make a difference.
Just curious, is there anything empirical that can be brought to bear on this question?