Basic Algebra Problem: Solving a/b/c=?

[adjacent]

Homework Statement

a/b/c=?

The Attempt at a Solution

I think it's $\frac{a}{bc}$.However,that sometimes gives incorrect results.
I never learned that 3 divisions.(I was lazy in gr.8)

 

[pasmith]

Homework Statement

a/b/c=?

The Attempt at a Solution

I think it's $\frac{a}{bc}$.However,that sometimes gives incorrect results.
I never learned that 3 divisions.(I was lazy in gr.8)

The notation is ambiguous. It can be interpreted either as
<br /> (a/b)/c = \frac{a}{bc}<br />
or as
<br /> a/(b/c) = \frac{ac}{b}<br />
and this is a point on which reasonable people may differ.

In short: don't ever write a/b/c; write either (a/b)/c or a/(b/c).

 

[adjacent]

No.
For example:
Make t the subject(isolate t)
$\frac{3}{s+4}=3t$
What will you do here?

 

[Mark44]

To the best of my knowledge, the behavior of expressions such as a/b/c is better understood in programming than in the mathematics we are taught. In C (and other languages based on C) and Fortran, a/b/c is exactly the same as if it were written (a/b)/c.

I remember being taught a mnemonic device in 9th grade - "my dear aunt sally" - to help remind us that multiplication and division take precedence over addition and subtraction. Since that time a new mnemonic has appeared - PEMDAS - parentheses, exponents, multiplication, division, addition, subtraction - but that wasn't around when I was in junior high and high school.

Besides listing the precedences of all operators, the C programming language defines the order in which some operations will be performed. This is called the associativity of an operation. For example, the associativity of the addition operator (+) is left to right, so the expression a + b + c is evaluated as if it were written (a + b) + c. Likewise, the associativity of the multiplication and division operators (* and /) is left to right, so as already mentioned, a/b/c is the same as (a/b)/c.

With regard to 3/(s + 4) = 3t, divide both sides by 3 to get 1/(s + 4) = t.

Note that before simplification, the left side could be written as 3/(s + 4)/3. As long as mathematics abides by the same associativity that C and other programming languages specify, then the above is understood to mean 1/(s + 4). Not all mathematicians are C programmers though, so my assumption might not be valid.

 

[adjacent]

Since that time a new mnemonic has appeared - PEMDAS - parentheses, exponents, multiplication, division, addition, subtraction -

Shouldn't it be PEDMAS?

btw,voko gave a very nice way to deal with these kind of problems in post 22.
So Is that the best way?
According to you a/b/c is (a/b)/c
But according to voko,it is (ac)/b

 

[Mark44]

Shouldn't it be PEDMAS?

It doesn't matter. Multiplication and division are at the same precedence level. Likewise, addition and subtraction are at the same level

btw,voko gave a very nice way to deal with these kind of problems in post 22.

Post 22? There aren't that many posts in this thread.

So Is that the best way?
According to you a/b/c is (a/b)/c
But according to voko,it is (ac)/b

Apparently voko is interpreting a/b/c as a/(b/c) = a * 1/(b/c) = a * (c/b) = (ac)/b. As an expression in one of the programming languages I cited, that would not be correct. As far as I know, the rules in mathematics aren't as clearcut.

 

[PeroK]

As far as I know, the rules in mathematics aren't as clearcut.

I believe the rules of mathematics are clear. If * is a non-associative operation, then
a*b*c is not well-defined. There's no convention on where to put the brackets.

 

[adjacent]

Post 22? There aren't that many posts in this thread.

Sorry it's this thread:https://www.physicsforums.com/showthread.php?t=740604&page=2
I forgot to include the link

 

[BruceW]

yeah, mathematically I agree with pasmith and PeroK. the expression a/b/c is not mathematically meaningful, since (as far as I know) the convention a/b/c = (a/b)/c is just a programmer's convention, not a mathematician's convention.

edit: or whatever the programmer's convention is, be it a/b/c=(a/b)/c or a/b/c=a/(b/c) either way, I don't think this is a mathematician's convention.

second edit: also, in your other thread with voko, you have simply been lazy to not write in the brackets. You should put the brackets in the correct place, otherwise the equation you were writing is meaningless.

 

[Mark44]

I believe the rules of mathematics are clear. If * is a non-associative operation, then
a*b*c is not well-defined. There's no convention on where to put the brackets.

Well, that's exactly the problem, the lack of defined-ness of some expressions. Mathematically, division and subtraction aren't associative, but for one reason or another, the programming languages I cited have defined how all of the operators associate (which is left to right for the arithmetic operators +, -, *, and /). It seems a lot more satisfying to me that there aren't as many expressions that aren't well-defined.

yeah, mathematically I agree with pasmith and PeroK. the expression a/b/c is not mathematically meaningful, since (as far as I know) the convention a/b/c = (a/b)/c is just a programmer's convention, not a mathematician's convention.

IMO, the math folks should adopt the same conventions...

 

[BruceW]

