LiveCode Forums.

While not that immediately important, i do feel the integer keyword should distinguish 1.0 from 1

Admittedly the value of this is limited but it is a potential source of error, so while low priority i consider this a bug and have filed a bug report.
If you agree, please see the bug report here: https://quality.livecode.com/show_bug.cgi?id=22892

Feel free to add a 'me too' reply -- i presume this increases visibility (just guessing...)

dunbarx wrote: Sun Sep 06, 2020 2:00 pm But then 003 would pass as an integer. By using "trunc", that oddity is removed, as well as ".".

In my mind 003 is both an integer and a 'whole number'. The '00' is the formatting of the number, not the type and it should just be a matter of formatting the number correctly. But it is an integer

Stam.

I disagree on this small point of a admittedly relatively unimportant issue. "003" is programmatically no different than "3.0". They are both formatted forms of what we think of as the concept of integers. It is not the decimal point, as opposed to leading zeros, that matter, it is our idea of what an integer is. It is all computer-think.

I am still waiting for anyone to find a scenario where it actually makes a difference, beyond the idea of formatting, either in data entry or in what is considered the "correct" form. Something like "3 + 4 <> 3.0 + 04"

Craig

I am very weak on formal mathematics. I don't know. Some of it I don't even understand, but in my simplistic view,
00000000001.0000000000000000000000000 is an integer.
00000000001.0000000000000000000000001 is very close, but not. The former is just a string representing a formatted version of 1 and the latter is a decimal representation of a non integer, also formatted as a string with leading zeroes.

In reply to you Craig, "3 + 4 = 3.0 + 04" (I believe that this is coincidentally how the LiveCode engine sees it).

I don't know what Hermann would think, he's probably within his rights to shoot me.

Hi Craig,
Fun philosophical discussion

For what it's worth i would argue that arithmetically 003 and 3.0 are the same, but programmatically these are not - not because there is a difference in mathematical value, but because of a difference in type of variable.

Imagine this scenario: You may receive data of unknown type from some process and stick it in a variable.
If the type of data is an integer (eg. 003, 052 or 111) then it signifies an error code.
If the type of data is a float (decimal, eg 0.001, 1.5, 3.8, or yes, 1.0 ) then it's the result of a computation.

Your introspection includes the code: If it's an integer - no problem, in this fictitious example you would act on the error code received.
But if this the value of a result, that say in this case could have been 1.1, 1.2, 1.5 but in this case returns 1.0, then that's a problem as integer returns true. Which means in this particular example your code would assess this as an error code, not a result value.

Arithmetically in LiveCode these are these are of course the same and it matters not when you perform arithmetic with these numbers. But if you have decisions based on type of data, this will lead to issues.

