2010 Ti Nspire Faster than G2 HP Prime

[gastondefer]

What do you guys thing about this YouTube video?

https://youtube.com/shorts/KCZ4YaPcMl4?feature=share

Interestingly enough, my prime was considerably slower (more than 1:30s!) when I did the same operation for the 2nd or 3rd time. My G1s (A and C) were about 3 times faster than G2.

[jfelten]

That's strange. What's even more confusing is that when you simply input "(x^2+7x+4)^50" on the "Maximum" simplification setting, the calculator will output a result almost instantly, in noticeably less time than the Nspire.

[Jean-Baptiste Boric]

Two different CAS engines executing on two unrelated operating systems built with two separate toolchains running on top of two dissimilar hardware platforms have differing performance characteristics. Color me surprised.

I bet that there's one or more algorithms somewhere within the HP Prime that at the very least happen to have non-linear computational complexity in this particular case. It could be Giac itself, or a dependency, or a library, or any of the above in any combination at fault here. It doesn't matter if one calculator has a processor five times slower than the other, an O(n) algorithm on the slower machine will win against an O(n²) algorithm on the faster machine given a big enough n.

That the G1 is three times faster than the G2 in this benchmark is unexpected, but still... Despite the appearances they do not share the same operating system underneath, so it's yet more code that has potentially different performance characteristics between the two.

Discovering why exactly the HP Prime has a bad time with this input would probably require profiling its firmware. Maybe Giac happens to be the only component at fault here and profiling it on its own would reproduce the problem, but ultimately the only ones who have all the pieces to investigate this are those with full access to the HP Prime codebase.

[gastondefer]

(09-17-2022 06:55 PM)jfelten Wrote:  That's strange. What's even more confusing is that when you simply input "(x^2+7x+4)^50" on the "Maximum" simplification setting, the calculator will output a result almost instantly, in noticeably less time than the Nspire.

Oh wow! In literally milliseconds indeed; ain't that something! ? The Prime has to be the most interesting calculator of its time!

[gastondefer]

(09-17-2022 07:21 PM)Jean-Baptiste Boric Wrote:  Two different CAS engines executing on two unrelated operating systems built with two separate toolchains running on top of two dissimilar hardware platforms have differing performance characteristics. Color me surprised.

I bet that there's one or more algorithms somewhere within the HP Prime that at the very least happen to have non-linear computational complexity in this particular case. It could be Giac itself, or a dependency, or a library, or any of the above in any combination at fault here. It doesn't matter if one calculator has a processor five times slower than the other, an O(n) algorithm on the slower machine will win against an O(n²) algorithm on the faster machine given a big enough n.

That the G1 is three times faster than the G2 in this benchmark is unexpected, but still... Despite the appearances they do not share the same operating system underneath, so it's yet more code that has potentially different performance characteristics between the two.

Discovery why exactly the HP Prime has a bad time with this input would probably require profiling its firmware. Maybe Giac happens to be the only component at fault here and profiling it on its own would reproduce the problem, but ultimately the only ones who have all the pieces to investigate this are those with full access to the HP Prime codebase.

Absolutely mate! This makes me think of the Nspire Touchpad from 2010 with slower hardware, being slightly faster than the 2011 color screen model (both CAS and non CAS) in pretty much everything I threw at it! Though I strongly suspect the color LCD to be the cause in that particular case.

[parisse]

