Page 1 of 1

### [Solved] An OO Basic pitfall?

Posted: Wed Dec 05, 2018 8:37 pm
I'm facing a problem with this:
In the spreadsheet you can write =-2^(1/3) without problems but you can't do that:

Sub Main
MsgBox -2^(1/3)
End Sub

If you do this:

Sub Main
MsgBox -(2^(1/3))
End Sub

It's OK.

### Re: A OOBasic pitfall?

Posted: Wed Dec 05, 2018 9:08 pm
Welcome to the Forums.
The first one doesn't work because you can't get a fractional power of a negative number.
The second one works because the number you are putting to a power is positive, then the formula changes that result to a negative number.

I don't know why you are stating that the first one works as a direct entry, as when I tried it , I got a #VALUE error.

### Re: AOO Basic pitfall?

Posted: Wed Dec 05, 2018 11:14 pm
Dear RusselB,

I don't know why you are stating that the first one works as a direct entry, as when I tried it , I got a #VALUE error.

Look at this,

### Re: AOO Basic pitfall?

Posted: Thu Dec 06, 2018 12:08 am
Please edit your last post so that the image shows. I recommend using the Preview option when attaching images/documents so that you can ensure everything is showing correctly before you post.
I can tell that you tried to attach an image, but the image isn't showing.

Apologies. I got the #VALUE when using OpenOffice Calc, which is my default.
When forcing the usage of LibreOffice Calc I do get an answer for
Code: Select all   Expand viewCollapse view
`=-2^(1/3)`

Code: Select all   Expand viewCollapse view
`=-(2^(1/3))`

So it appears the difference between the two is how Calc is handling the sequence of operations, as the results are identical.

### Re: AOO Basic pitfall?

Posted: Thu Dec 06, 2018 12:37 am
RusselB wrote:I got the #VALUE when using OpenOffice Calc, which is my default.
[Solved] Power of negative number

RusselB wrote:So it appears the difference between the two is how Calc is handling the sequence of operations, as the results are identical.
[Tutorial] Order of Operations in Calc

Luizz wrote:I appreciate any enlightening comments
The syntax/semantics for AOO's Basic language is unrelated to Calc's syntax/semantics. They were developed independently. You should not expect to use a Calc expression in Basic and receive the same result.

If this solved your problem please go to your first post use the Edit button and add [Solved] to the start of the title. You can select the green checkmark icon at the same time.

[Tutorial] Ten concepts that every Calc user should know

### Re: AOO Basic pitfall?

Posted: Thu Dec 06, 2018 2:46 am
Sorry, my fault. Just a novice. The figure is here:

I agree with both of you but IMHO it is a pitfall. I've imported a full-functional macro from VBA to solve Cubic Equations of State, very common in Thermodynamics,
and it didn't work neither in OO nor in LO. It was necessary a hard work to find the issue and circumvent it. Those equations are much more complex than the example
here and I decided to share the issue with the community in a easier way.
I'm coming from Excel (I've published a book about it) and I become an OO and LO fan and I'm sure I'm going to learn a lot as I just did with your kind answers.

Thank you

### Re: [Solved] An OO Basic pitfall?

Posted: Thu Dec 06, 2018 3:17 am
There are cases where two very different usages of the minus character are conflicting and need to be disambiguated either by mandatory parentheses or by a strict "universally" applied rule. Since the one generally accepted rule does not exist, we should disambiguate wherever a probable conflict comes in sight at the horizon.

The usages:
We need a figure in addition to the common digits (and some additional elements like the decimal separator) to be able to represent negative numbers as constants. Unfortunately history decided to use in this role the same character that is used in two related but different roles:
As a prefixable unary operator meaning "change sign".
As the well known binary infix operator for addition.

Concerning the current issue this means that -2^(1/3) can be evaluated like (-2)^(1/3) if we read the minus as a sign. If we read it as a prefix operator the common preference rule will evaluate (2^(1/3)) and apply the ChgSgn to the result.

Since we often need to change the common preference in algebraic expressions with the help of parentheses anyway, while there is no obvious substitute for the minus as a sign, I would plead for the way our Basic (and other programming languages) do it. However, I cannot find the spell to tidy up the mess we have. Thus: Disambiguate in every case of the slightest doubt.

"Do it as VBA / Excel does" never was a good idea, imo.

