Hi Jim,

It's a question of semantics, I guess. Confusion caused between stretching and shrinkage. Usually, in my world, a per unit change (simply multiply by 100 if the per unit value is small to get percentage) is the amount you have to move from where you are to where you want to be expressed as a ratio of where you are. So, if I want to walk ten miles, and I've gone eight, then I have to walk (10-8)/8 of the distance that I've walked so far e.g. 1/4 or 25% more. If I want to look back at it, from the destination, then the last effort was (10-8)/10 or 1/5th or 20% of the total.

So, Mike has said you want to make (that is the destination) a 36 long print, but you get 35.5, so shrinkage is 100x(36-35.5))/36 = 1.3888%, or 1.4% in real money. (you have to stretch what you have by 1.4% to get to the desired length). If you happen to get a print, say 36.5 long, then shrinkage would be 100x(36-36.5)/36 = -1.4%, (call it 1.4% stretch?) and you have to shrink your result by 1.4% to get to where you want to be.

Aternatively, you could say, in the first case (shrinkage) that from where you are, you need to stretch what you have by 100x(36-35.5)/35.5 = 1.4084 (or 1.4%) to get to the desired length, so if the shrinkage is small compared with the length, whether actual or desired, it doesn't really matter which method you use to calculate it, in a practical situation.

Have I confused you yet? If so, do what I do - make the frame to suit the size of the canvas.  

I was sort of amused by your discussion with yourself, and wondered how long you could keep doing so  

Best wishes,

Ray

edited to correct typo in calculation

Usually, when swimming, if the water temperature in the lake or ocean is cold, there will be shrinkage.... not sure how you calculate that!

Fred
  :-\

I wanted to keep it as simple as possible for users.  You guys are making it as complicated as possible.  Take the intended length and divide by the actual length that came out of the printer.  Use that as a percentage.  If you print 36 inches and you get 35.25 inches, it's 36/35.25 or 1.02... so use 2%.  As the tool tip says when you hover over it, it stretches by that amount to compensate.  So your 35.25 inch print (actual) is going to get stretched by 2%.  2% of 35.25 is .75 inch and that's the stretch you want.

Mike

I think we gots it now!  Yeah, I should have mentioned that you don't put 1.01 in the input box but rather use that as a percentage (the fractional part*100).  In my mind, I was assuming that part because the box says %.    I'll explain this as simply as possible in the next revision of the help.

For now, the tool tip says it most concisely: "stretch the length by this amount" which is correct.  What the program is actually doing is adding 2% to the length if you enter a "2" in the box.  And that fits with your math above.  That makes the math as simple as possible for users.  Take the specified print length (36 for example), divide by the actual print length that comes out (35.5 for example), and your answer is sitting on the display: just ignore the one and shift the decimal 2 places to the right.  36/35.5 = 1.014084507, so 1.01.4084507% (1.4%) is your answer.

Mike

Jim,

Mike used to, maybe still does, program in Pascal, iirc. That is one huge mathematical trick. I know many folk who used that language, it tended to distort their view of reality 

By saying that, it tended to make them think of short cuts, different ways of doing things, which were not necessarily obvious to us lesser mortals stuck with Fortran, Cobol, and the like.

fwiw, Mike is saying the same as you, except he's not expressing it with the maths required to shift 1.02 to 2% - but we know that anyway. I wonder if the sharpening (which depends on print size) is adjusted accordingly 

Best wishes,

Ray

See above.    Coding in any language teaches you how to be efficient.  Being able to get the answer on your calculator with one divide using two numbers is a lot better than doing a subtraction, trying to remember the result, dividing that by the larger of the two numbers you started with (remembering not to accidentally use the smaller one), and then multiplying that whole deal by 100.  And for what?  Because you can't ignore the "1" on the calculator and use the 3rd, 4th, and 5th digit on the display?  Doing all that nonsense is what a C++ programmer would do. 

Mike

Mike,

I think we can argue this all day and probably not agree on the best method.  Your approach certainly works but I am convinced that only a minority of people would use your method to calculate percent change whatever the situation.  In my opinion you should not tell users how to calculate the required percent stretch at all.  Better to just define precisely what the input requires and leave it to the user to use whatever method he prefers, either mine and RayW's or yours.

You are making an argument that your method is easier and simpler than mine.  I would argue that using your method is essentially using a mathematical trick that has the big disadvantage of basically ignoring the natural definition of percent change which is 100 times the fractional change where the fractional change is the change or delta from some base value divided by the base value.

In my experience it is better to remember a definition and do calculations based on that definition than to remember a trick that gives the same answer.  I argue, but you may disagree, that your method bears no obvious relation to the definition.

By the way, I do not subscribe to RayW's suggestion that your "view of reality" has been somehow distorted by Pascal programming.  I am a retired engineer who programmed in Pascal, basic, C, and Fortran (mostly Fortran) and I don't feel that my view has been distorted (although friends and family may disagree).  On the other hand, during many years of working with numbers, it never occurred to me to calculate percent change in the manner you suggest.

I think I can anticipate your rejoinder.  You are going to say that many Qimage users don't know enough about the definition of percent change to do the required calculation.  This is probably true of those who print on canvas.

Jim H.

Hi Jim,

Well, from the user's point of view, I would guess since QI knows the size he's aiming at (36 in examples above), then all he needs to enter is the size he actually gets (35.5), so no need for the user to calculate anything. It's up to the programmer to choose whatever method he likes in getting to the result he needs, bearing in mind documentation and maintenance issues, of course.

I bought Borland Pascal before Philippe Kahn moved to USA. It was for a cpm machine, iirc. It consisted of a couple of floppies (5 1/4 iirc, or maybe 8 inches) and a dozen or so duplicated sheets for the manual - not even printed, stencil duplicated. You can now version 1 and later versions for free. I don't remember actually using it, but many did. Interesting article on the Wiki, you can see how Borland was 'different', even from the origin of the original code. Having started out different, it is difficult to later conform to more widespread standards, without upsetting and maybe losing your existing customer base.

Best wishes,

Ray

(Next week, a dissertation on alternative uses for punched cards  )