LOCAL and INPUT: number of variables allowed

[Eddie W. Shore]

Someone recently emailed me that he ran into trouble with a program because LOCAL and INPUT had more than 2 variables.

I don't recall LOCAL and INPUT had the limitation of 2 in the past. Does anyone remember when had this restriction in past software versions?

[Tim Wessman]

The limit is 8.

If it is erring with less, they are attempting to use a reserved system word like "e" or "i" most likely.

[cyrille de brébisson]

Hello,

The limit for any function parameter count is 16. ie, no function can take more than 16 parameters...

LOCAL is a function that takes n pairs of parameters. The first item in each pair is a variable name and the 2nd the variable initialization value (0 by default if not provided).

As a result, LOCAL is limited to 8 (16/2) simultaneous definitions.

INPUT, as a function, is also limited to 16 parameters. BUT since the variables are put in a single list, and since thee list size limit is 10 000, there is no practical limits to the number of variables that INPUT can handle.

Cyrille

[Han]

(06-26-2017 05:38 AM)cyrille de brébisson Wrote:  Hello,

The limit for any function parameter count is 16. ie, no function can take more than 16 parameters...

LOCAL is a function that takes n pairs of parameters. The first item in each pair is a variable name and the 2nd the variable initialization value (0 by default if not provided).

As a result, LOCAL is limited to 8 (16/2) simultaneous definitions.

INPUT, as a function, is also limited to 16 parameters. BUT since the variables are put in a single list, and since thee list size limit is 10 000, there is no practical limits to the number of variables that INPUT can handle.

Cyrille

Perhaps I misunderstand what is meant by no practical limits, but INPUT is indeed limited to 10 screens worth of parameters. Thus, if you put one parameter per screen row, then you are limited to 70 variables. Of course, you can put more variables per row and thus increase the total number of parameters. However, at some point legibility becomes an issue (too many input fields per row) and then you are truly indeed limited from a practical point of view.

[cyrille de brébisson]

Hello,

You are quite right, I completely forgot that they was a limit on the number of inputs in an input!
See corresponding line of code:
if (l>7*10) return &HPERInvalidInput; // are you freaking kidding me????

Obviously, I thought that should INPUT be called with more than 70 inputs, they was most likely something quite wrong!

It is often a balancing act between trusting the inputs from the programmer and detecting potentially incorrect ones!

Do you have a realistic case where 70 is not enough?

Cyrille

[Han]

(06-27-2017 04:55 AM)cyrille de brébisson Wrote:  Hello,

You are quite right, I completely forgot that they was a limit on the number of inputs in an input!
See corresponding line of code:
if (l>7*10) return &HPERInvalidInput; // are you freaking kidding me????

Obviously, I thought that should INPUT be called with more than 70 inputs, they was most likely something quite wrong!

It is often a balancing act between trusting the inputs from the programmer and detecting potentially incorrect ones!

Do you have a realistic case where 70 is not enough?

Cyrille

The equation library app I wrote has a screen that allows users to choose which system of equations they wish to delete. I believe there are 102 systems in the current implementation. As a workaround I have simply created "pages". I used INPUT so that I could have multiple check boxes. Each system gets its own entry line since users could in theory have a very long title for the system of equations.