Re: Re: From PaddedForm to numbers?
- To: mathgroup at smc.vnet.net
- Subject: [mg80583] Re: [mg80514] Re: From PaddedForm to numbers?
- From: DrMajorBob <drmajorbob at bigfoot.com>
- Date: Sun, 26 Aug 2007 03:14:40 -0400 (EDT)
- References: <faj6fp$9gt$1@smc.vnet.net> <fajn99$pb1$1@smc.vnet.net> <32842021.1187938132627.JavaMail.root@m35>
- Reply-to: drmajorbob at bigfoot.com
> If the standard comment were changed to something like " . . . affects
> printing, but not evaluation *of the expression inside the wrapper*"
Better to delete the comment entirely. There's no way to rescue it.
I think what they usually mean, in effect, is that First@anyWrapper@x ==
x. That's USEFUL INFORMATION, at least.
It's also true for any function that remains unevaluated at the argument.
First@Cos@x == x, for instance, if x is undefined or exact (but not if x
is Real). Hence one way of rewriting the comment might be
"...affects display but remains unevaluated."
But that's not transparently correct either, since
NumberForm[7,1,NumberPadding->{"0",""}]
%
gives this output:
07
7
But also
NumberForm[7,1,NumberPadding->{"0",""}];
%
07
(The wrapper goes away in the process of display, so both examples make
sense... if you hold your mouth right.)
So... six years on, I have little idea what they mean by "wrapper", except
that it warns me to figure out each situation as it comes. And that's not
so hard, really, so long as we don't take Help literally.
> x=7; PaddedForm[x, 3, NumberForm->{"0",""} ]
> produces 0007 -- which doesn't match my naive interpretation of "padding
> something out to three significant figures"
Amen to that, too. But now you know what to expect, and all it took was
trying it.
Bobby
On Fri, 24 Aug 2007 00:55:45 -0500, AES <siegman at stanford.edu> wrote:
> In article <fajn99$pb1$1 at smc.vnet.net>,
> David Bailey <dave at Remove_Thisdbailey.co.uk> wrote:
>
>> PaddedForm is a wrapper - like MatrixForm, and many others. WRI have a
>> standard comment in relation to these - "PaddedForm acts as a â??wrapperâ??,
>> which affects printing, but not evaluation."
>>
>> The wording of this has always seemed to me unfortunate, because if you
>> leave wrapper round an object it looks OK, but can't be incorporated in
>> a further calculation - in other words a wrapper certainly does affect
>> evaluation!
>
> Amen. Been caught by this repeatedly with TableForm -- especially if
> it's something like Table[ - - lengthy expression - - ]//TableForm.
>
> If the standard comment were changed to something like " . . . affects
> printing, but not evaluation *of the expression inside the wrapper*",
> you'd at least.
>
> By the way, if my test in 5.2 the other day was correct,
>
> x=7; PaddedForm[x, 3, NumberForm->{"0",""} ]
>
> produces 0007 -- which doesn't match my naive interpretation of "padding
> something out to three significant figures", especially since it
> expresses x = 7777 correctly as *four* significant figures. (It doesn't
> make James Bond very happy either).
>
>
--
DrMajorBob at bigfoot.com