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=...