Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

2 views

Skip to first unread message

May 8, 2007, 5:44:22 PM5/8/07

to

While most 2D graphics output from Mathematica 6 now looks pretty

nice with anti-aliased drawing, I had been unimpressed with the

3D quality both in my own use and as shown in the "What's new in

6" web seminar. Specifically the fact that no anti-aliasing appears

to be done and the edges of surfaces and axis lines and lables are

quite "jaggy".

nice with anti-aliased drawing, I had been unimpressed with the

3D quality both in my own use and as shown in the "What's new in

6" web seminar. Specifically the fact that no anti-aliasing appears

to be done and the edges of surfaces and axis lines and lables are

quite "jaggy".

Well, it turns out that you can probably fix this. Mathematica

appears to be using the 3D capabilities of your video card and the

card's own quality settings to do all the 3D rendering. I was

able to bring up the NVIDIA configuration program and add a set

of override settings for Mahtematica.exe and told it to turn all

the anti-aliasing and similar options up to their highest level.

Now I get smoothly rendered 3D surfaces and lines! In addition

when I save a notebook the saved copy of images take advantage

of the high quality so when someone opens the notebook the images

will look smooth (at least until they start to rotate or otherwise

recompute them) even if they don't have AA turned on.

There's a slight reduction in interaction speed when rotating 3D

images, but most Mathematica 3D graphs seem relatively simple in

terms of polygon count (compared to a modern 3D game say) and the

performance change isn't very noticeable (also you can adjust the

quality settings to choose the level of performance you want).

G.

May 9, 2007, 12:09:16 AM5/9/07

to

"Gavin Scott" <ga...@allegro.com> wrote in message

news:1341rpm...@news.supernews.com...

> While most 2D graphics output from Mathematica 6 now looks pretty

> nice with anti-aliased drawing,

One of the most important things for me, which existed in Matlab for years

seems to be still missing in 2D plots in Mathematica, which is the following

simple task:

The ability to select a region on the plot using the mouse and zoom into

that area.

This is VERY important. Many times one wants to examine a small area on the

plot in more details, instead of having to mug up again with the command

used to make the original plot, and change some parameters and make a new

plot which shows in more details the region of interest, in Matlab one

simply uses the mouse to zoom in, then zoom out again when done.

I am amazed such an important feature is still missing in Mathematica after

all these years.

Another problem I noticed with 2D. Make a plot, say

Plot[Sin[x], {x, -Pi, Pi}]

Now select it, and pick up the a corner edge and shrink down the plot to

make it smaller and smaller.

Noticed something? the tick numbers on the axis do not shrink !, they remain

in large fonts. This means not everything in the plot shrinks in same

proportions.

Other than that, yes 2D plots now look smoother than before.

Nasser

May 9, 2007, 6:04:19 AM5/9/07

to

> One of the most important things for me, which existed in Matlab for years

> seems to be still missing in 2D plots in Mathematica, which is the following

> simple task:

>

> The ability to select a region on the plot using the mouse and zoom into

> that area.

>

> This is VERY important. Many times one wants to examine a small area on the

> plot in more details, instead of having to mug up again with the command

> used to make the original plot, and change some parameters and make a new

> plot which shows in more details the region of interest, in Matlab one

> simply uses the mouse to zoom in, then zoom out again when done.

> seems to be still missing in 2D plots in Mathematica, which is the following

> simple task:

>

> The ability to select a region on the plot using the mouse and zoom into

> that area.

>

> This is VERY important. Many times one wants to examine a small area on the

> plot in more details, instead of having to mug up again with the command

> used to make the original plot, and change some parameters and make a new

> plot which shows in more details the region of interest, in Matlab one

> simply uses the mouse to zoom in, then zoom out again when done.

There are lots of possible interface designs for graphics that you can

now implement relatively easily yourself. Here is a simplified version

of what you are requesting...

ClickZoomShow[gr_Graphics] :=

DynamicModule[{pr = PlotRange /. Options[gr, PlotRange]},

Dynamic[EventHandler[

Show[gr,

PlotRange -> pr],

{"MouseClicked" :> (pr = {(pr[[1]] +

MousePosition["Graphics"][[1]])/2,

(pr[[2]] +

MousePosition["Graphics"][[2]])/2})

}]]]

Use it like this...

ClickZoomShow[Plot[Sin[1/x] x, {x, -1, 1}]]

Now each click on the graphic will zoom towards that point.

You could adapt this to a better version by regenerating the plot each