It is just notation really. It has no mathematical importance. (Is what I'd guess a mathematician would say). we could universally adopt the notation a/b/c=(a/b)/c and this would not change anything mathematically. It would just mean we could avoid using the brackets. In truth, I think it reads nicer with the brackets. I'd rather have less convention and more brackets.

edit: unless I was writing a really long program with a lot of (a/b)/c. In this case, I'd rather have the convention than the brackets. So I can see why programmers adopt a convention.

 

[Ray Vickson]

yeah, mathematically I agree with pasmith and PeroK. the expression a/b/c is not mathematically meaningful, since (as far as I know) the convention a/b/c = (a/b)/c is just a programmer's convention, not a mathematician's convention.

edit: or whatever the programmer's convention is, be it a/b/c=(a/b)/c or a/b/c=a/(b/c) either way, I don't think this is a mathematician's convention.

second edit: also, in your other thread with voko, you have simply been lazy to not write in the brackets. You should put the brackets in the correct place, otherwise the equation you were writing is meaningless.

If you parse from left to right it is unambiguous: a/b/c = (a/b)/c. However, parsing from left to right is not always done. It can even be done differently in the same type of software. For example, in Maple the Classic worksheet interprets a/bX as (a/b)X, so a/b+c = (a/b)+c, a/b*c = (a/b)c and a/b/c = a/(bc); this can be handy when we want a/(b1*b2*b3* ... *bn), which is entered as a/b1/b2/b3/.../bn. However, in the newer "standard" worksheet, a/bX is interpreted as a/(bX. When we start by typing a/b we immediately (on screen and in memory) get a solidus with 'a' in the numerator and with a denominator that starts with 'b'. So a/b+c would be a/(b+c (and would be open-ended until we enter a right-arrow), a/b*c would be a/(b*c (open-ended) and a/b/c would be a/(b/(c (both open-ended).

 

[Mark44]

It is just notation really. It has no mathematical importance.

It might help to reduce confusion, so I'd say it's important that way.

(Is what I'd guess a mathematician would say). we could universally adopt the notation a/b/c=(a/b)/c and this would not change anything mathematically. It would just mean we could avoid using the brackets. In truth, I think it reads nicer with the brackets. I'd rather have less convention and more brackets.

edit: unless I was writing a really long program with a lot of (a/b)/c. In this case, I'd rather have the convention than the brackets. So I can see why programmers adopt a convention.

As far as I know, the associativity rules in C (and C++, C#, Java, etc.) make it possible for the compiler to generate code to evaluate an expression. The fewer expressions whose behavior is undefined, the better.

I agree that parentheses are important. Although compilers can parse a complicated expression, human readers have a much more difficult time, so adding parentheses can help people.

BTW, as I learned it, these -- [] -- are brackets, these -- () -- are parentheses, and these -- {} -- are braces (also called curly braces). It might be a Britishism to call () brackets.

 

[adjacent]

What do I use then?Programming or mathematics?

 

[adjacent]

Let's start with an example.
a/b/c/d

a=1 , b=2 , c=3 , d=4
Writing this directly into calculator gives
1/24

by voko's method:
(1*4)/(2*3)
=4/6

By your programming method,
I don't know.

Yes I agree that parentheses are important.But in a problem like this:
a/b=cd
,
you have no choice than to write a/b/c
It can be written as (a/b)/c but what if the question asked for simplifying the whole ?

 

[PeroK]

BTW, as I learned it, these -- [] -- are brackets, these -- () -- are parentheses, and these -- {} -- are braces (also called curly braces). It might be a Britishism to call () brackets.

I've always said: [] -- are square brackets, () -- are round brackets, and {} -- are curly brackets!

It's probably a US/UK difference.

 

[BruceW]

If you're just doing mathematics, then use the brackets (or parentheses, if that's the right word for it). So then, you don't even need to think about left-to-right or right-to-left parsing. The parentheses will make it explicitly clear what you mean. If I had a step in a calculation that was like a/b/c then I would not be surprised if my teacher gave me a minus mark for that. (although it would be a bit mean).

If you're programming, then feel free to use a/b/c to mean (a/b)/c. But keep in mind that not every programming language will necessarily adhere to this convention. (although it seems like most of them do, by what others have been saying in this thread).

 

[BruceW]

I've always said: [] -- are square brackets, () -- are round brackets, and {} -- are curly brackets!

It's probably a US/UK difference.

haha, yeah, I've always said: [] -- are square brackets, {} -- are curly brackets, and () -- are round brackets, or parentheses. And I've always just said 'brackets' if I don't care which one. I don't know if my language is 'correct' or not though.

 

[BruceW]

If you parse from left to right it is unambiguous: a/b/c = (a/b)/c. However, parsing from left to right is not always done. It can even be done differently in the same type of software. For example, in Maple the Classic worksheet interprets a/bX as (a/b)X, so a/b+c = (a/b)+c, a/b*c = (a/b)c and a/b/c = a/(bc); this can be handy when we want a/(b1*b2*b3* ... *bn), which is entered as a/b1/b2/b3/.../bn. However, in the newer "standard" worksheet, a/bX is interpreted as a/(bX. When we start by typing a/b we immediately (on screen and in memory) get a solidus with 'a' in the numerator and with a denominator that starts with 'b'. So a/b+c would be a/(b+c (and would be open-ended until we enter a right-arrow), a/b*c would be a/(b*c (open-ended) and a/b/c would be a/(b/(c (both open-ended).

Interesting, an example of right-to-left parsing for a/b/c. So, in the new Maple worksheet, it gives a/b/c = a/(b/(c)) = a/(b/c) ? I'll try to remember that, if I ever need to use Maple.

edit: well, I guess I don't need to remember anything, since it draws the solidus on-screen as you're typing.

 

[adjacent]

No Programming Please.I am only interested in Maths here.
So Please tell me Mathematically.

 

[pasmith]

Yes I agree that parentheses are important.But in a problem like this:
a/b=cd
,
you have no choice than to write a/b/c

Nonsense. You always have the choice (and, I would say, the obligation) to add parentheses to make your meaning clear. I would automatically add the parentheses to get (a/b)/c = d, and actually I'd simplify that and write a/(bc) = d instead.

 

[adjacent]

I would automatically add the parentheses to get (a/b)/c = d, and actually I'd simplify that and write a/(bc) = d instead.

There you go.
You simplified using that method.Am I wrong?

 

[adjacent]

Since this thread is about Simple algebra,I have another question.What is this: >> and <<?

 

[Mark44]

Since this thread is about Simple algebra,I have another question.What is this: >> and <<?

>> - very much greater than
<< - very much less than

 

[adjacent]

>> - very much greater than
<< - very much less than

What makes them different from > and <?

 

[Mark44]

>> - very much greater than
<< - very much less than

> - greater than
< - less than

What makes them different from > and <?

One extra symbol in each, and the definitions are different.

Some examples:
2 > 1
100 >> 1

 

[adjacent]

100 >> 1

Isn't this just SAME as 100>1?
I don't see any reason why we should use >> instead of >.

 

[Mark44]

The symbols >> and << are used in approximations, to make calculations simpler. They're used typically when the two things being compared are different by at least an order of magnitude.

Here's an example.
You probably know that (1 + a)³ = 1 + 3a + 3a² + a³. If a << 1, then a² and a³ will be very tiny, so (1 + a)³ ≈ 1 + 3a.

Let's say that a = .01, so a << 1. (a is two orders of magnitude smaller.)

The exact value of (1 + a)³ is 1.030301.
The value of 1 + 3a is 1.03, so my approximation agrees with the exact value to three decimal places. The smaller a is in comparison to 1, the better the approximation will be.

 

[Mark44]

100 >> 1

Isn't this just SAME as 100>1?

No, they're not the same. There's a qualitative difference between "larger than" and "way larger than."

 

[ChrisVer]

If you're just doing mathematics, then use the brackets (or parentheses, if that's the right word for it).

I am not sure that I'd like to see someone writing something like this in a sheet:
a/b/c/d/.../w
On paper/mathematics we can use the ___ lines to write divisions... In case we are working with a program, then parenthesis can help in avoiding unwanted mistakes (if you don't know how the program interprets what you type in)

 

[Ray Vickson]

Interesting, an example of right-to-left parsing for a/b/c. So, in the new Maple worksheet, it gives a/b/c = a/(b/(c)) = a/(b/c) ? I'll try to remember that, if I ever need to use Maple.

edit: well, I guess I don't need to remember anything, since it draws the solidus on-screen as you're typing.

Right, but it does need a right arrow to get get out of the fraction, or to get out of an exponent x^n or a subscript x_n.

 

[Ray Vickson]

Interesting, an example of right-to-left parsing for a/b/c. So, in the new Maple worksheet, it gives a/b/c = a/(b/(c)) = a/(b/c) ? I'll try to remember that, if I ever need to use Maple.

edit: well, I guess I don't need to remember anything, since it draws the solidus on-screen as you're typing.

Right, but it does need a keyboard right arrow to get get out of the fraction, or to get out of an exponent x^n or a subscript x_n. However, to compensate, one can enter many types of fractions without using brackets (parentheses?), such as a/(b + c*e + f), which is entered as a/b+c*e+f→, etc, and displays on screen exactly as you finally want it exactly when you type it.

 

[adjacent]

Everyone!I have got a nice solution to this fraction thing.
Let's simplify a/b/c/d/e/f/g/h/i/j/k ...z
First take the $\frac{a}{b}$ and divide c by it.
That gives $\frac{a}{b}*\frac{1}{c}$ by taking the reciprocal.
So it's very simple.
$\frac{a}{b}*\frac{1}{c}*\frac{1}{d} ...\frac{1}{z}$
Which is same as:
$\frac{a}{bcdefghijklmnopqrstuvwxyz}$

No mess.Simple Gr.5 division.
Ah,I'm so relieved.