I may have discovered a bug in the input function...

09082017, 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 minihelp, and that's fine, but the input should appear in the box itself, not at the bottom of the screen... Thanks Donald 

09082017, 01:15 PM
Post: #2




RE: I may have discovered a bug in the input function...
(09082017 10:37 AM)webmasterpdx Wrote: The type for integer in the input command is 1. Real number type is 0. 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? 

09082017, 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.


09092017, 02:56 AM
Post: #4




RE: I may have discovered a bug in the input function...
(09082017 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 

09092017, 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^641 are not possible in Home. CAS integers, on the other hand, can be huge, up to a maximum of 2^85991, and they can be either positive or negative. <0ΙΈ0> Joe 

« Next Oldest  Next Newest »

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