# GNU Astronomy Utilities - Tasks: task #13867, Infix notation for ImageArithmetic

You are not allowed to post comments on this tracker with your current authentication level.

# task #13867: Infix notation for ImageArithmetic

 Submitted by: Mohammad Akhlaghi Submitted on: Tue 26 Jan 2016 06:24:28 AM UTC Should Start On: Mon 25 Jan 2016 03:00:00 PM UTC Should be Finished on: Mon 25 Jan 2016 03:00:00 PM UTC Category: Arithmetic Priority: 5 - Normal Item Group: Enhancement Status: Postponed Privacy: Public Percent Complete: 0% Assigned to: None Open/Closed: Open Effort: 0.00

## Discussion

Mon 30 Mar 2020 11:32:14 AM UTC, comment #6:

As you say, this is a feature of the infix notation, so it doesn't yet exist ;-).

Currently Arithmetic only works in reverse polish notation and only has the tools for that. Its up to you to define it for your implementation of the infix notation ;-).

Mon 30 Mar 2020 11:29:05 AM UTC, comment #5:

I mean the order in which operations are executed.
https://en.wikipedia.org/wiki/Order_of_operations

In infix expressions, the operator precedence is required to resolve ambiguities. Operator Precedence is just like BDMAS rule of mathematics.
Eg: 1 + 2 * 3 , we need to calculate 2 * 3 first and then add it to 1 because * has higher operator precedence than +.

I have seen the reverse polish operations in arithmetic. It takes input of arithmeticparams and gal_list_str_t contains all the tokens.

Kartik Ohri <lucifer13>
Mon 30 Mar 2020 11:19:51 AM UTC, comment #4:

I don't really understand what you mean by "precedence order of all operators". Please be more elaborate! Did you look at how the reverse polish operation is managed in Arithmetic? Your function should have similar inputs ;-).

Mon 30 Mar 2020 07:20:31 AM UTC, comment #3:

To implement the algorithm, we need a precedence order of all operators. Is there an order already defined or should I define one ? If I have to define one, what things to keep in mind?

Kartik Ohri <lucifer13>
Sun 29 Mar 2020 12:45:27 AM UTC, comment #2:

If you have the time, that would be great ;-)!

Yes, its best to avoid library technicalities and start with a simple C source. Once it works nicely, you can put it into Gnuastro. Just look at the existing parsing methodology and write your library so the inputs are the same.

Sat 28 Mar 2020 09:14:55 PM UTC, comment #1:

While my copyright forms are being processed and till you are able to review the work on units library, can I work on this ? Also, should I begin with a similar approach first write an independent C file to convert infix notation to postfix and then proceed with integrating it in the library ?

Kartik Ohri <lucifer13>
Tue 26 Jan 2016 06:24:28 AM UTC, original submission:

In task #13574 a program to do image arithmetic was created (ImageArithmetic). But to be simply implemented it uses the postfix or reverse polish notation. Therefore as explained in that task, it is important for easy usability that it change the notation to the Infix notation where the operators are placed between the operands and it includes parenthesis. As explained in that task, a good way to do this might be through the Shunting-yard algorithm which translates infix notation to postfix notation which ImageArithmetic currently uses:

There is a very nice explanation with a full program here:

## Attached Files

No files currently attached

## Dependencies

Depends on the following items: None found

Items that depend on this one: None found

Carbon-Copy List
• -email is unavailable- added by makhlaghi (Submitted the item)
•

Do you think this task is very important?
This task has 0 encouragements so far.

Only logged-in users can vote.

## History

No changes have been made to this item