Re: IntegerPart
- To: mathgroup at smc.vnet.net
- Subject: [mg130309] Re: IntegerPart
- From: Bill Rowe <readnews at sbcglobal.net>
- Date: Tue, 2 Apr 2013 03:27:08 -0400 (EDT)
- Delivered-to: l-mathgroup@mail-archive0.wolfram.com
- Delivered-to: l-mathgroup@wolfram.com
- Delivered-to: mathgroup-newout@smc.vnet.net
- Delivered-to: mathgroup-newsend@smc.vnet.net
On 4/1/13 at 12:58 AM, dougwangsaif at gmail.com wrote:
>can anyone help with this. There seems to be something wrong with
>the IntegerPart function. Please help!
>Clear["Global`*"] nSize = 100;
>prefstate = Table[0, {i, 1, nSize}]; Do[
>{prefstate[[i]] = If[EvenQ[i], 0.8, 0.4]}, {i, 1, nSize}
>];
>Plot[{prefstate[[IntegerPart[x]]]}, {x, 1, nSize + 1},
>AxesOrigin -> {0, 0}, TicksStyle -> Directive[18], PlotStyle ->
>{Black}]
No, the issue isn't with IntegerPart. Instead it is the sampling
routine used by Plot. To see this is the case, force Plot to
sample with higher resolution. That is
Plot[{prefstate[[IntegerPart[x]]]}, {x, 1, nSize + 1},
AxesOrigin -> {0, 0}, TicksStyle -> Directive[18],
PlotStyle -> {Black}, PlotPoints -> 150]
will generate the plot you were expecting.
A couple of other things you might want to be aware of.
There is no point to doing Do[....]; since the return value from
Do is (Null)
A more efficient way to generate prefstate would be
prefstate=Table[If[EvenQ@n, 0.8, 0.4],{n, nSize}]
There is no need to initialize prefstate with 0's prior to
setting it to alternating values.
But if you are going to use initialize prefstate and use an
explicit Do loop, the following produces the same result for
prefstate but will run faster
prefstate={};
Do[
prefstate={prefstate, If[EvenQ@n, 0.8, 0.4]},{n, nSize}];
prefstate=Flatten@prefstate;
Notice here there is a point to doing Do[...];prefstate=...