You cannot trust arithmetic anymore

[FourthWorld]

Richard.

"Give me a business case where you'd want custom behavior without a custom name."

Well, one might say that having the "div" operator work as if decimal arithmetic was the norm was a case in point. The implication being that "custom behavior" in this context is what humans think of as "normal behavior".

Consider the xTalk definition of "word". It's unique to xTalks, and arguably wrong. But it's so long established that when proper word parsing became practical with the addition of IBM's Unicode libraries, the team preserved the original chunk type while introducing a new one, trueWord.

I believe you've demonstrated a bug in this engine feature, so the appropriate solution would be to address it where the problem lives, in the engine.

Overriding would create a world where behavior would become unpredictable depending on which libraries one may or may not have in play at any given time.

So Raney's thinking was to allow diversity while maintaining predictability: when you want something different from what the engine delivers, call it by a different name.

[FourthWorld]

Funnily enough I thought LiveCode would listen to their customers . . .

What happened in your life to compel you to habitually choose the most sweepingly rude way to convey almost anything?

Do you talk to colleagues or family with such unsupportably broad judgementalism?

I have also attracted a lot of flack from time to time by suggesting that LiveCode might like to
retrench a bit and sort out quite a lot of bugs BEFORE going hell for leather for the next big thing.

Often from yourself, where you frequently also demand they invest in new initiatives.

Running a software business is a challenging balancing act, one that may appear simple in inverse proportion to the demander's personal experience in undertaking such challenges.

[richmond62]

Do you talk to colleagues or family with such unsupportably broad judgementalism?

If I cannot get through to them otherwise, I do.

I was waiting for that.

Aye, well, sometimes it taks a graip tae shift the glaur.

Bugs that have been sitting around for 10 years or more that still cause problems need to be sorted out.

[dunbarx]

Richard.

I believe you've demonstrated a bug in this engine feature, so the appropriate solution would be to address it where the problem lives, in the engine.

I don't think so. As Mark W. pointed out, and the current "bug" thread in QC addresses, the issue is inherent in the way the math library works. It is, I think, our responsibility to know about that stuff, and adapt. I was sloppy, thinking, assuming, I knew what "div" meant, when at the deepest level, I did not.

If I knew then what I know now, I would have quietly incorporated my little kludge, and never mentioned the issue, except perhaps as a subject of interest in LC trivia.

Craig

[richmond62]

my little kludge

Why is it necessary to depend on 'kludges' and workarounds?

Oh, and:

sweepingly rude

Obviously some folk round here have never encountered what constitutes real rudeness.

[dunbarx]

Richmond.

Why is it necessary to depend on 'kludges' and workarounds?

Because computers are only machines, and we are only human. One day when we both are mostly bionic these little annoyances will go away.

In the meantime, and you were among the very first to point out the issue, we count on our fingers and toes, and computers count ones and zeros. Sometimes you need a little kludge glue to make things stick together..

But you already know this

Craig

[richmond62]

Because computers are only machines, and we are only human.

That is indisputably true.

But, between humans (difficult closed systems) we have languages,
and between humans and computers (closed partly difficult systems) we have languages.

All human languages are 'imperfect' insofar as:

1. They cannot transfer information without interference and background noise between humans.

2. Different languages, having developed in different environments are better at conveying some information
and worse at other information than other languages.

The same can be said re computer languages.

Now, as Dan Shafer stated; LiveCode is a very, very high level language.

Does the price of having a very, very high level language involve having to use 'kludges' and workarounds
which might not be necessary in lower level languages?

[mwieder]

The "problem" with trying to quantize an analog world isn't localized to just LiveCode.
For instance, in python you would see the same thing:

Code: Select all

>>> (11.025 * 28) / 11.025
27.999999999999996

because python also uses the same binary math engine.

Richmond - by means of which I'm attempting to agree.
A high-level language shouldn't require these kludges. I can get the correct result on any of my hand-held calculators.
And using a decimal arithmetic library in place of the current binary one would solve the discrepancy.

[FourthWorld]

Richard.

I believe you've demonstrated a bug in this engine feature, so the appropriate solution would be to address it where the problem lives, in the engine.

I don't think so. As Mark W. pointed out, and the current "bug" thread in QC addresses, the issue is inherent in the way the math library works. It is, I think, our responsibility to know about that stuff, and adapt. I was sloppy, thinking, assuming, I knew what "div" meant, when at the deepest level, I did not.

Every language has gotchas, and as Mark pointed out math anomalies are common even in the most popular of them.

My only point here wasn't about the method by which the engine could address the issue (Mark Waddingham does a good job here), but merely that the issue is indeed in the engine. If scripts could override engine behavior, we would have a potentially unpredictable world in which the same LC version might seem to exhibit a wide range of behavior because some script somewhere has overridden a built-in language feature.

It seems we don't really disagree there, but with the remedy for an existing work:

If I knew then what I know now, I would have quietly incorporated my little kludge, and never mentioned the issue, except perhaps as a subject of interest in LC trivia.

When we want to make consistent changes across a code base, a good search-and-replace is ideally the solution for that, and a great many other things besides. If the IDE's search-and-replace tool isn't doing what you need, perhaps we can explore how to improve it so it can.

[dunbarx]

It always seemed, er, unseemly to add a small value to the number being "divvied". Clunky, you know.

This actually addresses the math library issue head on:

Code: Select all

on mouseUp
   put round(11.025 * 28) div 11.025 into fld 1
end mouseUp

If the library cannot quite reach the "full" value of the multiplication, just give it a push.

Craig

[mwieder]

Craig-

That assumes you already know the answer you're looking for.
Different input values will give you different results.

Code: Select all

on mouseUp
   put round(10.9 * 28) div 10.9 into fld 1
end mouseUp

[dunbarx]

Mark.

Oddly, I realized just that right after I wrote it, and went to delete the post. "Round()" is the wrong way to go about it. But I could not find it, and thought it never actually went through. But now there it is.

So I will stick with adding the tiny kludge kicker.

Craig

[richmond62]

A high-level language shouldn't require these kludges. I can get the correct result on any of my hand-held calculators.

Having just paid about $300 for some new glasses (!) I can get a correct result on my hand-held as well:
-

slide.jpeg (6.1 KiB) Viewed 6269 times