PureBasic Forums - English

> expressions are evaluated left to right

They still are, but higher priority parts will come first, however typing is depending on the sequence of processing.

>> types never change 'downwards'
> ; Type changes downwards from float to long here
> ; V
> q.q = 2*(92/8.+5)
> Debug q

Nope, perhaps I should rephrase this. PB is using a certain type to store the result. That 'result' type is not downgraded.

> ; And here V
> Debug 2*(92/8.+5)

So what happens here is:

2 -> result type is long
* ( ... ) -> () have higher prop, step through them
92 -> we stay on long
8.0 -> up to float

I checked the other examples as well, but it is still the same. The type in which is calculated goes only up, not down, until assigned to a var.

> Only the return type of a function can force a typechange.

Although overloaded it does change the type, read my original description carefully.

> a.f = 3
> b.l = 1 + 2 / a.f
>
> Notice the mathematic priority! It's NOT going to do something like ( 1 +
> 2 ) / 3 but it does 1 + ( 2 / 3 ). However, it will not start with typing a
> float as it still works from left to right.

Well, it's going to start with the left side...

1 -> stay a long
2 / a.f -> process as a block
/ -> result stays a long
/ a.f -> result is a flow
= -> we turn the result into the requested type, in this case a long

> Here, the 1 will acutally be treated as a float although you give the
> impression that that will not happen. Why?

No, it's not a float, it's a long, and stays a long until the / a.f is hit.

> Because: 2/a.f is a float, and when you add a constant and a float the
> result is a float. Also, the result of the entire expression is a float
> because if the 1 was a long it would be converted. It would be faster to
> add after the division because that would make the convertion more
> efficient, but the result is the same, the integer at 1 will be converted to
> a float.

Well, exactly not. The 1 itself is not turned into a float. It is stored as a long, then converted to a float the moment it hits the / a.f.

@blueznl:
This response to Trond's code is a little confusing.

blueznl wrote:I checked the other examples as well, but it is still the same. The type in which is calculated goes only up, not down, until assigned to a var.

The code results in the value 32 when it should be 33 according to your description. It should only result in 32 if it was downgraded somewhere in the process.

Using a lengthy breakdown, here goes:
This example is the same as the Trond's example for a quad result except the result would be downgraded to a quad for storing in q. It also results in 32 but it should be 33 according to your explanation.

If I have misunderstood the process please correct me.

No, you're right, but there is something very annoying going on...

PB 3.94:

Debug 2*(92/8.+5) returns 33

PB 4.10 Beta 2

Debug 2*(92/8.+5) returns 32


FRED PLEASE! Tell us what you changed...

Edit: looks like things in 4.10 are again as expected...

Okay, people. Small update of the PureBasic survival guide is up. 's a little more detail on how strings occupy memory, a section on files, and a few touchups. I'm now looking at the fancy new 4.10 to see if there is anything I can add to the nowadays extensive PB help files Anything new will be in red, as usual.

So, in effect, it's a Survival Guide for 4.00 about to be updated to 4.10? Uh, guess so then...

The link:

http://www.xs4all.nl/~bluez/datatalk/purebasic.htm

Have fun!

I'm working on a new update, now that the 4.xx breed gets better and better.

Some small sections have been redone (a piece on the debugger, for example) but there's still a lot to do.

Are there any special requests? (... of such a low level that I am able to answer them )

Oh, the link...

http://www.xs4all.nl/~bluez/datatalk/purebasic.htm

Latest version just upped. Now includes a new page on the debugger.
Find it here:

http://www.xs4all.nl/~bluez/datatalk/pure11.htm#top

New version just went up. Now includes a section on threads and some other small improvements.

http://www.xs4all.nl/~bluez/datatalk/pu ... #6_threads

good work.

Some things worth noting maybe:

On the Debugger/Profiler you wrote that enabling the profiler may slowdown the program.
This is not really an issue. The slowdown caused by the profiler is very small.
Adding a couple of dynamic breakpoints probably causes more slowdown than that.

On CreateMutex() vs. CreateMutex_() Your description makes it sound as though they are totally interchangable.
You should maybe add though that locking an API mutex (being an interprocess communication object)
is dead slow compared to the PB ones (critical sections), so it is not really suited for pure thread synchronisation.

Thanks. Good to know at least someone knowledgable is reading it I will make the changes...

... updated.

Some small updates. Updated the 'downloadable' version as well.

blueznl wrote:No, you're right, but there is something very annoying going on...

PB 3.94:

Debug 2*(92/8.+5) returns 33

PB 4.10 Beta 2

Debug 2*(92/8.+5) returns 32


FRED PLEASE! Tell us what you changed...

Edit: looks like things in 4.10 are again as expected...

Debug 2*(92/8.+5) returns 33.0 here in PB 4.20

That was fixed quite some time ago, I think you're replying to a very old message

Another update.

- FTP
- Sprites http://www.xs4all.nl/~bluez/datatalk/pu ... nd_screens

I've added as much to sprites as I could, but I'm stuck, either by my own lack of understanding, or by PB's limitations or bugs. I hope to find out soon

The following applies to all sprite commands:

* the size of the sprite should be smaller or equal to the screen
* 'standard' sized sprites are preferred (16x16 32x32 64x64 128x128 256x256)

the limit to the screensize is important for 2D sprites that will be clipped.
more modern hardware displays bigger sprites without problems when not clipped,
some even have no problems when clipping.


the (2^n)² limitation ONLY applies for sprites used for textures for CreateSprite3D,
normal 2D Sprites can have any size you like.

newer hardware can use textures in (2^x)*(2^y), some hardware can even use textures at any size.
sprite textures used to create Sprite3Ds may be bigger than the screen.
afaik Grafics Cards of the Generation of the GForce4 can use 2048² textures, newer Hardware can use up to 4096².

Thanks, Kaeru, I have to think of a good way to include this information.