Insufficient Memory for MAKEMAT(0,320,240)

[matalog]

I was trying to make a little graphics program, and have the calculator keep track of the pixels on screen, so I tried M1:=MAKEMAT(0,320,240) thinking that it wouldn't be a problem, but the calculator (G2) reported insufficient memory.

I imagined this would be 320x240 = 76,800 bytes for 8 bit numbers, maybe 76,800 x 5 for larger numbers. What is the initial expectation for the type of numbers in a Matrix?

Is there a way to be able to keep track of the numbers associated with each 320x240 pixels, I only need room for a 9 bit number really, so 16 bits would be fine.

The Hp Prime G2 has 256 MiB RAM or 268,435,456 bytes so I didn't expect this to be a problem.

Is M1:=MAKEMAT(0,320,240) the wrong way to use this?

[StephenG1CMZ]

Matrices are of a limited size.
A workaround would be to use a list of lists (each list can have 10 000 elements).
Or, perhaps storing the data as a screen image might be useful?
This program lists implementation limits.
https://www.hpmuseum.org/forum/thread-13...hlight=Ppl
(AFAIK the implementation limits were not increased from G1 to G2 models, despite the hardware improvements)

If you really want to use matrices, you could reduce the resolution.

Matrices must have less than 20 000 elements, so for example a (320/2) * (240/2) matrix would be possible.

[C.Ret]

(09-17-2022 12:57 PM)matalog Wrote:  I was trying to make a little graphics program, and have the calculator keep track of the pixels on screen, [...]

Why didn't you use a GROB object and the dedicated functions build-in your HP Prime to do this exact task?

Storing the whole screen in the graphical object G1 is as easy as a BLIT(G1,G0).

[matalog]

(09-17-2022 01:37 PM)StephenG1CMZ Wrote:  Matrices are of a limited size.
A workaround would be to use a list of lists (each list can have 10 000 elements).
Or, perhaps storing the data as a screen image might be useful?
This program lists implementation limits.
https://www.hpmuseum.org/forum/thread-13...hlight=Ppl
(AFAIK the implementation limits were not increased from G1 to G2 models, despite the hardware improvements)

If you really want to use matrices, you could reduce the resolution.

Matrices must have less than 20 000 elements, so for example a (320/2) * (240/2) matrix would be possible.

Thanks I was able to do what I needed by writing a false colour pixel to G1 and reading back from it with GETPIX.

[jte]

(09-17-2022 12:57 PM)matalog Wrote:  ⋮
I tried M1:=MAKEMAT(0,320,240)
⋮
I imagined this would be 320x240 = 76,800 bytes for 8 bit numbers, maybe 76,800 x 5 for larger numbers. What is the initial expectation for the type of numbers in a Matrix?

The per-element memory use is 8 bytes (for real matrices); there’s also a little bit of fixed per-matrix overhead (for matrix dimensions, type, etc.). Matrices hold floating-point values (of the same floating-point arithmetic as the built-in variables).

[Will Gibson]

(09-17-2022 01:37 PM)StephenG1CMZ Wrote:  Matrices are of a limited size.
A workaround would be to use a list of lists (each list can have 10 000 elements).
Or, perhaps storing the data as a screen image might be useful?
This program lists implementation limits.
https://www.hpmuseum.org/forum/thread-13...hlight=Ppl
(AFAIK the implementation limits were not increased from G1 to G2 models, despite the hardware improvements)

If you really want to use matrices, you could reduce the resolution.

Matrices must have less than 20 000 elements, so for example a (320/2) * (240/2) matrix would be possible.

I also wanted to have a large matrix on my HP Prime G2. Your list of lists idea is working for me. Thanks! A list of matrices also works.