“We are doomed”
https://www.carette.xyz/posts/we_are_doomed/

“The only system with a good software compatibility that I know is
Windows, and this explains a ton of things keeping very old UI/UX
frameworks, software and APIs to run, for example, Windows 95 compatible
games like “Roller Coaster Tycoon”.”

“Otherwise, you are doomed.”

The C++ committee has screwed up and continues to screw up by not
creating a graphics standard for C++.

Lynn

On 16/01/2024 22:03, Lynn McGuire wrote:
> “We are doomed”
>    https://www.carette.xyz/posts/we_are_doomed/
>
> “The only system with a good software compatibility that I know is
> Windows, and this explains a ton of things keeping very old UI/UX
> frameworks, software and APIs to run, for example, Windows 95 compatible
> games like “Roller Coaster Tycoon”.”
>
> “Otherwise, you are doomed.”
>
> The C++ committee has screwed up and continues to screw up by not
> creating a graphics standard for C++.
>
> Lynn
One problem that could be very easily fixed is that there is no standard
representation of a point or a vector. Whilst generally it's just a POD
structure with x and y members, the name varies, and sometimes the
dimensions are referred to by index instead of by letter. You can also
have a philosophical discussion about whether points and vectors should
be the same structures or incompatible structures.
But a simple standardisation would mean the end of pointless editing of
code just to conform to whatever the host program has chosen.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 2024-01-19, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> One problem that could be very easily fixed is that there is no standard
> representation of a point or a vector. Whilst generally it's just a POD
> structure with x and y members, the name varies, and sometimes the

For code working with 2D vectors, designers should consider complex numbers.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 1/19/2024 10:17 AM, Malcolm McLean wrote:
> On 16/01/2024 22:03, Lynn McGuire wrote:
>> “We are doomed”
>>     https://www.carette.xyz/posts/we_are_doomed/
>>
>> “The only system with a good software compatibility that I know is
>> Windows, and this explains a ton of things keeping very old UI/UX
>> frameworks, software and APIs to run, for example, Windows 95
>> compatible games like “Roller Coaster Tycoon”.”
>>
>> “Otherwise, you are doomed.”
>>
>> The C++ committee has screwed up and continues to screw up by not
>> creating a graphics standard for C++.
>>
>> Lynn
> One problem that could be very easily fixed is that there is no standard
> representation of a point or a vector. Whilst generally it's just a POD
> structure with x and y members, the name varies, and sometimes the
> dimensions are referred to by index instead of by letter. You can also
> have a philosophical discussion about whether points and vectors should
> be the same structures or incompatible structures.
> But a simple standardisation would mean the end of pointless editing of
> code just to conform to whatever the host program has chosen.

Fwiw, I am very fond of the following header only library:

https://github.com/g-truc/glm

Works great and makes it rather straightforward to port to GLSL shaders.
I basically use it everyday for stuff like:

https://youtu.be/KRkKZj9s3wk

On 19/01/2024 18:35, Kaz Kylheku wrote:
> On 2024-01-19, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>> One problem that could be very easily fixed is that there is no standard
>> representation of a point or a vector. Whilst generally it's just a POD
>> structure with x and y members, the name varies, and sometimes the
>
> For code working with 2D vectors, designers should consider complex numbers.
>
That's a nice idea.

But I've never seen code where the horizontal axis is "real" and the
vertical "imaginary", except of course in code designed to demonstrate
complex numbers as such. Mandelbrot is my favourite test program when
getting a new system.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 1/20/2024 5:59 AM, Malcolm McLean wrote:
> On 19/01/2024 18:35, Kaz Kylheku wrote:
>> On 2024-01-19, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>>> One problem that could be very easily fixed is that there is no standard
>>> representation of a point or a vector. Whilst generally it's just a POD
>>> structure with x and y members, the name varies, and sometimes the
>>
>> For code working with 2D vectors, designers should consider complex
>> numbers.
>>
> That's a nice idea.
>
> But I've never seen code where the horizontal axis is "real" and the
> vertical "imaginary", except of course in code designed to demonstrate
> complex numbers as such. Mandelbrot is my favourite test program when
> getting a new system.
>