time, as zooming does not produce any more detail, only lets you look

closer. This would be even more important in Matlab which does not

have adaptive plot sampling like Mathematica, so unless you have

chosen a very high sample rate at the start you would quickly run out

of detail.

May 9, 2007, 9:20:23 AM5/9/07

to

Jon McLoone wrote:

> ClickZoomShow[gr_Graphics] :=

> DynamicModule[{pr = PlotRange /. Options[gr, PlotRange]},

> Dynamic[EventHandler[

> Show[gr,

> PlotRange -> pr],

> {"MouseClicked" :> (pr = {(pr[[1]] +

> MousePosition["Graphics"][[1]])/2,

> (pr[[2]] +

> MousePosition["Graphics"][[2]])/2})

> }]]]

>

> ClickZoomShow[gr_Graphics] :=

> DynamicModule[{pr = PlotRange /. Options[gr, PlotRange]},

> Dynamic[EventHandler[

> Show[gr,

> PlotRange -> pr],

> {"MouseClicked" :> (pr = {(pr[[1]] +

> MousePosition["Graphics"][[1]])/2,

> (pr[[2]] +

> MousePosition["Graphics"][[2]])/2})

> }]]]

>

> You could adapt this to a better version by regenerating the plot each

> time, as zooming does not produce any more detail...Wow. I can't believe you can't zoom in to a 2D plot in Mathematica to see

the detail. You guys should really put that into 6.1.

We're working on a graphical library for the F# language from Microsoft:

http://www.ffconsultancy.com/products/fsharp_for_visualization/

I'll make sure that functionality goes in...

--

Dr Jon D Harrop, Flying Frog Consultancy

The F#.NET Journal

http://www.ffconsultancy.com/products/fsharp_journal/?usenet

May 9, 2007, 12:39:47 PM5/9/07

to

The approach of regenerating the function to increase detail is

potentially problematic as a standard behaviour unless your are only

visualizing elementary functions. Most examples of this feature that I

have seen have been in "graphing calculator" software.

If the function was dependant on some data set that has changed, or

was the result of a random process, or a record of a specific system

state at the time, it is not clear whether you want the function as it

was then or as it would be now? Getting more detail might, in some

cases, require re-running the process. What do you do if it is

expensive to calculate? What if the person holding the document with

the plot does not have access to the code that created it?

The typical set of assumptions might well deal with most cases but

will always render other valid cases inaccessible, so being able to

choose the kind of interaction you want rather than have it is imposed

is still important -- if it is easy to do.

Here is the simplest set of assumptions: zoom to the origin,

recalculating the function from scratch...

Manipulate[Plot[Sin[1/x] x, {x, -1/n, 1/n}], {n, 1, 100}]

May 10, 2007, 8:06:50 PM5/10/07

to

Jon McLoone wrote:

> If the function was dependant on some data set that has changed, or

> was the result of a random process, or a record of a specific system

> state at the time, it is not clear whether you want the function as it

> was then or as it would be now?

> If the function was dependant on some data set that has changed, or

> was the result of a random process, or a record of a specific system

> state at the time, it is not clear whether you want the function as it

> was then or as it would be now?

The evaluation semantics for Mathematica's Plot function are undefined. So

the user is already at fault if they provided an impure function to be

plotted.

> Getting more detail might, in some cases, require re-running the process.

Yes.

> What do you do if it is expensive to calculate?

The same thing you do every other time: make the user wait. If you're really

interested in performance, put a high-performance compiler into

Mathematica.

> What if the person holding the document with

> the plot does not have access to the code that created it?

This is the primary advantage of using a rewrite system like Mathematica:

you can re-evaluate an expression using different semantics (e.g.

precision). Competitors (e.g. me) can't do this because they're using

statically-resolved compiled languages, so I'd expect this to be leveraged

as much as possible by WRI.

> The typical set of assumptions might well deal with most cases but

> will always render other valid cases inaccessible, so being able to

> choose the kind of interaction you want rather than have it is imposed

> is still important -- if it is easy to do.

Worst case, the zoomed version will be different (random data) or will take

about the same time to plot as the original. Either way, the user only

suffers if they choose to zoom and the plot was only wrong if the user made

a mistake.

May 10, 2007, 9:36:45 PM5/10/07

to

Jon Harrop wrote:

> Jon McLoone wrote:

>> If the function was dependant on some data set that has changed, or

>> was the result of a random process, or a record of a specific system

>> state at the time, it is not clear whether you want the function as it

>> was then or as it would be now?

>

