how can we change dimension  inch to millimeter in matlab please help me for that

could you please give me syntax for that with example ?

"kunal  varaiya" <kvaraiya@gmail.com> wrote in message <hoq5bk$8e1$1@fred.mathworks.com>...
> how can we change dimension  inch to millimeter in matlab please help me for that
> 
> could you please give me syntax for that with example ?

lenmm=leninch*25.4;

I hope this wasn't a serious question...

Mark Shore wrote:
> "kunal  varaiya" <kvaraiya@gmail.com> wrote in message 
> <hoq5bk$8e1$1@fred.mathworks.com>...
>> how can we change dimension  inch to millimeter in matlab please help 
>> me for that

>> could you please give me syntax for that with example ?
> 
> lenmm=leninch*25.4;
> 
> I hope this wasn't a serious question...

That will not work properly, due to floating point round off error. 25.4 
is the exact conversion factor, by definition (I think it was the inch 
they redefined for this purpose), but 25.4 is not exactly representable 
in double precision. To get better precision, the original poster should 
multiply by 254, sprintf() that result to the desired accuracy in the 
desired format, and then use string manipulation to create the string 
that would result from dividing the value by 10.

<snip>
> That will not work properly, due to floating point round off error. 25.4 
> is the exact conversion factor, by definition (I think it was the inch 
> they redefined for this purpose), but 25.4 is not exactly representable 
> in double precision. To get better precision, the original poster should 
> multiply by 254, sprintf() that result to the desired accuracy in the 
> desired format, and then use string manipulation to create the string 
> that would result from dividing the value by 10.

I suppose if one's linear measurement is accurate to ~1e-16, then that would be one approach to take. Since I've never personally had the occasion to, say, measure the distance to the moon to a precision of 40 nm, I don't worry about it much. I suspect the OP falls into the same camp. :-)

Walter Roberson <roberson@hushmail.com> wrote:
> Mark Shore wrote:
>> "kunal  varaiya" <kvaraiya@gmail.com> wrote in message 
>> <hoq5bk$8e1$1@fred.mathworks.com>...
>>> how can we change dimension  inch to millimeter in matlab please help 
>>> me for that
> 
>>> could you please give me syntax for that with example ?
>> 
>> lenmm=leninch*25.4;
>> 
>> I hope this wasn't a serious question...
> 
> That will not work properly, due to floating point round off error. 25.4 
> is the exact conversion factor, by definition (I think it was the inch 
> they redefined for this purpose), but 25.4 is not exactly representable 
> in double precision. To get better precision, the original poster should 

Get used to it- you don't get exact floating point values on a digital
computer no matter what you do. Multiplying by 10 and rounding won't
change this since you still get the same resolution as defined by IEEE
64-bit floating point standard.

Besides- not relevant since there's virtually no possible distance
measurement that you can make with 15 significant figures anyhow,
so more than double-precision pretty much becoems a "don't care"

Stan 

Mark Shore wrote:
> <snip>
>> That will not work properly, due to floating point round off error. 
>> 25.4 is the exact conversion factor, by definition (I think it was the 
>> inch they redefined for this purpose), but 25.4 is not exactly 
>> representable in double precision.

> I suppose if one's linear measurement is accurate to ~1e-16, then that 
> would be one approach to take. Since I've never personally had the 
> occasion to, say, measure the distance to the moon to a precision of 40 
> nm, I don't worry about it much. I suspect the OP falls into the same 
> camp. :-)

Best not to get the original poster started with bad programming habits, 
though, or the next thing you know they'll be complaining that there 
must be a Matlab bug because converting back doesn't equal same value 
they started with...

Stan Bischof wrote:
> Walter Roberson <roberson@hushmail.com> wrote:

>> That will not work properly, due to floating point round off error. 25.4 
>> is the exact conversion factor, by definition (I think it was the inch 
>> they redefined for this purpose), but 25.4 is not exactly representable 
>> in double precision.

> Get used to it- you don't get exact floating point values on a digital
> computer no matter what you do. Multiplying by 10 and rounding won't
> change this since you still get the same resolution as defined by IEEE
> 64-bit floating point standard.

I suggested using 254 as the multiplier and then fudging the printed output. 
254 *is* exactly representable in double precision.

> Besides- not relevant since there's virtually no possible distance
> measurement that you can make with 15 significant figures anyhow,
> so more than double-precision pretty much becoems a "don't care"

It's about 11.57 days of counting caesium 133 transitions on an atomic clock, 
an error of about 33 1/2 transitions per year. It is my understanding that 
there is some work for which that kind of error is meaningful and undesirable.