Same here! :^D

On 2024-01-20, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> On 19/01/2024 18:35, Kaz Kylheku wrote:
>> On 2024-01-19, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>>> One problem that could be very easily fixed is that there is no standard
>>> representation of a point or a vector. Whilst generally it's just a POD
>>> structure with x and y members, the name varies, and sometimes the
>>
>> For code working with 2D vectors, designers should consider complex numbers.
>>
> That's a nice idea.
>
> But I've never seen code where the horizontal axis is "real" and the
> vertical "imaginary", except of course in code designed to demonstrate
> complex numbers as such. Mandelbrot is my favourite test program when
> getting a new system.

Complex numbers are used for expressing mappings that have geometric
interpretations.

In 2D computer graphics, they are convenient. E.g. to rotate
a vector that is a complex number z = a + ib, you just multiply by
a complex number that is on the unit circle representing that
angle cos(theta) + i sin(theta) .

The multiplication math is exactly the same as

[ cos -sin ] [ a ]
[ sin cos ] [ b ]

Because when you multiply two complex nubmers (c + id)(a + ib),
the FOIL rule produces

ca + icb + ida + iidb

= (ca - db) + i(cb + da).

And that's just

[ c -d ] [ a ] = [ ca - db ]
[ d c ] [ b ] = [ da + cb ]

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 1/19/24 19:17, Malcolm McLean wrote:
> One problem that could be very easily fixed is that there is no standard
> representation of a point or a vector. Whilst generally it's just a POD
> structure with x and y members, the name varies, and sometimes the
> dimensions are referred to by index instead of by letter. You can also
> have a philosophical discussion about whether points and vectors should
> be the same structures or incompatible structures.
> But a simple standardisation would mean the end of pointless editing of
> code just to conform to whatever the host program has chosen.

And what should be the data type of the coefficients of the vector? And
what should? Why not also have matrices? What is the maximum dimension
supported? Are homogeneous coordinates a built-in feature? No, leave the
graphics stuff to a graphics team.

On 22/01/2024 00:22, immibis wrote:
> On 1/19/24 19:17, Malcolm McLean wrote:
>> One problem that could be very easily fixed is that there is no
>> standard representation of a point or a vector. Whilst generally it's
>> just a POD structure with x and y members, the name varies, and
>> sometimes the dimensions are referred to by index instead of by
>> letter. You can also have a philosophical discussion about whether
>> points and vectors should be the same structures or incompatible
>> structures.
>> But a simple standardisation would mean the end of pointless editing
>> of code just to conform to whatever the host program has chosen.
>
> And what should be the data type of the coefficients of the vector? And
> what should? Why not also have matrices? What is the maximum dimension
> supported? Are homogeneous coordinates a built-in feature? No, leave the
> graphics stuff to a graphics team.
It should take a template, so any type can be used for the coefficients.
Unless you have some weird and wonderful ideas, it will of course be
scalar.
I'd recommend a 2D with x and y and a 3D with x, y and z. Humanity is
not going to be elevated to a higher dimension any time soon. No
homogenous co-ordinates. No angle / magnitude notation. No need for
matrices because we already have a natural representation of the these,
since C++ supports 2 dimensional fixed size array.
Needing to store points in 2D or 3D space is a common requirement, and
code needs to communicate with other modules. One of which will be the
graphics system, which may well have requirements beyond simple points
in space, but will include such a requirement.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 21/01/2024 04:06, Kaz Kylheku wrote:
> On 2024-01-20, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>> On 19/01/2024 18:35, Kaz Kylheku wrote:
>>> On 2024-01-19, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>>>> One problem that could be very easily fixed is that there is no standard
>>>> representation of a point or a vector. Whilst generally it's just a POD
>>>> structure with x and y members, the name varies, and sometimes the
>>>
>>> For code working with 2D vectors, designers should consider complex numbers.
>>>
>> That's a nice idea.
>>
>> But I've never seen code where the horizontal axis is "real" and the
>> vertical "imaginary", except of course in code designed to demonstrate
>> complex numbers as such. Mandelbrot is my favourite test program when
>> getting a new system.
>
> Complex numbers are used for expressing mappings that have geometric
> interpretations.
>
> In 2D computer graphics, they are convenient. E.g. to rotate
> a vector that is a complex number z = a + ib, you just multiply by
> a complex number that is on the unit circle representing that
> angle cos(theta) + i sin(theta) .
>
> The multiplication math is exactly the same as
>
> [ cos -sin ] [ a ]
> [ sin cos ] [ b ]
>
> Because when you multiply two complex nubmers (c + id)(a + ib),
> the FOIL rule produces
>
> ca + icb + ida + iidb
>
> = (ca - db) + i(cb + da).
>
> And that's just
>
> [ c -d ] [ a ] = [ ca - db ]
> [ d c ] [ b ] = [ da + cb ]
>
Yes I know. I did complex numbers at high school.

