HPGCC3 - symbolic matrix vs array

[multilingualtricker]

Hello!

Don't know if anyone has any suggestions on this issue?
Am getting better at making programs on HPGCC3 (many thanks to Gjermund for this)

HPGCC3 seems to only like arrays (type 3) rather than symbolic matrices (type 29)

Quite often I want it to operate on arrays that have the occasional NAN (not a number) in them which invariably turns the object into a type 29.

What I wanted to know is, is there some replacement for NAN that I could use which would maintain the type 3 status of the array, but would not get involved in the maths in HPGCC3? (e.g. when calculating the average of numbers in a column)

The other solution is to get rid of NANs in a wrapper and then feed into HPGCC3, but this throws up problems of it's own e.g. the columns of the matrix might not maintain equal length etc.

Many thanks!

p.s. just on the subject of HPGCC3, has anyone noticed that this program causes the TICKS to run backwards (i.e. the latter tick ends up being before the initial tick somehow??)

[DavidM]

(08-14-2016 12:25 PM)multilingualtricker Wrote:  p.s. just on the subject of HPGCC3, has anyone noticed that this program causes the TICKS to run backwards (i.e. the latter tick ends up being before the initial tick somehow??)

Can't help with the first part of your post, but the TICKS issue is already known.

It's not a result of HPGCC3, but rather the general operation of the ARM-based systems. The underlying ARM O/S is continually making corrections to the emulated system clock tick count in an effort to keep it somewhat rational. The RTC in the CPU is only capable of supplying time to a resolution of 1 sec, so the ARM O/S tries to simulate a tick count as best it can under current operating conditions (battery condition and temperature have been shown to effect the amount of correction needed at any given time). This can result in negative adjustments to the tick count, which is seen as "stepping back" in time.

Most users seldom run into this issue because the length of time between User RPL commands is usually too slow to encounter one of these "corrections". It does occasionally happen, however.

You are far more likely to run into this when you are running code which executes at a fast enough speed to check the system time at close intervals, which is likely what you are experiencing when running HPGCC3 code.

[multilingualtricker]

Hi DavidM,

Ah interesting! Thanks for the explanation!

[Claudio L.]

(08-14-2016 12:25 PM)multilingualtricker Wrote:  Hello!

Don't know if anyone has any suggestions on this issue?
Am getting better at making programs on HPGCC3 (many thanks to Gjermund for this)

HPGCC3 seems to only like arrays (type 3) rather than symbolic matrices (type 29)

Quite often I want it to operate on arrays that have the occasional NAN (not a number) in them which invariably turns the object into a type 29.

What I wanted to know is, is there some replacement for NAN that I could use which would maintain the type 3 status of the array, but would not get involved in the maths in HPGCC3? (e.g. when calculating the average of numbers in a column)

The other solution is to get rid of NANs in a wrapper and then feed into HPGCC3, but this throws up problems of it's own e.g. the columns of the matrix might not maintain equal length etc.

Many thanks!

p.s. just on the subject of HPGCC3, has anyone noticed that this program causes the TICKS to run backwards (i.e. the latter tick ends up being before the initial tick somehow??)

HPGCC3 only has support for numeric matrices, since algebraic objects involving functions would require that function to be written in C for evaluation. As an alternative, your code would have to drop back to RPL to eval the symbolic then go back into HPGCC3, losing the main advantage of working in C (a major overhead to get in and out of C).
Your only chance is either you code the symbolic handling yourself (it's not that hard), trying to simulate only the functions you need (let's say you only need SIN, COS, TAN, that's easy to detect and simulate), or simply write a wrapper that detects any anomalies in the matrix before you feed it to hpgcc3.

Another solution is: convert your matrix into a list of lists with AXL and use hpgcc3 list manipulation functions. You should be able to detect symbolic objects from within hpgcc3 and stop calculation then.

Regarding TICKS, the answer from DavidM is correct, as hpgcc3 prevents the RPL OS from properly updating its counters.