My issue is that the integer keyword fails to recognise this, which would be important in the above example (where you need to know the type of variable you're dealing with).
Many typed languages are clever and can infer the data type. In Swift, you can type As LiveCode is typeless language it of course doesn't make any difference when performing arithmetic (whereas in typed languages this would cause crashes), but if your decision making is based on data type, then the integer keyword failing this way is a problem...

LiveCode does an excellent job at shielding devs from many of the issues with data types, but there are tradeoffs, like in the example above.
There's a very nerdy write up on data types in programming languages on Wikipedia but i'm sure there are simpler resources online -- they would all say the same as above. But thankfully this doesn't really affect LiveCode coding in most circumstances.

As of LC 8.0 there is an "is strictly" operator.

value is strictly { nothing | a boolean | an integer | a real | a string | a binary string | an array }

Unfortunately I can not get it to work with integers. It probably reflects the internal state of LC or how it currently views value.
Maybe someone has more luck than I do.

Kind regards

@ Bernd.

Yes, "is strictly" fails with: No beeps.

@Stam
I agree.

Early on, I had mentioned that there might be cases where the formatting of either data input or output might matter., and therefore LC is far too loose about what an integer is. It is this sort of scenario, not when simply doing arithmetic, that may become an issue. In LC in particular, I think this sort of "app" might come up now and then.

LC needs a label warning of lark's vomit.

Glad you notified the team.

Craig

EDIT. When I wrote the code snippet I meant to imply that if the "strictly" was inserted, there were still no beeps. This led Klaus astray>

Hm, works here, macOS 10.14.6 and LC 9.6.1, as advertized!
Means it beeps twice after my click.

Or am I missing something obvious/the point?
Maybe your are talking about LCB?

Klaus wrote: Sun Sep 06, 2020 9:31 pm

Code: Select all

on  mouseUp
   if "3" is an integer then beep 2
end mouseUp

Hm, works here, macOS 10.14.6 and LC 9.6.1, as advertized!
Means it beeps twice after my click.

Regarding "is strictly" you would test for If you put 3 in quotes it is a string
from the message box this beeps twice It is just for integer and real that I don't get the "is strictly" to work.

Kind regards
Bernd

bn wrote: Sun Sep 06, 2020 7:42 pm As of LC 8.0 there is an "is strictly" operator.

value is strictly { nothing | a boolean | an integer | a real | a string | a binary string | an array }

Unfortunately I can not get it to work with integers. It probably reflects the internal state of LC or how it currently views value.
Maybe someone has more luck than I do.

Kind regards

hi bn -- i was unaware of the 'strictly' operator. Not sure why such an operator is needed, semantically it seems the same as 'is a'.
I found a bug report where LiveCode's Panos explains:

...
The ‘is strictly’ operators allow you to detect what the actual internal storage type of a value is.
Some things generate numbers which are stored as int32s but most will store them as doubles - arithmetic operators included.
I don’t know what the docs say about ‘is strictly an integer’ but the operators themselves are definitely doing as they
should so the docs might need some refinement

Mark

P.S. The ‘is strictly’ operators were not really added for general use as they are tied to internal mechanisms.
They were added to help with doing faithful export of values (lcVCS way back IIRC).

so basically the issue is that integers are stored internally as doubles...

When you ask “is an integer” you are actually asking if the value can be coerced to an integer which is why 3.0 and “3” report true. When you ask “is strictly” then the engine looks at how the value is actually stored without an attempt to coerce the value to the type. (Essentially what Mark said.)

Except as mentioned, strictly always returns false regardless if the value is 3 or 3.0.
That is, as I understand it, because of the way the value is stored internally (quite possibly the integer is stored as a double and the rational as some other data type internally).

The logic of “coercion” is suspect; I wonder if this was devised to try and explain the aberrant behaviour, rather than truly how the engine works.

I cannot think of a single reason that would be useful... and it’s not how any other language I’m aware of tackles this?

I'm new to LiveCode (as of August), but in HyperCard, we often had to resort to gimmicks like this:
There are variations on this theme, but the idea is to force HyperCard (or LiveCode) to convert both comparands to its internal numerical form before doing the comparison. That catches oddball values like 0003.

Also, the function above does not necessarily behave well if the parameter is not numeric. You should add your own error handling as appropriate for your situation.

PlaidFlannel.

HC and LC work exactly the same in all respects. Any, er, integer with leading zeros and/or trailing ones after a decimal point are seen as integers in both.

What does your function do that does not?

Most of the above thread is about whether it matters. Programmatically it seems not. Aesthetically, well, that is another issue.

Craig

User dunbarx is correct.

My memory of programming details from thirty years ago is obviously faulty. Maybe the gimmick of adding zero had been useful in some other untyped programming language of that era.

[NOTE: because this forum does not allow new members to use a decimal point in a post, I have substituted the bullet character • for a decimal point in the following text.]

Nevertheless, I was curious. Using an older Macintosh that is still capable of booting into System 9 (Mac OS 9•2•2 to be precise), I opened HyperCard 2•2 . I created a new stack with one card, which contained one button. The script of that button was:
The only interesting result is that counting the characters in a string containing digits sometimes produces a different result after adding zero to the string.

A lesson to be learned is that there may be situations where it is important to know whether the internal representation of data in a HyperTalk or LiveCode variable or expression will be treated as a string or a number.

While I was in HyperCard, I confirmed one other expectation: comparisons of very long numeric strings can produce different results because of truncation. For example, in a HyperTalk script, these two 18-digit numbers are not equal:

3000000000000000000
3000000000000000001

while these two 19-digit numbers are equal:

30000000000000000000
30000000000000000001

Similarly, these two 15-digit numbers are not equal:

3000•00000000000
3000•00000000001

while these two 16-digit numbers are equal:

3000•000000000000
3000•000000000001

These results are the same whether the code contains the value as a number (unquoted string of digits) or as a quoted string.