But whilst you could use the Argand plane as your graphics surface and
thus represent all points as complex numbers, I've never actually seen
anyone do so, and the axes are always given different labels. Except of
course in Mandelbrots or other programs concerned with complex numbers
themselves.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

Op 22.jan.2024 om 12:16 schreef Malcolm McLean:
> On 22/01/2024 00:22, immibis wrote:
>> On 1/19/24 19:17, Malcolm McLean wrote:
>>> One problem that could be very easily fixed is that there is no
>>> standard representation of a point or a vector. Whilst generally it's
>>> just a POD structure with x and y members, the name varies, and
>>> sometimes the dimensions are referred to by index instead of by
>>> letter. You can also have a philosophical discussion about whether
>>> points and vectors should be the same structures or incompatible
>>> structures.
>>> But a simple standardisation would mean the end of pointless editing
>>> of code just to conform to whatever the host program has chosen.
>>
>> And what should be the data type of the coefficients of the vector?
>> And what should? Why not also have matrices? What is the maximum
>> dimension supported? Are homogeneous coordinates a built-in feature?
>> No, leave the graphics stuff to a graphics team.
> It should take a template, so any type can be used for the coefficients.
> Unless you have some weird and wonderful ideas, it will of course be
> scalar.
> I'd recommend a 2D with x and y and a 3D with x, y and z. Humanity is
> not going to be elevated to a higher dimension any time soon. No
> homogenous co-ordinates. No angle / magnitude notation. No need for
> matrices because we already have a natural representation of the these,
> since C++ supports 2 dimensional fixed size array.
> Needing to store points in 2D or 3D space is a common requirement, and
> code needs to communicate with other modules. One of which will be the
> graphics system, which may well have requirements beyond simple points
> in space, but will include such a requirement.

According to Einstein, humanity lives already in a four dimensional
space; time is the fourth dimension.
There are many problems in physics and other fields with even more than
4 dimensions, so it would be short-sighted to limit the library to 3
dimensions.
In addition one could ask how far the standard library must go. What
operations must be supported? Calculate the length of a vector, allowing
non-Euclidian spaces?