On the other hand, it does seem to me likely that if you _are_ working at that 
kind of precision, then probably the original distance measurements would be 
in metric. Though since the imperial vs metric problem crashed the Mars 
lander, I no longer rely on common sense in international science :(

Stan Bischof wrote:

> Get used to it- you don't get exact floating point values on a digital
> computer no matter what you do. Multiplying by 10 and rounding won't
> change this since you still get the same resolution as defined by IEEE
> 64-bit floating point standard.

 >> 25.4 * 3  - 76.2
ans =
       -1.4210854715202e-14

 >> (254 * 3) / 10 - 76.2
ans =
      0


No change, eh?

Walter Roberson <roberson@hushmail.com> wrote in message <hoqv46$9a5$1@canopus.cc.umanitoba.ca>...
> Stan Bischof wrote:
> 
> > Get used to it- you don't get exact floating point values on a digital
> > computer no matter what you do. Multiplying by 10 and rounding won't
> > change this since you still get the same resolution as defined by IEEE
> > 64-bit floating point standard.
> 
>  >> 25.4 * 3  - 76.2
> ans =
>        -1.4210854715202e-14
> 
>  >> (254 * 3) / 10 - 76.2
> ans =
>       0
> 
> 
> No change, eh?

-or- luck, maybe(?)...
because in this ...particular... instance, it works both ways...

     25.4*4-101.6
%    ans = 0
     (254*4)/10-101.6
%    ans = 0

us

us wrote:
> Walter Roberson <roberson@hushmail.com> wrote in message 

>>  >> 25.4 * 3  - 76.2
>> ans =
>>        -1.4210854715202e-14
>>
>>  >> (254 * 3) / 10 - 76.2
>> ans =
>>       0

> -or- luck, maybe(?)...
> because in this ...particular... instance, it works both ways...
> 
>     25.4*4-101.6
> %    ans = 0
>     (254*4)/10-101.6
> %    ans = 0

3 of the 10 single-digit multipliers will show this kind of round-off error: 
3, 6, and 7.

23 of the two-digit multipliers will have the round-off error, 253 of the 
three-digit, 2104 of the 4 digit, 20760 of the 5 digit, 246027 of the 6 digit.

We cannot calculate the probability of a round-off error because the length of 
the inputs are not uniformly randomly chosen, but I think it would be safe to 
say that the probability of a round-off problem exceeds 21% if the inches are 
input in whole numbers.

Walter Roberson <roberson@hushmail.com> wrote in message <hoqj29$kvh$1@canopus.cc.umanitoba.ca>...
>
> 
> That will not work properly, due to floating point round off error. 25.4 
> is the exact conversion factor, by definition (I think it was the inch 
> they redefined for this purpose), but 25.4 is not exactly representable 
> in double precision. To get better precision, the original poster should 
> multiply by 254, sprintf() that result to the desired accuracy in the 
> desired format, and then use string manipulation to create the string 
> that would result from dividing the value by 10.

But Walter, even if you *think* you do better by multiplying 254 and divide by 10, your argument is still flawed. Face it: when a float number is multiplied by whole number 254, there is right there a round-off error. So your method is subjected to successive two round-off errors (the second is when divided by 10). Why it's better than multiplying directly with 25.4 (which also have two sources of errors)?

Much ado about nothing. Multiplying with 25.4 should be fine.

Bruno

Bruno Luong wrote:
> Walter Roberson <roberson@hushmail.com> wrote in message 
> <hoqj29$kvh$1@canopus.cc.umanitoba.ca>...

>> That will not work properly, due to floating point round off error. 
>> 25.4 is the exact conversion factor, by definition (I think it was the 
>> inch they redefined for this purpose), but 25.4 is not exactly 
>> representable in double precision. To get better precision, the 
>> original poster should multiply by 254, sprintf() that result to the 
>> desired accuracy in the desired format, and then use string 
>> manipulation to create the string that would result from dividing the 
>> value by 10.

> But Walter, even if you *think* you do better by multiplying 254 and 
> divide by 10, your argument is still flawed. Face it: when a float 
> number is multiplied by whole number 254, there is right there a 
> round-off error. So your method is subjected to successive two round-off 
> errors (the second is when divided by 10).

My method doesn't actually divide by 10: it manipulates the string so that the 
output has the appearance of division by 10. Or to look at it another way, the 
division by 10 is done in indefinite precision base 10 arithmetic rather than 
in fixed precision base 2 arithmetic.

Suppose the input was a number that did not have round-off when represented in 
double precision -- i.e., an integer, or an integer divided by a power of 2 
(up to 2^52). Then, multiplying by 254 does not introduce any round-off error 
(unless the number was greater than about 2^45), and converting to string 
would not introduce any round off error (if done correctly and fully), and 
then manipulating the string would not introduce any round-off error. In this 
case, there would have been no round off error anywhere in the process.

If, however, one multiplies by 25.4 and does not go through the string 
manipulation, then there round-off error in representing the 25.4, and that 
round-off error will propagate in the multiplication. That's at least one 
round-off error instead of 0 round-off errors, up to 2^45.

Walter Roberson <roberson@hushmail.com> wrote in message <hor4vb$hv2$1@canopus.cc.umanitoba.ca>...

> 
> My method doesn't actually divide by 10: it manipulates the string so that the 
> output has the appearance of division by 10. Or to look at it another way, the 
> division by 10 is done in indefinite precision base 10 arithmetic rather than 
> in fixed precision base 2 arithmetic.

Wait a minute, did OP asked to write in decimal the conversion result???

Bruno

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <hor6b3$kmc$1@fred.mathworks.com>...
> Walter Roberson <roberson@hushmail.com> wrote in message <hor4vb$hv2$1@canopus.cc.umanitoba.ca>...
> 
> > 
> > My method doesn't actually divide by 10: it manipulates the string so that the 
> > output has the appearance of division by 10. Or to look at it another way, the 
> > division by 10 is done in indefinite precision base 10 arithmetic rather than 
> > in fixed precision base 2 arithmetic.
> 
> Wait a minute, did OP asked to write in decimal the conversion result???
> 
> Bruno

This may be unfair, but I don't think the OP had thought that far ahead, and that the original question was every bit as simple as it looked.

Mark Shore wrote:
> "Bruno Luong" <b.luong@fogale.findmycountry> wrote in message 
> <hor6b3$kmc$1@fred.mathworks.com>...

>> Wait a minute, did OP asked to write in decimal the conversion result???

> This may be unfair, but I don't think the OP had thought that far ahead, 
> and that the original question was every bit as simple as it looked.

Yeh, but then it wouldn't have been a Matlab question, so by the very fact 
that it was placed here, we need to discuss the details of how Matlab would 
deal with the conversion ;-) If the answer is "You can't do that in Matlab, 
you can only come up with a very close approximation in Matlab!" then the 
original poster needs to know :D