Create an account on the HP Community to personalize your profile and ask a question
01-30-2018 11:37 PM
Why is it impossible to enter a number greater than 1000 in the Start N box in the Sequence App? It is sometimes very useful to avoid the calculation of a complex expression for several thousands of elements.
Junging by the manual it must be a bug. The manual states that this value can be 0 or any positive number (p. 314) and that the HP Prime is able to represent numbers between 1E-499 and 9.99999999999E499 (p.23).
Solved! Go to Solution.
01-31-2018 10:35 AM
You have no recurring sequence defined. Please take a look at the sequence chapter for more info on how to use the application.
Although I work for the HP calculator group as a head developer of the HP Prime, the views and opinions I post here are my own.
01-31-2018 01:29 PM
It doesn't matter if you enter an explicit sequence or a recurring sequence or haven't entered any yet. You just can't set the starting N to a number greater than 1000. That's the problem.
The only thing I found in the manual was N could start at 1 (the default value), 0, or any positive integer. The manual stated it twice. So the same question still remains. Why is it prohibited to start a sequence from 1001, for example?
01-31-2018 11:36 PM
The manual is incorrect, N is limited to 1000.
The internal limitation is actually 65535 (because the number is stored as a 16 bit integer).
The main reason for the limit has to do with display. Now, why did I limit it to 1000 and not 999, I can honestly not remember.
The thinking at the time was that realistic starting points were usually way, way bellow these ranges.
The reason why this was implemented was because some countries mathematic tradition start at 0 and some at 1. At the time, I honnestly debated having only these 2 options, but it was easier to implement as a "user select" than a 0 or 1 choice, which is why it ended up that way.
Anyhow, I am interested in understanding why you need to start with numbers larger than 1000?
Note that in your case, since your sequence is not recursive, going to the plot or num view and setting the startup value at 10000 (or any other number) will not cause extra calculations as non recursive sequences are calculated directly.
The user of arbitrary start number also hits a "wall" as the maximum N is 32767 (N^15-1) as N is stored internally on a 16 bit signed integer (15 bit value + 1 bit sign). So there is no point in having N being able to be any number.
It is true that these implementation based restrictions might seems weired, but remember that the sequence app really is designed to handle classroom type recursive sequence study and where these limitations are not problematic at all.
In your case if you really want to study your function, the function APP is definitely the most appropriate.
02-02-2018 04:08 AM
Thank you for taking the time to post your elaborate and interesting explanations!
Perhaps I should have used another example. I find this setting very useful for recurrent sequences. It makes it possible to avoid calculating its first elements when, for example, you want to focus on the Ns where the sequence approaches its limit. It can save you a lot of time when you deal with complex sequences.
02-02-2018 04:35 AM
Internally, when the system detects a recusrive sequence, it will evaluate it "bottoms up". Meaning from 0 (or whatever start you specify) to N, N being the number that you are calculating.
Additionally, it will save the last 256 (from memory, I might be wrong on the exact number here) values that are calculated.
So, any 'forward' calculations will result in "optimized" calculations.
However, if you calculate U1(1000) and then ask for U1(100), U1(100) will force a recalc for N= all values from 0 to 100. While is you ask for U1(1010), only U1 for N=1001 to 1010 will be calculated.
If the sequence is non recusrsive, then it calculates it directly.
Hope this helps in optimizing your work.