Exp10()

[chris319]

While new math functions are being added to v4.5, how about adding Exp10() to balance Log10()?

[STARGÅTE]

Code: Select all

Macro Exp10(Value)
  Pow(10, Value)
EndMacro

[chris319]

If it's that simple there is no reason for it not to be in the language for completeness.

[UserOfPure]

If it's that simple then that's why it's not been added. And that's a quote from Freak.

[chris319]

If it's that simple then that's why it's not been added.

Yeah, they might have to spend a whole 10 minutes adding it.

[UserOfPure]

Yeah, they might have to spend a whole 10 minutes adding it.

The discussion that ensued for such a request was that the command would have to be added for all 3 platforms (Windows, Linux, Mac), then the docs updated for each, then testing to ensure it worked, etc. So, a little longer than 10 minutes and for something you can wrap in a macro in 2 seconds? That's the reason.

[Trond]

The reason for having separate LogX(Value) commands instead of a single LogN(N, Value) is that the function can be faster with hard-coded value for N. But, Exp10() will likely not be (as far as I can tell).

[chris319]

Yeah, they might have to spend a whole 10 minutes adding it.

The discussion that ensued for such a request was that the command would have to be added for all 3 platforms (Windows, Linux, Mac), then the docs updated for each, then testing to ensure it worked, etc. So, a little longer than 10 minutes and for something you can wrap in a macro in 2 seconds? That's the reason.

10 minutes was an exaggeration. In reality I can't see this taking longer than about 30 minutes. And I wasn't aware you spoke for the development team.

[Fred]

The main issue is the number of available commands for PureBasic. We are already to more than 1100. If we add every simple commands, we will end up with way too much commands, which will add to PB complexity. So yes, we try to always see if it really adds something before adding a new command (which couldn't be easily removed once it's here).

[naw]

The main issue is the number of available commands for PureBasic. We are already to more than 1100. If we add every simple commands, we will end up with way too much commands, which will add to PB complexity. So yes, we try to always see if it really adds something before adding a new command (which couldn't be easily removed once it's here).

Might that be a reason to have an *official* PB include file that adds all these simple commands - that are too small / insignificant to add as a full blown command, but are still nice to have. Having an *official* include file for extra commands would also help maintain compile compatibility between various sources and Win/Lin/Mac

[freak]

How would that be different from a builtin function?

[naw]

How would that be different from a builtin function?

Well - it wouldn't need to be included in the Help files. Because it would be written only in PB (no ASM), should compile across Win/Lin/Mac, you and Fred wouldn't necessarily have to code it, because the code is visible to all perhaps it doesn't need such rigorous testing (assuming that the rigorous testing has already been done with the core PB commands)

[freak]

So, if we don't write it and we don't test it and we don't document it... where exactly is the *official* part?

[Rescator]

Such an include would be a bad idea!

Well firstly somebody would need to maintain that.
Secondly it would have to be tested for each release.
Thirdly, who decides what to include or not?
Fourthly, there must be no dependencies.
Fifthly, documentation would be needed.

If the PureBasic team decides the why not make it native almost the same amount of work involved.

If not them, then who?

Personally I've been slowly building a include library.

I name them such:

"Windows 1.0.pbi" this contains window/gui related procedures for example.

If I add new procedures or improve existing ones but do not change my internal "API" it becomes "Windows 1.1.pbi"
If things are changed such that compatibility is broken it becomes "Windows 2.0.pbi" etc.
These includes are copied from the include library to the projects include folder so each project is "self contained", a benefit if a include jumps from 1.x to 2.s which could break existing code.

Some includes have dependencies on others, like my UUID that takes UUID/GUID strings and turn them into .GUID and vice versa, or create new ones.
Again the version numbering makes sure to avoid breaking code or make it easy to notice.

It would be much better if the PureBasic team enhanced the IDE to have such include maintenance built in, rather than a generic include.

[naw]

So, if we don't write it and we don't test it and we don't document it... where exactly is the *official* part?

Ha ha - a good point, well made...