Is this is a bug or am I not doing something right? I wanted to assign an
implicit array (I think thats what those parameters are being called now) so I
made an overload but the compiler is complaining. Using single characters gives
a different error because the compiler thinks it’s an array of
>Why are you using dynamic arrays for vectors/matricies? If what you have is
an actual array you wish to grow then + would likely be an append operation.
Dynamic arrays are incredibly convenient for purposes like signal processng,
whe you need to handle large blocks of numeric data in variable
> By all means, please reconsider this, and leave me the choice to define the
> operators. If I want "+" for concatting, it is trivial to define it myself.
> I don't need the language to force that and eseentially destroy operator
> overloading for mathematical operations on dynamic arrays.
Same
> On Jun 2, 2018, at 1:35 PM, Nitorami wrote:
>
> I strongly disagree with the opionon that "+" is natural to be the append
> operation.
Not even in the context of a list? I’m still not sure what exactly the
operations you are doing but it sounds like you have a vector of numbers and
you
As a sanity check for myself if you remember a while ago I posted about an idea
for “stack aliases” to override the memory allocation for classes. No one
really liked the idea and lots of potential safety concerns were raised (fair
criticisms).
By random chance today I came upon this feature
On Sat, 2 Jun 2018, Ryan Joseph wrote:
As a sanity check for myself if you remember a while ago I posted about an idea
for “stack aliases” to override the memory allocation for classes. No one
really liked the idea and lots of potential safety concerns were raised (fair
criticisms).
By
> On Jun 2, 2018, at 2:42 PM, Sven Barth via fpc-pascal
> wrote:
>
> It wasn't me who implemented that part. I personally had planned to do it
> with a warning for existing overloads, but Florian beat me to it and
> implemented it this way. Though when asked by me he did say that we'll wait
> On Jun 2, 2018, at 1:44 PM, Michael Van Canneyt
> wrote:
>
> 2 remarks:
> 1. It's only for arrays
> 2. It's for fixed-length arrays
>
> So you can do this in FPC today.
>
> Thirdly, you have objects which can be allocated on the stack, or advanced
> records.
>
> Plenty of choice for you.
> On Jun 2, 2018, at 2:17 PM, denisgolovan wrote:
>
> Same here.
>
> The semantics for vector operations on arrays was thoroughly explored in
> vector languages (APL, A+, J, K, etc).
> Doing per-element dyadic function application is the basis for it. Having
> proper operators overloads is
It's technically possible.
But for vector operations to be valid/consistent both of them should work the
same way. That is perform arithmetic per-element addition.
BTW, you first overload is not implemented properly. You need to clone "left"
first and return it as a result.
BR,
Denis
Yes, I strongly support removing that functionality in favor of user operator
overloads or vector-compatible way.
Moreover, SSE/AVX vector extensions also should work per-element.
I mean those vectors as in https://bugs.freepascal.org/view.php?id=27870
BR,
Denis
> Sven Barth via fpc-pascal hat am 2. Juni
> 2018 um 09:42 geschrieben:
>
> denisgolovan < denisgolo...@yandex.ru> schrieb am Sa., 2. Juni 2018, 09:18:
> > @Sven
> > Please reconsider "+" operator for arrays if your changes really forbid to
> > overload operators for arrays now.
>
>
>
denisgolovan schrieb am Sa., 2. Juni 2018, 09:18:
> @Sven
> Please reconsider "+" operator for arrays if your changes really forbid to
> overload operators for arrays now.
>
It wasn't me who implemented that part. I personally had planned to do it
with a warning for existing overloads, but
On Sat, 2 Jun 2018, Ryan Joseph wrote:
On Jun 2, 2018, at 1:44 PM, Michael Van Canneyt wrote:
2 remarks:
1. It's only for arrays
2. It's for fixed-length arrays
So you can do this in FPC today.
Thirdly, you have objects which can be allocated on the stack, or advanced
records.
Plenty
On 02/06/18 08:00, Ryan Joseph wrote:
On Jun 2, 2018, at 2:42 PM, Sven Barth via fpc-pascal
wrote:> > It wasn't me who implemented that part. I personally had planned to do it with
a warning for existing overloads, but Florian beat me to it and implemented it this way.
Though when asked by
On 06/02/2018 02:01 AM, Ryan Joseph wrote:
So it looks like my idea wasn’t that crazy after all. ;)
just because more than one person comes up with the same or similar idea does
not mean that it is not crazy or worse ;) ;) ;)
--
NOTE: No off-list assistance is given without prior
denisgolovan schrieb am Sa., 2. Juni 2018, 10:28:
> Yes, I strongly support removing that functionality in favor of user
> operator overloads or vector-compatible way.
>
To clear something up: this new operator will definitely not be removed.
Period.
What might be done however (and what I had
> On Jun 2, 2018, at 2:54 PM, Michael Van Canneyt
> wrote:
>
> Personally, I don't understand the obsession with language features.
> If anything, I would make the language more simple. But this is just me
> swimming against the current.
Ironically I totally agree but it’s so difficult to
Mark Morgan Lloyd schrieb am Sa., 2.
Juni 2018, 10:53:
> However as Dennis points out + is also essential for vector operations.
> Perhaps either leaving it to the programmer to define what's needed
> would be the best approach, or alternatively splitting dynamic arrays
> into mathematical
Did anyone have any idea about this or should I just file a bug report for now?
I don’t want to forget about it if possible.
> On Jun 2, 2018, at 1:05 PM, Ryan Joseph wrote:
>
> type
> generic TMyCollection = record
>class operator := (values: array of T): TMyCollection;
>
20 matches
Mail list logo
