rayw


« Reply #15 on: March 14, 2012, 01:12:08 AM » 

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 (108)/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 (108)/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(3635.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(3636.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(3635.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


« Last Edit: March 14, 2012, 03:11:38 AM by rayw »

Logged




JimH
Newbie
Posts: 22


« Reply #16 on: March 14, 2012, 02:02:30 AM » 

RayW, Now we are making progress. I agree with what you are saying regarding percent change, but It's a question of semantics, I guess. I would say it's more a matter of precise definition on Mike's part than one of semantics. But, then that may itself be a matter of semantics. I started all this because Mike used the 36/35.5 ratio in his initial example. I can only assume that he had a temporary brain freeze because this is clearly not how one calculates either percent shrinkage or percent stretch. It's a ratio and not a percent change. I only jumped into this because Seder then was led astray and used the ratio as Mike seemed to be suggesting. He asked Mike if he was correct and Mike responded that he was when he clearly was wrong. I then made my initial 10% instead of 1% mistake but that was just a slip on my part and not fundamental to my argument. After wandering around a bit, I finally looked at the QU box to be filled in. If you hover your mouse over the box it says "Stretch the length by this amount" and it asks for a percent. Therefore, for the intended 36inch print that shrank to 35.5 inches, I would say that what Mike seems to be wanting is to stretch a 35.5 inch result to 36 inches. I think this would properly require a "stretch" computed by 100*((36  35.5)/35.5 = 1.408% If, on the other hand, Mike really intends the input to be the amount of "shrinkage" from what is intended, then since we want 36 but are getting 35.5, the shrinkage number would be 100*((36  35.5)/36) = 1.389% Obviously this "semantic difference" is probably of no practical concern unless of course Mike really means to use the ratio. Jim H



Logged




Fred A


« Reply #17 on: March 14, 2012, 08:48:36 AM » 

If, on the other hand, Mike really intends the input to be the amount of "shrinkage" from what is intended, then since we want 36 but are getting 35.5, the shrinkage number would be
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



Logged




Ernst Dinkla


« Reply #18 on: March 14, 2012, 09:33:51 AM » 

If, on the other hand, Mike really intends the input to be the amount of "shrinkage" from what is intended, then since we want 36 but are getting 35.5, the shrinkage number would be
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 You are sure your trunks did not expand instead? http://www.powerhousemuseum.com/collection/database/?irn=91382met vriendelijke groeten, Ernst Shareware too: 330+ paper white spectral plots: http://www.pigmentprint.com/spectralplots/spectrumviz_1.htm



Logged




admin


« Reply #19 on: March 14, 2012, 02:12:53 PM » 

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



Logged




JimH
Newbie
Posts: 22


« Reply #20 on: March 14, 2012, 03:09:49 PM » 

Mike,
I'm going to make one more comment and then I'll slink away.
What got me started was your initial use of the 36/35.5 = 1.04 example instead of the usual calculation of stretch percentage that Ray and I seem to agree on. This led Seder to ask if, when needing to stretch from 20 inches to 20.2 inches, he should put 1.01 into the input (20.2/20 = 1.01) . You then said that using 1.01 is correct but it is clearly not. This is partly what led me a little astray.
What I had not realized is that what you are saying is that you can use the ratio calculation if you use the fractional part of the result (multiplied by 100).
Example: Suppose you want to stretch from 40 inches to 50 inches.
50/40 = 1.25 > 0.25*100 = 25%
The more usual percentage calculation would be
100*((50  40)/40) = 25%
Voila, the same answer!!
A little algebra shows why this is so:
Let d = desired length
r = resultant length
Then
100*((d/r)  1) = 100*((d  r)/r)
This little result had escaped me.
It's been fun!
Jim H.



Logged




admin


« Reply #21 on: March 14, 2012, 04:12:17 PM » 

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



Logged




JimH
Newbie
Posts: 22


« Reply #22 on: March 14, 2012, 06:17:08 PM » 

Mike,
As the late, great Etta James sang "At Last"! The answer has come along.
I'm glad we are on common ground now. The only criticism I might offer after all this is that your method of using a ratio and then subtracting one and then shifting the decimal two places to the right, although simple, deviates from what people would normally do when asked to calculate a percentage stretch. I may be wrong but my guess is that most would calculate it using the definition of percentage change (i.e. 100*change/base) instead of what might be regarded as somewhat of a mathematical trick.
And I said I was through ...
Jim H


« Last Edit: March 14, 2012, 06:19:01 PM by JimH »

Logged




rayw


« Reply #23 on: March 14, 2012, 10:41:55 PM » 

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



Logged




admin


« Reply #24 on: March 14, 2012, 11:10:44 PM » 

Mike,
As the late, great Etta James sang "At Last"! The answer has come along.
I'm glad we are on common ground now. The only criticism I might offer after all this is that your method of using a ratio and then subtracting one and then shifting the decimal two places to the right, although simple, deviates from what people would normally do when asked to calculate a percentage stretch. I may be wrong but my guess is that most would calculate it using the definition of percentage change (i.e. 100*change/base) instead of what might be regarded as somewhat of a mathematical trick.
And I said I was through ...
Jim H
Your way is just harder to do and harder to explain and is more prone to mistakes. To get "change" in your method, you have to do a subtraction first which puts a third number into the mix, then divide that third number by the base (and half the time people will divide by the wrong number  the smaller one), then multiply all that by 100. Personally, I think it's easier to just tell people to take the larger number and divide it by the smaller one and the answer is on the calculator! Just look at the third digit, add a decimal point, then add the fourth, and fifth digits and you have your answer. Both ways work, so take the easier one. If doing a subtraction, plus a divide, plus a multiply is easier for you, I can't argue. For most people, I'll tell you from experience, half the time they won't know whether the "base" is the 36 inches or the 35.5 inches. Larger number divided by smaller number and start at digit 3 on the calculator is a lot easier for most. Mike


« Last Edit: March 14, 2012, 11:15:43 PM by Mike Chaney »

Logged




admin


« Reply #25 on: March 14, 2012, 11:13:49 PM » 

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


« Last Edit: March 14, 2012, 11:17:07 PM by Mike Chaney »

Logged




rayw


« Reply #26 on: March 14, 2012, 11:16:03 PM » 

Precisely



Logged




JimH
Newbie
Posts: 22


« Reply #27 on: March 14, 2012, 11:51:36 PM » 

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.



Logged




JimH
Newbie
Posts: 22


« Reply #28 on: March 15, 2012, 12:02:44 AM » 

Mike, You said Doing all that nonsense is what a C++ programmer would do. I can't resist commenting on this. The typical C and C++ programmer just revels in the tricky and sly shortcut. He is always trying to compress the algorithm into the shortest and most incomprehensible code possible. Therefore, he would favor your method. The typical plodding Fortran programmer can't remember tricks and must start from first principles and therefore would favor my method. Jim H.



Logged




rayw


« Reply #29 on: March 15, 2012, 01:42:30 AM » 

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 )



Logged




