|
I buy the tires that my car was first sold with (the type, not the actual tire) and if they are not available then I get the next closest match.
Money is not a concern to me when it comes to my car or tires, so I don't purchase cheap tires just to be cheap and frugal.
EDIT: I don't do customizations with my car. Most everything is stock.
|
|
|
|
|
That's exactly what I have right now. They are ok at everything, but excellent at nothing. A better energy efficiency would be interesting, but all of them claim to have the one and only optimal profile.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
Exactly. You don't need performance tires if you are not doing performance driving. If you are going to deviate from the stock tires, then buy tires for the style of driving you do most.
Edit: see JSOP's post below.
|
|
|
|
|
I don't exactly know what I am going to need. My requirements are slowly changing as I learn. This year I gained some energy efficiency in trade for a slightly reduced performance, but there are also additional short peaks where I need all the performance I can get now. The general purpose blades I have right now are not quite right anymore.
John mentioned some measurements which give you an idea what a tire can or cannot do. For my blades all easily measurable things like length, width, weight or area are very similar. The more interesting things like the profile (which may also vary along the length of the blade), 'stiffness', behavior at high or low speeds and many other things are not described well at all. Read the description at the link I posted. The alternatives read themselves very similar, so how can I avoid trial and error?
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
Are you under the impression car manufacturers go out of their way to put the best quality tires they can find on the car they sell you?
|
|
|
|
|
|
Depends on the car: no for a hyundai, maybe yes for some high end brands, and I would hope definitely for one of these
Disclaimer: not that I'll ever own the latter
Sin tack ear lol
Pressing "any" key may continuate
|
|
|
|
|
That's kind of a silly question. If you want mileage at the expense of increased noise and reduced traction, You get a harder compound. Generally an all-weather tire with a higher tread-wear value is what you want. To reduce noise, get a tire with a taller sidewall.
If you're a road warrior and want something more performant, you get a tire with a much lower tread wear rating and shorter sidewalls.
When you've narrowed down your choices, study customer reviews, and make a selection.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Very true.
In this particular case (it's not quite about rubber tires) all candidates are made of carbon fiber and the manufacturers all promese that their product provides the best possible control. If you get to try them out, you will find some of them to be more flexible and the control softer and less precise.
Energy efficiency is a big deal, no matter what I decide to do with the saved energy. All claim to have exactly the right profile for every situation and I'm not naive enough to blindly believe that.
Most measurable parameters are very similar and beyond that it comes down to guessing. When everything goes well, those blades last forever. My old ones still look like new, at least when they are cleaned up. Collecting new ones until I finally find the right ones is a waste.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
And if you live somewhere that gets cold and snowy in the winter you either buy two sets of tires and swap the snow tires on/off every fall and spring; or get tires with softer rubber and accept the shorter lifespan and hit to fuel economy (a few percent vs hard rubber) as the tradeoff for better handling when it gets cold.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Everything regarding tire selection is a trade-off.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
You start by spelling them properly! 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
If you look closely, you will find that this is the right spelling in this case: BLADES 
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
Quite right too. I was wondering what on earth he was on about.
Regards,
Rob Philpott.
|
|
|
|
|
Bear with him. He was just a bit tyred! 
Anything that is unrelated to elephants is irrelephant
Anonymous
-
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-
I'd just like a chance to prove that money can't make me happy.
Me, all the time
|
|
|
|
|
Right now I feel very, very, very...
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
I still miss one construct from a proprietary systems programming language I was using 3o years ago:
Frequently, executing a loop, and exiting from it, has two different outcomes. E.g. you search a list or a table, and find what you were searching for. Or you do not find what you were searching for. The two cases often require distinctly different post processing. In C class languages, one way of handling this is to declare a bool outside the loop, initialize it, possibly modifying it in the loop before exiting, testing it after the loop and to either this or that.
This bool variable really isn't a variable; it is flow control. So it isn't good. And, the termination handling is syntactically detached from the loop it applies to; that isn't good either. Finally: Due to this detaching, the termination handling being outside the loop, it does not have access to the inner working of the loop, such as those values causing the loop exit.
With this language constuct I am missing, you can specify two alternate loop 'tails': One if the loop came to an end ('exitfor'), another if the loop was left prematurely due to some specific condition not being satisfied ('exitwhile'). Both tails are syntactically part of the loop, with access to loop local variables. No flow control variables need to be declared, set or tested. An example: Search a list for a key (here: 'refkey'). If the key is found, increment 'refcount'. If not, insert a new element in the list and set 'refcount' to 1:
for (Listelt elt in mylist) {
.
. until (elt.key == refkey);
.
. exitfor
. mylist.insert(new Listelt(refkey,1));
. exituntil
. elt.refcount++;
}
The corresponding plain C# code, without exit clauses, would look like
. Listelt eltfound = null;
. for (Listelt elt in mylist) {
.
. if (elt.key == refkey) {
. eltfound = elt;
. break;
. }
.
. }
. if (eltfound != null) {
. elt.refcount++;
. }
. else {
. mylist.insert(new Listelt(refkey,1));
. }
... which I think is far less explit / readable, more error prone, and introduces variables ('eltfound') which really are relevant to the loop only, but defined in a much wider scope. Besides, the tail if/else is syntactically outside the loop, and has not access to relevant data within the loop.
I am not a particular strong fan of conceptually superfluous bracketing constructs - C class languages have some silly {}-requremnents! In the language where I picked this up, there are less of those, and 'exitfor' serves as a delimiter, allowing any number of statement down to the either 'exitwhile' or the loop end. Similarly, the 'exitwhile' block may have multiple statements. In C class languages, {} would probably be needed.
In the original design, a loop might have several 'until' tests; they would all end up in the same 'exituntil'. I would like a way to optionally attach a label to an 'until' test and one or more labels to the 'exituntil' block (which could then have several alternatives differently labeled) - that would make the mechanism even more useful. (Strictly speaking, the original design used 'while' tests rather than 'until', 'exitwhile' rather than 'exituntil'. Since C# already has a 'while' with different semantics, reversing the test and calling it 'until' fits the C class languages much better.)
I have tried to create '#define' to emulate this by generating 'goto' to generated labels, but never really succeeded. Besides, the compiler doesn't know that the 'exit' part is done after termination, so modifing the list inside the loop might be prohibited (in C#). If the exit parts were part of the language, the compiler would know that modifying the list is OK - there will be no more iterations.
Would this extension have any disavantages, except for the obvious one of introducing new reserved words? (I don't think 'exitfor' and 'exituntil' are very common as variable or function names, though!)
|
|
|
|
|
Will your C# code even compile? I might be missing something here. elt will not be accessible outside the foreach.
I think I kind of understand what you are talking about. Do Any or Where extension methods help in these situations?
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
That should of course be: eltfound.refcount++;
rather than: elt.refcount++;
As I wrote: The traditional way of doing it is error prone!
|
|
|
|
|
A better solution would be a generic "not completed" detector:
for (...)
{
}
onbreak
{
}Which could work with for, foreach, while, etc.
But to be honest, I find it pretty natural to either use a bool or put the loop code in a separate method - which has the advantage of reducing the code size in the original one as well.
I can't see that this is really needed myself, but that's just my opinion.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
That 'onbreak' handles the 'exituntil' part.
It does not handle the 'exitfor' part - the code which is to be executed if you come to the end of the loop.
Besides, the way you define it: The block which contains the iterated code, the top {} pair, is closed and dead when you come to the onbreak {} part. So whichever variables were used in the loop - such as those causing the break condition, are inaccessible to the onbreak {}. I certainly hope that you are not going to suggest that local variables within the for {} block shall be accessible to the onbreak {} block!
Putting the loop code in a separate method helps nothing to handle alternate exit paths without having to set boolean flags. If you meant to include the alternate exit handlers in the method, what is the point of the method? If not: How would you indicate the required exit handling upon return to the caller of that method? How would the exit handlers be able to access the values causing that specific exit action, values local to the loop (function)?
You have another parsing problem in your proposal: The for loop is syntactically completed at the closing }. What follows it, could be any statement. You introduce an onbreak statement, not an onbreak clause of the for statement. The semantics of the for loop is modified by an adjacent statement (i.e. the onbreak) - that is sort of messy.
Obviously, I would like to have the exit clauses available in both for loops, foreach looops etc - the language providing exit clauses has a generalized 'for' control construct that covers both 'for' and 'foreach'). It also allows several exit tests (like the 'until') for while loops, similar to several 'if (cond) break;' - but since the main point is to provide different termination handling under different conditions, the mechanism would be most useful if you could provide arbirarily many 'exituntil' type clauses. I ceratainly would welcome that!
When I first was offered these alternate exit paths, it took me a while to see its real usefulness. But once you have learned to use it, and then move over to a language without it, you all the time tell yourself 'This would just have been so much more elegant if alternate exits were provided!'.
|
|
|
|
|
Member 7989122 wrote: C class languages have some silly {}-requremnents!
They don't.
If anything C has too few by allowing unbracketed one-liners for loops and conditions.
if (Whatever)
DoSomething();
is both a little untidy and slightly dangerous as there's no really visible connection between action and condition. Stuff gets moved or removed and things start to go wrong.
For my money, the compiler should insist on:
if (Whatever)
{
DoSomething();
}
|
|
|
|
|
Or better:
if (Whatever)
{
DoSomething();
}
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
That's just bad indentation!
|
|
|
|
|
I prefer that the { comes together with the indentation; the indentation starts with the {. In your layout, it doesn't: The indentation starts before the {.
Then, I also like the indentation to end with the }. If the } is undented, the undentation comes before the }, which is, in my eyes, similarly inconsistent.
Finally: When you read an if, then the condition, then ... What??? something is missing here! I don't like that, either. If the conditional statement doesn't fit on the same line, it is not empty but contains an announcer: Conditional statement(s) follow below, indented.
So my preferred style is
if (whatever) {
DoSomething();
}
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
