# Tag Info

8

Possible workaround (tested on V9.0.1, Linux): just add VertexColors -> {Black} option. Without this option I get repeatPts[pt_, n_] := Line[ConstantArray[pt, n]] Graphics[{Thickness[.125], CapForm[cap], repeatPts[{0., 0.}, #], repeatPts[{1., 1.}, #]}, ImageSize -> 50, Frame -> True, FrameTicks -> None, PlotRangePadding -> .3] ...

8

Here is some evidence concerning what is going wrong. ff[arg : {(h : _)@___ ...}] := Row @ {h, " : ", arg} ff @ {u[x]} u : {u[x]} ff @ {{x}} List : {{x}} ff @ {{}} List : {{}} All the above show what one would expect, but ff @ {} {} : In this last case, I conclude that h has been matched with {} and arg has been matched with ...

8

When tracing other plots, I often saw that plotting-related functions compile their arguments when possible. A quick look at the trace of your example suggests the same, because the Exp function is used only for the evaluation of function. This seems to indicate that your second argument Exp[-9 t^2] was already compiled down and doesn't show up when the ...

7

The problem arises when function returns a number smaller than $MinMachineNumber: function[t_] := Exp[-9 t^2]; LogLogPlot[function[t], {t, 8.8718, 8.872}, PlotRange -> All, GridLines -> {{{Sqrt[Log[1/$MinMachineNumber]]/3, Directive[Thick, Dashed]}}, None}] Show[%, Ticks -> Automatic] For some reason LogLogPlot considers numbers smaller ...

5

Thanks for all your generous help. The wolfram technical support has just confirmed the issue originates from the first derivative of inverse Fourier transform. Actually D[u[x, t], x] should output InverseFourierTransform[I k U[k, t], k, x] rather than InverseFourierTransform[-I k U[k, t], k, x].

4

This seems to be a minor bug that shouldn't affect the functionality of PetersenGraph. The symbol has an incorrect SyntaxInformation. If it bothers you, you can (mostly) fix it by putting the following in your Kernel init.m: If[\$Version == 9.0, PetersenGraph; (* load symbol *) Unprotect[PetersenGraph]; SyntaxInformation[PetersenGraph] = ...

4

Here is a way in which ParallelMap works three times faster (V9.0.1, Mac OS, Intel i7, Quad core, 8 virtual cores). The trick is to evaluate dispatch = Dispatch@rules on each kernel. I don't really have an explanation, other than the guess that the dispatch table resides wholly in each kernel's memory and the observation that when rules are distributed, ...

3

In Mathematica 8.0.4 Rasterize[p] uses the default styles even without ImageSize. The workaround is to specify the stylesheet explicitly: p = Plot[x, {x, 0, 1}] stylesheet = First@Options[EvaluationNotebook[], StyleDefinitions]; Rasterize[Style[p, stylesheet]]

2

I brought this to the attention of the WRI tech support. This was their reply: I am writing to let you know that I have reported this bad behavior to our development team. I would also like to point out (if you were not aware) that the behavior you observed is even different between operating systems (for example, in Linux the points always appear, but ...

2

A bit of an obvoius hack but it does the job. repeatPts[pt_,n_] := (If[ Length@Tally[#] == 1 , {} , Line[#]] &@ ConstantArray[pt, n]) Graphics[{Thickness[.125], repeatPts[{0., 0.}, #], repeatPts[{1., 1.}, #]}, ImageSize -> 50, Frame -> True, FrameTicks -> None, PlotRangePadding -> .3] & /@ Range[5] .. a bit faster : If[ ...

2

With Mathematica version 9.0.1 I can get the result I wanted by specifying the ImageSize as a Graphics option, e.g. using Show, rather than using it as an option to Rasterize: Rasterize[Show[p, ImageSize -> 200]] Note that the labels are still at the size specified in the style sheet. Interestingly, the custom style is used if the graphic is ...

Only top voted, non community-wiki answers of a minimum length are eligible