LAE

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: SambaDancer

Dear Lavastorm developers,

As known and extensibly documented (for example: here) the unsuspected Lavastorm user can be confronted with very strange and unexpected results when calculating with fields of the DOUBLE data type.

In my modest opinion, both the principle and the explanation of this phenomenon in both the Lavastorm documentation and (even more extensibly) here, is very technical and pretty much incomprehensible for the business user Lavastorm is targeting.

I use Lavastorm in an auditing environment and last week, I gave a 3-day basic training to 6 certified auditors in the use of Lavastorm.
I have been trying to explain why they got such strange results when calculating with floating points and why (for example) placing a filter on a certain number resulted in 0 results.
Although I showed all proposed workarounds, I have failed miserably in getting the message through, and 2 of the attendees even raised the question if Lavastorm would even qualify as a 'serious data analysis tool' "if it can't even do what Excel can". You will understand my frustration...

I really don't want to get into a discussion if floating point arithmetic is perhaps superior to simple decimal calculation. My point is: if the targeted audience apparantly doesn't understand it, then something should change.

I therefore propose the following:
- Introduction of an new data type "DECIMAL" (or whatever you like to call it).
- For each field of type DECIMAL, the end-user can choose the number of decimals, with a maximum of ... (10? 15?)
- Addition, subtraction, multiplication and division of two DECIMAL fields or of an INT and a DECIMAL results in a product with the largest number of decimals of both input, unless specified otherwise. For example: (0.1*0.22 = 0.022); (123*45.67 = 5617.41); (123.45/678.9 = 0.18); (1.2345*6.789).ROUND(-3) = 8.381
- Rounding can be further controlled by multiplication with a 1 with the desired number of decimals. For example: (1.000000* 123.45/678.9 = 0.181838)

I sincerely hope that you will take my request into consideration.

Thanks so much in advance and best regards from The Netherlands,

Bart Roeleveld,
Senior Data Analysis Expert,
Coney B.V.

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: ejones

I really like that syntax for dealing with rounding. I believe doubles support 15 decimal digits so that may be the limit.

To make this work it would be necessary to clearly define some things so that LAE users will get the results they expect. So, I'd like to understand the rule that says 0.1*0.22 gives 0.022 and also that 123*45.67 gives us 5617.41. Does the number 0.22 give us a max of digits, or two digits to the right of the decimal? Does 45.67 give us four digits that can be used in any number or two digits to the right of the decimal?

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: SambaDancer

Sorry, made an error, so the example 0.1*0.22 = 0.022 is incorrect.

The proposed rule is that the number with the highest number of decimals, determines the number of decimals of the outcome. So it should have been: 0.1 * 0.22 = 0.02.

If you want MORE decimals, you multiply by 1 + the desired number of decimals. So if you would want 10 decimals: 1.0000000000 * 12.34 / 45.67 = 0.2701992555

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: SambaDancer

Dear developers, could you please confirm/deny that this feature request has indeed been officially addressed?
I'm getting a lot of questions about it from my students and from colleagues.
Thanks ever so much!!
Best regards,
Bart Roeleveld,
Senior Data Analysis Specialist,
Coney B.V., The Netherlands.

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: DanRosenblatt

Hi Bart- I will add this feature request to our bug tracking system to be addressed in a future version of LAE. You make some very good points, and while there are some ways to work around this (as noted in the "Floating Point Arithmetic" section of the BRE Help file), our intention is certainly not to require a computer science lecture for users to get going with the software. We'll keep you updated and will contact you if we have any questions.

Please feel free to encourage your students to post in the community forums here or contact Lavastorm Support with any issues or questions around floating point arithmetic in BRAINscript.