> The evaluation semantics for Mathematica's Plot function are undefined. So

> the user is already at fault if they provided an impure function to be

> plotted.

> Jon McLoone wrote:

>> If the function was dependant on some data set that has changed, or

>> was the result of a random process, or a record of a specific system

>> state at the time, it is not clear whether you want the function as it

>> was then or as it would be now?

>

> The evaluation semantics for Mathematica's Plot function are undefined. So

> the user is already at fault if they provided an impure function to be

> plotted.

RTFM: http://reference.wolfram.com/mathematica/ref/Plot.html

In particular read up on Options->{PlotPoints, MaxRecursion,

MeshFunctions}. These are not new to version 6.

The rest of your points have similar counterpoints.

Please quit marketing your F- "language" on usenet. For many of us,

your continued off-topic hype is causing negative impressions.

-DH

May 11, 2007, 3:40:03 AM5/11/07

to

D Herring wrote:

> Jon Harrop wrote:

>> Jon McLoone wrote:

>>> If the function was dependant on some data set that has changed, or

>>> was the result of a random process, or a record of a specific system

>>> state at the time, it is not clear whether you want the function as it

>>> was then or as it would be now?

>>

>> The evaluation semantics for Mathematica's Plot function are undefined.

>> So the user is already at fault if they provided an impure function to be

>> plotted.

>

> RTFM: http://reference.wolfram.com/mathematica/ref/Plot.html

> In particular read up on Options->{PlotPoints, MaxRecursion,

> MeshFunctions}. These are not new to version 6.

> Jon Harrop wrote:

>> Jon McLoone wrote:

>>> If the function was dependant on some data set that has changed, or

>>> was the result of a random process, or a record of a specific system

>>> state at the time, it is not clear whether you want the function as it

>>> was then or as it would be now?

>>

>> The evaluation semantics for Mathematica's Plot function are undefined.

>> So the user is already at fault if they provided an impure function to be

>> plotted.

>

> RTFM: http://reference.wolfram.com/mathematica/ref/Plot.html

> In particular read up on Options->{PlotPoints, MaxRecursion,

> MeshFunctions}. These are not new to version 6.

I cannot see any definition of the evaluation semantics (the order of

evaluation).

May 11, 2007, 1:57:59 PM5/11/07

to

On May 11, 9:40 am, Jon Harrop <j...@ffconsultancy.com> wrote:

> D Herring wrote:

> > Jon Harrop wrote:

> >> Jon McLoone wrote:

> >>> If the function was dependant on some data set that has changed, or

> >>> was the result of a random process, or a record of a specific system

> >>> state at the time, it is not clear whether you want the function as it

> >>> was then or as it would be now?

>

> >> The evaluation semantics for Mathematica's Plot function are undefined.

> >> So the user is already at fault if they provided an impure function to be

> >> plotted.

>

> > RTFM:http://reference.wolfram.com/mathematica/ref/Plot.html

> > In particular read up on Options->{PlotPoints, MaxRecursion,

> > MeshFunctions}. These are not new to version 6.

>

> I cannot see any definition of the evaluation semantics (the order of

> evaluation).

> D Herring wrote:

> > Jon Harrop wrote:

> >> Jon McLoone wrote:

> >>> If the function was dependant on some data set that has changed, or

> >>> was the result of a random process, or a record of a specific system

> >>> state at the time, it is not clear whether you want the function as it

> >>> was then or as it would be now?

>

> >> The evaluation semantics for Mathematica's Plot function are undefined.

> >> So the user is already at fault if they provided an impure function to be

> >> plotted.

>

> > RTFM:http://reference.wolfram.com/mathematica/ref/Plot.html

> > In particular read up on Options->{PlotPoints, MaxRecursion,

> > MeshFunctions}. These are not new to version 6.

>

> I cannot see any definition of the evaluation semantics (the order of

> evaluation).

What do you mean by the "order of evaluation"? Plot[] takes one

function to be evaluated several times.

May 11, 2007, 2:33:24 PM5/11/07

to

Oh, I see. Your probably mean that for x1 < x2 it is not guaranteed

that that f[x1] is evaluated before f[x2] when Plot[]-ting f. In v5.2

you can ensure that f is evaluated with predictable arguments by using

PlotDivision -> 1.

May 11, 2007, 11:01:34 PM5/11/07

to

SzH wrote:

> Oh, I see. Your probably mean that for x1 < x2 it is not guaranteed

> that that f[x1] is evaluated before f[x2] when Plot[]-ting f.