### Re: [Solved] An OO Basic pitfall?

Posted: Fri Dec 07, 2018 8:54 pm
Lupp wrote:We need a figure … to be able to represent negative numbers as constants.
APL, developed in the 1960s, had that feature.
¯ indicated that a numeric constant was negative.

An APL interpreter shows the different results. ★, when used dyadically, is the exponentation operator; ÷, when used monadically, is the reciprocal operator. All operators in APL are right-associative, so people usually read expressions right to left. ¯2★÷3 means (Calc formula) =(−2)^(1/3) but −2★÷3 means =−(2^(1/3)). APL supports complex numbers and 0.629961+1.09112i is one of the three cube roots of minus two.
Screen Shot 2018-12-07 at 11.56.31 .png (10.06 KiB) Viewed 667 times

### Re: [Solved] An OO Basic pitfall?

Posted: Sat Dec 08, 2018 2:56 pm
Well, I never used APL, but I heard of it in the 1960es, too. Thanks for the examples!

However, we are living in unicode times, and there should long be established a section dedicated to characters for use in everyday mathematics and in everyperson programming and in everychild usage of spreadsheets ... as well.
Instead we have support for hundreds of "languages" with their special characters all over the place ...

Concerning mathematics (including programming, usage of spreadsheets, ...) we have a dichotomy between the usage of formula editors supporting next to everything except calculations/evaluations and the bad and messed-up usage of a 1880 type-writer system having overgrown older (and sometimes better considered) practice due to their limited basket. We haven't even a widely accepted way to easily disambiguate by a simple context-independent formalism between a "5 through 11" (amiguous understanding!) in some traditions written as "5 - 11" and a "5 minus 11" written mostly with the same string.

Not only erring is human. Doing things in a bad or insufficiently considered way also is.

We are going forwad. To an even bigger mess every year! AI will surely help us out. Will we understand then the answer if it is 42?

### Re: [Solved] An OO Basic pitfall?

Posted: Sat Dec 08, 2018 9:55 pm
Hi Lupp,
We must remember that programmers are not mathematicians. Just as they were not astronomers and did not notice that 1900 AD was not a leap year.
(What, me worry?)

Have a look at the attached pdf showing some software calculations

### Re: [Solved] An OO Basic pitfall?

Posted: Sat Dec 08, 2018 11:53 pm
@jrkrideau: Thanks a lot.

However, I am not completely agreeing with your comment. Any mathematician should be capable of considering the needs of programming and every programmer should have some insight concerning mathematics. The great inventors in the field, and the founders of programming (like Lady Lovelace, Alan Turing, Donald E. Knuth ...) were mathematicians after all. There were powerful forces pulling in the wrong direction and introducing sloppiness and "better Q&D than late", too, and some may have human names. I would suspect the forces were of commercial and/or military nature mostly.

The rule of the Gregorian calendar excluding double-zero-years from the set of leap-years if not the number has the divisor 400 was teached to every scriptor in any monastery and was understood by every clergyman. It had been discussed thoroughly in advance. It was teached in highschool when I was a schoolboy and I teached it myself all my professional life. Thus I feel sure that not a programmer choose that silly "day zero" but that someone who should have known better let slide his supervision of an apprentice assuming he would also know - or be clever enough to look in a book to not risk to earn the laughter of the centuries.

Well, historians not are mathematicians mostly but clever guys. On the other hand they have to handle a chronology whose principles are older than the general acceptance for the zero as a number and for negative numbers. Thus they have an excuse for the lacking of a year 0. No excuse for any human of the twentieth century to not know about negative numbers and the necessity of indisputable intertpretation of formalised information (like dates).

I am not an astronomer but I was rightfully also teached that astronomers still use a "Julianic year" of exactly 365.25 days - and I did not suffer from that.

### Re: [Solved] An OO Basic pitfall?

Posted: Sun Dec 09, 2018 12:35 am
Lupp wrote:The great inventors in the field, and the founders of programming (like Lady Lovelace, Alan Turing, Donald E. Knuth ...) were mathematicians after all.

Off topic: some 25(?) years ago I heard Donald Knuth speak to the Mathematical Society of Trinity College, Dublin. A truly great speaker, speaking fluently and simply. If one ever gets the opportunity to hear him speak (on anything), I strongly recommend hearing him. One of the four or five really great speakers/lecturers I have heard in my life.

Rory