Everybody can look at the source code of giac and see what happens here, let me explain how. Untar the source code (https://www-fourier.univ-grenoble-alpes....stable.tgz), go to the src directory and run

Code:

grep at_expand *.cc

(all user commands have a corresponding at_-prefixed object defined in the C++ source).
There are a few lines returned, the interesting one is

Code:

lin.cc:  define_unary_function_ptr( at_expand ,alias_at_expand ,&__expand);

Therefore expand source code is located in lin.cc. Open lin.cc with your favorite text editor, and search at_expand, you'll see just above expand source code (most user commands have an equivalent C++ code with the same prototype and either the same name or the same name prefixed with _):

Code:


  gen expand(const gen & e,GIAC_CONTEXT){
    if (is_equal(e))
      return apply_to_equal(e,expand,contextptr);
    if (e.type==_SYMB && (e._SYMBptr->sommet==at_and || e._SYMBptr->sommet==at_ou)){
      ...
    }
   vector<const unary_function_ptr *> v;
    vector< gen_op_context > w;
    v.push_back(at_prod);
    v.push_back(at_pow);
    v.push_back(at_neg);
    w.push_back(&prod_expand);
    w.push_back(&expand_pow_expand);
    w.push_back(&expand_neg_expand);
    return _simplifier(subst(e,v,w,false,contextptr),contextptr);
  }

It means that expand is done by substitution of rational operators by expanding code for each operator. Then a quick look at prod_expand and expand_pow_expand will show you that expand is implemented by applying rules only (e.g. distribution rule of * vs +/-), it does not take advantage of the fact that the input is a univariate polynomial while the TI obviously does.
You can also see how the expansion is done step by step on this example, run from the giac directory

Code:

export CXXFLAGS=-g &&  ./configure && cd src && make

then open gdb on .libs/icas (icas is the name of the giac shell executable), set a breakpoint at giac::expand_pow_expand, and run from gdb console:

Code:

r 'expand((x^2+7x+4)^5)'

Now the conclusion is that expand on the Prime is *not* the equivalent of expand on the TI Nspire, in fact it should be compared to normal/simplify on the Prime, or more precisely to partfrac on the Prime (the expand commandname on the Nspire is a bit misleading, it does not only expand, but also does partial fraction expansion).
The Prime CAS has more options/commands than the TI Nspire CAS, which means that before drawing conclusions on a benchmark, one should dig a little bit. Since this will probably not happen, I have now modified giac source code accordingly, see:
https://github.com/geogebra/giac/commits/master
Unfortunately, I have no idea when the change will be released in a public Prime firmware...

[gastondefer]

(09-18-2022 07:50 AM)parisse Wrote:  Everybody can look at the source code of giac and see what happens here, let me explain how. Untar the source code (https://www-fourier.univ-grenoble-alpes....stable.tgz), go to the src directory and run

Code:

grep at_expand *.cc

(all user commands have a corresponding at_-prefixed object defined in the C++ source).
There are a few lines returned, the interesting one is

Code:

lin.cc:  define_unary_function_ptr( at_expand ,alias_at_expand ,&__expand);

Therefore expand source code is located in lin.cc. Open lin.cc with your favorite text editor, and search at_expand, you'll see just above expand source code (most user commands have an equivalent C++ code with the same prototype and either the same name or the same name prefixed with _):

Code:


  gen expand(const gen & e,GIAC_CONTEXT){
    if (is_equal(e))
      return apply_to_equal(e,expand,contextptr);
    if (e.type==_SYMB && (e._SYMBptr->sommet==at_and || e._SYMBptr->sommet==at_ou)){
      ...
    }
   vector<const unary_function_ptr *> v;
    vector< gen_op_context > w;
    v.push_back(at_prod);
    v.push_back(at_pow);
    v.push_back(at_neg);
    w.push_back(&prod_expand);
    w.push_back(&expand_pow_expand);
    w.push_back(&expand_neg_expand);
    return _simplifier(subst(e,v,w,false,contextptr),contextptr);
  }

It means that expand is done by substitution of rational operators by expanding code for each operator. Then a quick look at prod_expand and expand_pow_expand will show you that expand is implemented by applying rules only (e.g. distribution rule of * vs +/-), it does not take advantage of the fact that the input is a univariate polynomial while the TI obviously does.
You can also see how the expansion is done step by step on this example, run from the giac directory

Code:

export CXXFLAGS=-g &&  ./configure && cd src && make

then open gdb on .libs/icas (icas is the name of the giac shell executable), set a breakpoint at giac::expand_pow_expand, and run from gdb console:

Code:

r 'expand((x^2+7x+4)^5)'

Now the conclusion is that expand on the Prime is *not* the equivalent of expand on the TI Nspire, in fact it should be compared to normal/simplify on the Prime, or more precisely to partfrac on the Prime (the expand commandname on the Nspire is a bit misleading, it does not only expand, but also does partial fraction expansion).
The Prime CAS has more options/commands than the TI Nspire CAS, which means that before drawing conclusions on a benchmark, one should dig a little bit. Since this will probably not happen, I have now modified giac source code accordingly, see:
https://github.com/geogebra/giac/commits/master
Unfortunately, I have no idea when the change will be released in a public Prime firmware...

Thank you so very much for this in depth explanation; truly appreciated!