Post Reply 
I may have discovered a bug in the input function...
09-08-2017, 10:37 AM
Post: #1
I may have discovered a bug in the input function...
The type for integer in the input command is 1. Real number type is 0.
If I create an input box of type 0, I can enter 25, for example, and it'll be accepted, as will 25.5.
However, if I create an input box of type 1, I cannot enter 25. I have to enter #25d to enter an integer. It SHOULD accept 25, and not accept 25.5. i.e. It should know that without the #, it's decimal. The way it's set up now, I can't stop someone from entering 2.5 (a real number with a fractional part) unless I force them to use #2d type input.

The other comment I have to add, is that it's not intuitive to have the value I'm typing not appearing in real time inside the box as I'm typing. Currently it appears on the input line on the bottom of the screen, which is counterintuitive.
Is there currently a way to do it properly like all other forms in the universe?
i.e. The comment on the bottom acts like a mini-help, and that's fine, but the input should appear in the box itself, not at the bottom of the screen...

Thanks
-Donald
Find all posts by this user
Quote this message in a reply
09-08-2017, 01:15 PM
Post: #2
RE: I may have discovered a bug in the input function...
(09-08-2017 10:37 AM)webmasterpdx Wrote:  The type for integer in the input command is 1. Real number type is 0.
If I create an input box of type 0, I can enter 25, for example, and it'll be accepted, as will 25.5.
However, if I create an input box of type 1, I cannot enter 25. I have to enter #25d to enter an integer. It SHOULD accept 25, and not accept 25.5. i.e. It should know that without the #, it's decimal. The way it's set up now, I can't stop someone from entering 2.5 (a real number with a fractional part) unless I force them to use #2d type input.

The other comment I have to add, is that it's not intuitive to have the value I'm typing not appearing in real time inside the box as I'm typing. Currently it appears on the input line on the bottom of the screen, which is counterintuitive.
Is there currently a way to do it properly like all other forms in the universe?
i.e. The comment on the bottom acts like a mini-help, and that's fine, but the input should appear in the box itself, not at the bottom of the screen...

Thanks
-Donald

I don't think it's a bug. It's just that 25 (with or without a decimal point) is a real number to the Prime. The only way Prime identifies integers is if they're expressed in a base system (10, 16, 8, 2) This may not be a good way to do it but it's the way the Prime is set up. It's by design and not a bug.

Tom L
Cui bono?
Find all posts by this user
Quote this message in a reply
09-08-2017, 04:23 PM
Post: #3
RE: I may have discovered a bug in the input function...
But in mathematics, 25 is considered an integer. 25.0 is real.
Find all posts by this user
Quote this message in a reply
09-09-2017, 02:56 AM
Post: #4
RE: I may have discovered a bug in the input function...
(09-08-2017 04:23 PM)webmasterpdx Wrote:  But in mathematics, 25 is considered an integer. 25.0 is real.

In HP Prime integers are always defined with the # prefix, and it is not possible to write them with decimals (#25.5d error!), a casting from real to integer is not assumed.

Viga C | TD | FB
Visit this user's website Find all posts by this user
Quote this message in a reply
09-09-2017, 04:01 AM
Post: #5
RE: I may have discovered a bug in the input function...
There is a huge difference between "integers" in Home and in CAS.

In Home, an "integer" has a "#" sign in front of it, and is displayed in the current base (decimal, hex, octal, or binary). Without the "#" sign, all numbers are reals, whether they have a decimal point or not.

In CAS, an "integer" is any number without a decimal point in it. They are always displayed in base 10. A real (AKA a "float") is any number with a decimal point in it, even if it has no fractional part. Numbers with "#" in front are not allowed in CAS. If typed, they are converted immediately to CAS integers.

To make matters even more complicated, there is a difference between the TYPE() and type() commands in CAS, and the values returned by type() differ between CAS and Home.

CAS: TYPE(123) --> 0.
CAS: type(123) --> DOM_INT
CAS: type(123)+0. --> 2.
CAS: TYPE(123.4) --> 0.
CAS: type(123.4) --> DOM_FLOAT
CAS: type(123.4)+0. --> 1.

Home: The above all return 0.
Home: TYPE(#123) --> 1
Home: type(#123) --> 1

Home integers are limited in size by the current wordsize setting. The largest possible wordsize setting is 64, so integers greater than 2^64-1 are not possible in Home.

CAS integers, on the other hand, can be huge, up to a maximum of 2^8599-1, and they can be either positive or negative.

<0|ΙΈ|0>
-Joe-
Visit this user's website Find all posts by this user
Quote this message in a reply
03-03-2022, 11:00 AM
Post: #6
RE: I may have discovered a bug in the input function...
Are integers significantly faster in execution speed compared to floats?

-Dream of Omnimaga
https://djomnimaga.music-2000.com
Visit this user's website Find all posts by this user
Quote this message in a reply
03-04-2022, 03:48 PM
Post: #7
RE: I may have discovered a bug in the input function...
Short integers (<2^31) are fast (comparable to floats), otherwise long integers are slow.
BTW, you can enter integers in base 16 with 0x prefix and in base 2 with 0b prefix.
Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 1 Guest(s)