> Oh, I see. Your probably mean that for x1 < x2 it is not guaranteed

> that that f[x1] is evaluated before f[x2] when Plot[]-ting f.

Exactly, yes.

> In v5.2

> you can ensure that f is evaluated with predictable arguments by using

> PlotDivision -> 1.

You mean it happens to work in 5.2 but, without a formal definition of the

evaluation semantics, there is no guarantee that it will continue to work

in that way in the future. So it would be a bad idea to write code that

relied upon it.

There is nothing wrong with leaving things undefined like this. In this

case, it allows WRI to implement better adaptive plotting algorithms in the

future.

My objection is simply that Jon McLoone was essentially saying that

already-broken code would break if they added zooming.

I don't think there is anything contentious here and I was surprised to see

DH give such a rude response...

May 12, 2007, 10:10:04 AM5/12/07

to

Jon Harrop wrote:

> D Herring wrote:

>> Jon Harrop wrote:

>>> Jon McLoone wrote:

>>>> If the function was dependant on some data set that has changed, or

>>>> was the result of a random process, or a record of a specific system

>>>> state at the time, it is not clear whether you want the function as it

>>>> was then or as it would be now?

>>> The evaluation semantics for Mathematica's Plot function are undefined.

>>> So the user is already at fault if they provided an impure function to be

>>> plotted.

>> RTFM: http://reference.wolfram.com/mathematica/ref/Plot.html

>> In particular read up on Options->{PlotPoints, MaxRecursion,

>> MeshFunctions}. These are not new to version 6.

>

> I cannot see any definition of the evaluation semantics (the order of

> evaluation).

> D Herring wrote:

>> Jon Harrop wrote:

>>> Jon McLoone wrote:

>>>> If the function was dependant on some data set that has changed, or

>>>> was the result of a random process, or a record of a specific system

>>>> state at the time, it is not clear whether you want the function as it

>>>> was then or as it would be now?

>>> The evaluation semantics for Mathematica's Plot function are undefined.

>>> So the user is already at fault if they provided an impure function to be

>>> plotted.

>> RTFM: http://reference.wolfram.com/mathematica/ref/Plot.html

>> In particular read up on Options->{PlotPoints, MaxRecursion,

>> MeshFunctions}. These are not new to version 6.

>

> I cannot see any definition of the evaluation semantics (the order of

> evaluation).

Ahh. For that you probably want ListPlot.

http://reference.wolfram.com/mathematica/ref/ListPlot.html

ListPlot is the moral equivalent of Matlab's plot command; the user has

complete control over how the lists are filled.

Another solution is to construct an InterpolatingFunction from the

original data and pass that to Plot.

http://reference.wolfram.com/mathematica/ref/InterpolatingFunction.html

- DH

P.S. Rude? My previous reply was overly harsh... but you do have a

tendency to post factual errors with an authoritative tone and then

segue into how your system fixes such problems.

May 14, 2007, 5:23:54 AM5/14/07

to

> My objection is simply that Jon McLoone was essentially saying that

> already-broken code would break if they added zooming.

Not a fair summary of my comments.

I provided a zooming function (although I overlooked that you can

already do this in Mathematica by holding the ctrl key, dragging the

graphic frame to the region of interest, releasing the ctrl key, and

dragging the frame back again). And indicated that it would be easy

enough to do a version that re-called the function.

My comments were that automatically re-calling the original generator

code, however large, slow, non-deterministic, proprietary or absent it

might be, is not necessarily something that you want to happen

automatically every time and it might be wiser if the plot creator

made a decision about whether this is the behaviour they want to

provide to the consumer of their plot.

May 14, 2007, 8:03:03 PM5/14/07

to

Jon McLoone wrote:

>> My objection is simply that Jon McLoone was essentially saying that

>> already-broken code would break if they added zooming.

>

> Not a fair summary of my comments.

>> My objection is simply that Jon McLoone was essentially saying that

>> already-broken code would break if they added zooming.

>

> Not a fair summary of my comments.

Then I misunderstood

> My comments were that automatically re-calling the original generator

> code, however large, slow, non-deterministic, proprietary or absent it

> might be, is not necessarily something that you want to happen

> automatically every time and it might be wiser if the plot creator

> made a decision about whether this is the behaviour they want to

> provide to the consumer of their plot.

I think that would be fine for a default behaviour. Especially considering

users can precompute an interpolating function so easily in Mathematica.

0 new messages

Search

Clear search

Close search

Google apps

Main menu