On 22/01/2024 11:34, Fred. Zwarts wrote:
> Op 22.jan.2024 om 12:16 schreef Malcolm McLean:
>> On 22/01/2024 00:22, immibis wrote:
>>> On 1/19/24 19:17, Malcolm McLean wrote:
>>>> One problem that could be very easily fixed is that there is no
>>>> standard representation of a point or a vector. Whilst generally
>>>> it's just a POD structure with x and y members, the name varies, and
>>>> sometimes the dimensions are referred to by index instead of by
>>>> letter. You can also have a philosophical discussion about whether
>>>> points and vectors should be the same structures or incompatible
>>>> structures.
>>>> But a simple standardisation would mean the end of pointless editing
>>>> of code just to conform to whatever the host program has chosen.
>>>
>>> And what should be the data type of the coefficients of the vector?
>>> And what should? Why not also have matrices? What is the maximum
>>> dimension supported? Are homogeneous coordinates a built-in feature?
>>> No, leave the graphics stuff to a graphics team.
>> It should take a template, so any type can be used for the
>> coefficients. Unless you have some weird and wonderful ideas, it will
>> of course be scalar.
>> I'd recommend a 2D with x and y and a 3D with x, y and z. Humanity is
>> not going to be elevated to a higher dimension any time soon. No
>> homogenous co-ordinates. No angle / magnitude notation. No need for
>> matrices because we already have a natural representation of the
>> these, since C++ supports 2 dimensional fixed size array.
>> Needing to store points in 2D or 3D space is a common requirement, and
>> code needs to communicate with other modules. One of which will be the
>> graphics system, which may well have requirements beyond simple points
>> in space, but will include such a requirement.
>
> According to Einstein, humanity lives already in a four dimensional
> space; time is the fourth dimension.
> There are many problems in physics and other fields with even more than
> 4 dimensions, so it would be short-sighted to limit the library to 3
> dimensions.
> In addition one could ask how far the standard library must go. What
> operations must be supported? Calculate the length of a vector, allowing
> non-Euclidian spaces?
No-one is saying that you can't devise your own structures if you want
to write programs to solve problems in general relativity. The idea is
to have a common standard for the common requirement to represent pints
and vectors in 2d and 3d spaces, so that routines writen in C++ can
communicate with each other without the need for adapter code or rewriting.
However having decided on a representation for points, there is also a
very strong case for a standard library for basic operations on those
points, such as taking the length of a vector. However probably not
non-Euclidian spaces. Again, some people will want to write software
that operates in Hilbert space or other non-Euclidean space, but it's
likely to be specialised, and so you can't expect much support from the
standard library.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 1/22/2024 3:22 AM, Malcolm McLean wrote:
> On 21/01/2024 04:06, Kaz Kylheku wrote:
>> On 2024-01-20, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>>> On 19/01/2024 18:35, Kaz Kylheku wrote:
>>>> On 2024-01-19, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>>>>> One problem that could be very easily fixed is that there is no
>>>>> standard
>>>>> representation of a point or a vector. Whilst generally it's just a
>>>>> POD
>>>>> structure with x and y members, the name varies, and sometimes the
>>>>
>>>> For code working with 2D vectors, designers should consider complex
>>>> numbers.
>>>>
>>> That's a nice idea.
>>>
>>> But I've never seen code where the horizontal axis is "real" and the
>>> vertical "imaginary", except of course in code designed to demonstrate
>>> complex numbers as such. Mandelbrot is my favourite test program when
>>> getting a new system.
>>
>> Complex numbers are used for expressing mappings that have geometric
>> interpretations.
>>
>> In 2D computer graphics, they are convenient. E.g. to rotate
>> a vector that is a complex number z = a + ib, you just multiply by
>> a complex number that is on the unit circle representing that
>> angle   cos(theta) + i sin(theta) .
>>
>> The multiplication math is exactly the same as
>>
>>    [ cos -sin ] [ a ]
>>    [ sin  cos ] [ b ]
>>
>> Because when you multiply two complex nubmers (c + id)(a + ib),
>> the FOIL rule produces
>>
>>     ca + icb + ida + iidb
>>    = (ca - db) + i(cb + da).
>>
>> And that's just
>>
>>    [ c  -d ] [ a ]  =  [ ca - db ]
>>    [ d   c ] [ b ]  =  [ da + cb ]
>>
> Yes I know. I did complex numbers at high school.
>
> But whilst you could use the Argand plane as your graphics surface and
> thus represent all points as complex numbers, I've never actually seen
> anyone do so, and the axes are always given different labels. Except of
> course in Mandelbrots or other programs concerned with complex numbers
> themselves.

Usually a vector, say 2-ary (x, y), x is the horizontal axis and y is
the vertical axis. This matches a complex number x + yi:

+y
|
-x--0--+x
|
-y

x is real, y is imaginary. :^)

