Coordinates for plotting

1 view
Skip to first unread message

Waldek Hebisch

unread,
May 3, 2023, 10:47:58 AM5/3/23
to fricas...@googlegroups.com
Our documentation says that 3D coordinate transformations take
'z' coordinate first, that is for plotting function values
is first, followed by arguments. But if we plot with no
coordinate transformation, than "normal" order is in use,
that is arguments first, function value last. Documentation
also claims that default coordinate transformation is
'cartesian'. But things above contradic this. Compare

draw(sin(x), x=0..2)

with

draw(sin(x), x=0..2, coordinates==cartesian)

You can see that compared to default setting giving 'cartesian'
swaps coordinates.

I must say that result of current setting looks strange, essentialy
like a bug. But given documentation and extra code needed this
behavour must be deliberte. Can anybody give reasons for
current behaviour?

There is also another thing: when given option 'polar' our code
treat treats argument and function as giving polar coordinates
and transforms this to cartesion. However, I understand "drawing
curve in polar coordinates" as producting curve in cartesian
coordinates and then transforming this to polar coordinates, that
is reverse of transformation our code is doing.

One way to make this clearer would be to have functions like
'polar_to_cartesian' (our current 'polar') and 'cartesian_to_polar'
(we do not have it now). But I somewhat dislike so long names.

--
Waldek Hebisch

68th

unread,
May 4, 2023, 4:02:45 AM5/4/23
to fricas...@googlegroups.com

------- Original Message -------


On Wednesday, May 3rd, 2023 at 7:48 PM, Waldek Hebisch de...@fricas.math.uni.wroc.pl wrote:

Documentation
also claims that default coordinate transformation is
'cartesian'. But things above contradic this. Compare

draw(sin(x), x=0..2)

with

draw(sin(x), x=0..2, coordinates==cartesian)

You can see that compared to default setting giving 'cartesian'
swaps coordinates.

I must say that result of current setting looks strange, essentialy
like a bug.

it's a bug to me.

There is also another thing: when given option 'polar' our code
treat treats argument and function as giving polar coordinates
and transforms this to cartesion.

that's right. you can transform one pair of coordinates from the polar or elliptic coordinate system to the Cartesian one. i guess that's what polar(pt) and elliptic(a) functions from the CoordinateSystems package do.

However, I understand "drawing
curve in polar coordinates" as producting curve in cartesian
coordinates and then transforming this to polar coordinates, that
is reverse of transformation our code is doing.

what do you mean by producing a curve? how is that different from the above-mentioned transformation of coordinates? why do you need to transform the Cartesian coordinates back to the polar ones? i guess the program needs Cartesian coordinates to make a plot.

Waldek Hebisch

unread,
May 4, 2023, 5:57:33 PM5/4/23
to '68th' via FriCAS - computer algebra system
On Thu, May 04, 2023 at 08:02:38AM +0000, '68th' via FriCAS - computer algebra system wrote:
> On Wednesday, May 3rd, 2023 at 7:48 PM, Waldek Hebisch de...@fricas.math.uni.wroc.pl wrote:
>
> > There is also another thing: when given option 'polar' our code
> > treat treats argument and function as giving polar coordinates
> > and transforms this to cartesion.
>
> that's right. you can transform one pair of coordinates from the polar or elliptic coordinate system to the Cartesian one. i guess that's what polar(pt) and elliptic(a) functions from the CoordinateSystems package do.
>
> > However, I understand "drawing
> > curve in polar coordinates" as producting curve in cartesian
> > coordinates and then transforming this to polar coordinates, that
> > is reverse of transformation our code is doing.
>
> what do you mean by producing a curve?

Here by curve I mean set of points. Of course normally such sets
are infinite so we need some internal representation (which for
plotting is only approximate).

> how is that different from the above-mentioned transformation of coordinates?

Curve is an abstract object which exist independenty of any coordinates.
To draw it we use coordinates, so we need to compute coordinates of
points. So "drawing curve in polar coordinates" means that we need
to compute polar coordinates of each point, and draw pixel with
computed coordinates (again this for each point of curve).

As I wrote above, we need some way to represent curves and points.
We use coordinates for this, this time cartesion coordinates.

That is why "drawing in polar coordinates" involves transformation
from cartesion coordiantes to polar coordinates.

--
Waldek Hebisch

68th

unread,
May 5, 2023, 3:29:03 PM5/5/23
to fricas...@googlegroups.com
------- Original Message -------

On Thursday, May 4th, 2023 at 8:02 AM, 68th <68...@proton.me> wrote:

------- Original Message -------
On Wednesday, May 3rd, 2023 at 7:48 PM, Waldek Hebisch de...@fricas.math.uni.wroc.pl wrote:

Documentation
also claims that default coordinate transformation is
'cartesian'. But things above contradic this. Compare

draw(sin(x), x=0..2)

with

draw(sin(x), x=0..2, coordinates==cartesian)

You can see that compared to default setting giving 'cartesian'
swaps coordinates.

I must say that result of current setting looks strange, essentialy
like a bug.

it's a bug to me.

it's not a bug, it's a feature. see 7.2.7 Coordinate System Transformations:

The option coordinates == cartesian directs FriCAS to treat the dependent variable ... as the x coordinate.
Reply all
Reply to author
Forward
0 new messages