1. Bernhard Stoeter
  2. PowerBuilder
  3. Wednesday, 29 April 2020 13:49 PM UTC

Hi all,

why leads the assignment "ldc_X = 25E2" to 2500 and "ldc_X = 2.5E3" to 2? This happens with decimal, double, long and real variables in all(?) PowerBuilder versions inclusive PB1900R2?

Kind regards,
Bernhard

Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 29 April 2020 18:51 PM UTC
  2. PowerBuilder
  3. # 1

Hi Bernhard;

  Yes, a conversion "bug" from way back in older PB releases.

For example:  Decimal  ldec  = 2.5E3  // Should be 2.5 but appears as 2500

  Please open a Support Ticket for this "legacy" issue.

Regards ... Chris

Comment
  1. Miguel Leeuwe
  2. Wednesday, 29 April 2020 23:51 PM UTC
I think Ricardo is right: they should evaluate to 2500, at least on my calculator ?
  1. Helpful
There are no comments made yet.
Ricardo Jasso Accepted Answer Pending Moderation
  1. Wednesday, 29 April 2020 19:30 PM UTC
  2. PowerBuilder
  3. # 2

I tested it in PB 2019 R3 and it works fine for all numeric datatypes (see attachement).

Attachments (1)
Comment
  1. Ricardo Jasso
  2. Wednesday, 29 April 2020 21:48 PM UTC
Sorry, I meant PB 2019 R2, not R3. Then, I tested it in PB 2017 R3 and it also works fine.
  1. Helpful
  1. Ricardo Jasso
  2. Wednesday, 29 April 2020 21:56 PM UTC
Both expressions should result in 2500.

25E2 is 25 * 10^2 equals 2500

2.5E3 is 2.5 * 10^3 equals 2500
  1. Helpful
  1. Chris Pollach @Appeon
  2. Thursday, 30 April 2020 15:18 PM UTC
Hi Ricardo ... FYI: Yes, OK on my 2017R3 build 1915 as well.
  1. Helpful
There are no comments made yet.
Bernhard Stoeter Accepted Answer Pending Moderation
  1. Thursday, 30 April 2020 06:17 AM UTC
  2. PowerBuilder
  3. # 3

I forgot to mention that I use german language settings. See attached picture.

Bernhard

Attachments (1)
Comment
  1. Ricardo Jasso
  2. Friday, 1 May 2020 13:00 PM UTC
I changed the region configuration on my computer to "Dutch (Germany)" and it behaves as you mention. So, indeed it is a bug. The fix could be one of two: 1) Use regional settings when assigning literal values to variables but store them internally in a standard format (e.g. a dot); this way other programmers can view the source code using their own regional settings (e.g. a comma), or 2) Don't use regional settings when assigning literal values to variables and standardize on the dot as the decimal separator. I think the first one might turn out to be too complicated, like when passing literal values as arguments to functions because they need to be separated by commas. The latter seems to be the right fix.
  1. Helpful
  1. Miguel Leeuwe
  2. Friday, 1 May 2020 14:11 PM UTC
haha, Ricardo, I'm "Dutch" and that's definitely not Germany. Germans are "Deutsch" and Dutch are from Holland.

(sorry, I know it was probably a typo)

And yes, your number 2) is I think the best thing to do. In code, I've never assigned "," as a decimal separator for hard coded values. Unless you might be working with strings and decimals. I think decimals do look at the language settings (when working with strings in combination), but all other values need a dot, no matter which language setting.

regards
  1. Helpful
  1. Ricardo Jasso
  2. Friday, 1 May 2020 16:39 PM UTC
Hahaha, you are right. I should have put "German (Germany)". I work with some german customers and I knew that German in German was spelled differenty. But in English it's actually "German". No need to translate. :)



I checked with VB.NET and a dot is always used no matter what regional setting I use. I guess that's a standard in all programming languages.
  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.