On 1/22/2024 3:16 AM, Malcolm McLean wrote:
> On 22/01/2024 00:22, immibis wrote:
>> On 1/19/24 19:17, Malcolm McLean wrote:
>>> One problem that could be very easily fixed is that there is no
>>> standard representation of a point or a vector. Whilst generally it's
>>> just a POD structure with x and y members, the name varies, and
>>> sometimes the dimensions are referred to by index instead of by
>>> letter. You can also have a philosophical discussion about whether
>>> points and vectors should be the same structures or incompatible
>>> structures.
>>> But a simple standardisation would mean the end of pointless editing
>>> of code just to conform to whatever the host program has chosen.
>>
>> And what should be the data type of the coefficients of the vector?
>> And what should? Why not also have matrices? What is the maximum
>> dimension supported? Are homogeneous coordinates a built-in feature?
>> No, leave the graphics stuff to a graphics team.
> It should take a template, so any type can be used for the coefficients.
> Unless you have some weird and wonderful ideas, it will of course be
> scalar.
> I'd recommend a 2D with x and y and a 3D with x, y and z. Humanity is
> not going to be elevated to a higher dimension any time soon. No
> homogenous co-ordinates. No angle / magnitude notation. No need for
> matrices because we already have a natural representation of the these,
> since C++ supports 2 dimensional fixed size array.
> Needing to store points in 2D or 3D space is a common requirement, and
> code needs to communicate with other modules. One of which will be the
> graphics system, which may well have requirements beyond simple points
> in space, but will include such a requirement.

And 4-ary with (x, y, z, w)

Again I am quite fond of the GLM library. It's just nice to me.

On 22/01/24 12:16, Malcolm McLean wrote:
> On 22/01/2024 00:22, immibis wrote:
>> On 1/19/24 19:17, Malcolm McLean wrote:
>>> One problem that could be very easily fixed is that there
>>> is no standard representation of a point or a vector.
>>> Whilst generally it's just a POD structure with x and y
>>> members, the name varies, and sometimes the dimensions
>>> are referred to by index instead of by letter. You can
>>> also have a philosophical discussion about whether points
>>> and vectors should be the same structures or incompatible
>>> structures.
>>> But a simple standardisation would mean the end of
>>> pointless editing of code just to conform to whatever the
>>> host program has chosen.
>>
>> And what should be the data type of the coefficients of
>> the vector? And what should? Why not also have matrices?
>> What is the maximum dimension supported? Are homogeneous
>> coordinates a built-in feature? No, leave the graphics
>> stuff to a graphics team.
> It should take a template, so any type can be used for the
> coefficients. Unless you have some weird and wonderful
> ideas, it will of course be scalar.
> I'd recommend a 2D with x and y and a 3D with x, y and z.
> Humanity is not going to be elevated to a higher dimension
> any time soon. No homogenous co-ordinates. No angle /
> magnitude notation. No need for matrices because we already
> have a natural representation of the these, since C++
> supports 2 dimensional fixed size array.
> Needing to store points in 2D or 3D space is a common
> requirement, and code needs to communicate with other
> modules. One of which will be the graphics system, which may
> well have requirements beyond simple points in space, but
> will include such a requirement.

Looking at the variety of image formats, I tend to think
that the coordinate system and RAM representation is still
the least of the problems, and that colour space
representation (bits depths, order, endianness, transparency
support) could be even worse.
Also, at some point, every library has to interact with the
OS to load/unload images into the display driver, which is
at best posix-copliant, but still depends a lot on the OS
internals.

Graphics that wont' show up on screen is not very appealing
or useful.
Here a lot of graphic SW had to be rewritten migrating from
X to Wayland.

So RAM representation is really the least hard part. The
worse is how to load/save a variety of formats to/from disk,
and how to display the results on screen. How to move large
block of pixels avoinding flickering, etc

Since external libraries handle all this, it's not that
difficult to have also its own RAM representation of pixels,
vectors and geometry.
I think that creating a standard for this won't solve the
other main problems.

--
1) Resistere, resistere, resistere.
2) Se tutti pagano le tasse, le tasse le pagano tutti
MarioCPPP