Definition of "spilling over"

We are seeing a lot of Spilling over 50 segments messages in the logs, but it's not that clear what this means. Does this just mean there are > 50 segments in the queue, and they'll be sent next request, or are those segments being dropped entirely and never sent upstream?

Hello @joehoyle , thank you for contacting us regarding your question and sorry for the late response. Daemon sends out segments to X-Ray backend by batches and one batch can have up to 50 number of segments. By design, one channel can has 20 batches of 50 segments at maximum and by default daemon has 8 channels to make concurrent calls to X-Ray backend. When you see this sentence Spilling over 50 segments, it means channel is full of 20 batches and the incoming batch is dropped entirely which will never be sent out to our backend. In order to solve this issue, you could config concurrency key in daemon configuration file to increase the number of channels. Please let me know if you have any other questions.

That's great, thanks @luluzhao

I continue to have this issue regardless of increasing memory and or concurrency. Is there any notion of a DLQ or better way to handle the "dropped" traces? For context I've increased concurrency (32) and memory (4gb) but still see spillage.


Disable Google Chrome Updates

Details
@binjo has proposed a way to disable Google Chrome Updates in https://github.com/mandiant/VM-Packages/pull/779 using code from https://github.com/actions/runner-images licenses under MIT  @mandiant/flare-vm is this something we want to do? Does anyone has any concern with possible side-effects? Should we consider adding this as a separate packageconfig.chrome.disableupdates  as proposed in https://github.com/mandiant/VM-Packages/issues/16?

We should check with legal how to best link the MIT license if we decide to include https://github.com/actions/runner-images

The license file includes the following, which indeed we'd need to consult with legals
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.


Requires python 3 but there is python 2.7 badge

Hi,
Is python3 really required? There is a python 2.7 badge but sources tell different.

Yes, the presence of that  badge is a bug.

Fixed in version 0.6

I am using Ubuntu 19.10 and had to use pip3 install licenseheaders, so you might want to adjust the README accordingly. With pip install licenseheaders I get the following error:

Could not find a version that satisfies the requirement licenseheaders (from versions: )
No matching distribution found for licenseheaders

It is not obvious from the error message that this is related to a wrong python version. Personally, I would not have noticed without this bug report (which is why I am commenting here).
Thank you for your this awesome project!

@redtux thanks, I updated the README file in an attempt to make this a bit clearer!

Great, thank you! 🎉 You might further want to replace -c by -o for the copyright owner. (At least the recent version does not have an option -c.)

Thanks again!


y2022 day16 part2: use A*

Is this a path-finding problem?

gave up but found the right answers with the latest version.


Upload image from backend

When I'm trying to upload an image by
clent.images.upload(dataBuffer)
I get an error with status 400
message: '{"detail":"file form field missing or not a file","status_code":400,"code":4,"exception":"InputException","duration":"0.28ms"} with HTTP status code 400' }
I'm trying everything but can't find out how to fix this problem.

I trying to convert image URL to image URI it still no work and I get a new error:
TypeError: source.on is not a function

@phongloihong for uploads in Node you need to pass in a DataStream and a file name.
file = fs.createReadStream('./hello.jpg');
client.images.upload(file, "hello.jpg");

feel free to re-open this issue if you still need more help with this.

@mahboubii - Sorry to bump an old thread but there seems to be a mismatch in expected typings when using TypeScript.
The following code:
    const fileStream = await fs.createReadStream(absolutePathToImage);
    const result = await streamClient.images.upload(fileStream);

Produces this error:
TSError: ⨯ Unable to compile TypeScript:
scripts/stream/uploadImageToStream.ts(11,53): error TS2345: Argument of type 'ReadStream' is not assignable to parameter of type 'string | File | Buffer | ReadStream'.
  Type 'ReadStream' is missing the following properties from type 'ReadStream': isRaw, setRawMode, isTTY, write, and 24 more.

But forcing a type conversion like so:
    const fileStream = await fs.createReadStream(absolutePathToImage);
    const result = await streamClient.images.upload(
      (fileStream as unknown) as NodeJS.ReadStream
    );

Will allow the upload to work.
I believe the types for the upload function
  upload(
    uri: string | File | Buffer | NodeJS.ReadStream,
    name?: string,
    contentType?: string,
    onUploadProgress?: OnUploadProgress,
  ) {
    return this.client.upload('images/', uri, name, contentType, onUploadProgress);
  }

need to be extended to include fs.ReadStream

we have @types/node as a peer dependency, if you have it in your project, it should do the trick for correct typing

@ferhatelmas
I still get the same error message with @types/node in either deps, devDeps, or PeerDeps.
Even created a new project to test outside of my current config.
package.json
{
  "dependencies": {
    "getstream": "^8.0.1",
    "typescript": "^4.7.4",
    "@types/node": "^18.0.4"
  },
  "peerDependencies": {
    "@types/node": "^18.0.4"
  }
}

index.ts
import Path from 'path';
import fs from 'fs';
import stream from 'getstream';

const apiKey= ''
const apiSecret = '';
const apiAppId = '';

const uploadImage = async () => {
  const absolutePathToImage = Path.resolve('./image.png');
  const fileStream = await fs.createReadStream(absolutePathToImage);

  const streamClient = stream.connect(apiKey, apiSecret, apiAppId);
  const result = await streamClient.images.upload(fileStream);

  return result
}

const client = stream.connect(apiKey, apiSecret, apiAppId);

Produces the same error message:
Argument of type 'ReadStream' is not assignable to parameter of type 'string | Buffer | File | ReadStream'.
  Type 'ReadStream' is missing the following properties from type 'ReadStream': isRaw, setRawMode, isTTY, write, and 25 more.ts(2345)

Am using default tsconfig.json produced by npx tsc --init
Happy to test other suggestions.


Nathaniel

Description

Type of change
Please select all relevant options

[x] New feature (non-breaking change which adds functionality)
[x] Bug fix (non-breaking change which fixes an issue)
[x] Formatting and/or style fixes
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?

[x] Test A : Sedov
[x] Test B : Sedov with origin being deleted
[x] Test C : a box penetrating a plate

Test Configuration:

OS version:  14.4.1
Hardware: i9 core
Compiler: clang c++ (Mac)

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] The code builds from scratch with my new changes
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] Any dependent changes have been merged and published in downstream modules

Looks good on my end.  Just get it up to date with main and you should be good to go.


Bug: Null Result Issue with SignalRTrigger Functions in .NET8 Upgrade

What version of .NET does your existing project use?
.NET 6
What version of .NET are you attempting to target?
.NET 8
Description
Hello,
I wanted to bring up an issue with the SignalRTrigger solution. My team and I are using this approach in .NET6 for our project to trigger some asynchronous operations. In response, we are returning a custom object indicating whether the operation was successful. However, in .NET8, our SignalRTrigger functions consistently return a null result in the server response, regardless of our efforts to fix it. It is worth mentioning that during the .NET8 upgrade, we are migrating our functions to isolated mode.
Expected
Function with SignalR trigger and return type will send custom response in result field to client.
Actual
Function with SignalR trigger is sending null result to client.
Examples

Click me
Here is our server-side code in .NET6:
[SignalRHub(path: "")]
public partial class MainHub : ServerlessHub<IMainHub>
{
    ...
    [FunctionName(nameof(Echo))]
    public async Task<SignalRHubActionRequest> Echo([SignalRTrigger()] InvocationContext invocationContext, string name, string message)
    {
        await Clients.Client(invocationContext.ConnectionId).Echo(name, message);
        return new SignalRHubActionRequest { SignalRHubActionStatus = SignalRHubActionStatus.Accepted };
    }
    ...
}

public class SignalRHubActionRequest
{
    public string Id { get; set; }
    public Status Status { get; set; }
}

public enum Status
{
    Success,
    Failure
}

The only change in .NET8 solution for this code snippet is the Echo function (in the SignalRTrigger attribute):
[Function(nameof(Echo))]
public async Task<SignalRHubActionRequest> Echo([SignalRTrigger(nameof(MainHub), CATEGORY, nameof(Echo), "name", "message")] SignalRInvocationContext invocationContext, string name, string message)
{
	await Clients.Client(invocationContext.ConnectionId).Echo(name, $"async : {message}");
	return new SignalRHubActionRequest { SignalRHubActionStatus = SignalRHubActionStatus.Accepted };
}

This is how we registered SignalR in .NET6:
builder.Services.Configure<SignalROptions>(o => {
    var settings = new JsonSerializerSettings()
    {
        NullValueHandling = NullValueHandling.Ignore,
        ContractResolver = new CamelCasePropertyNamesContractResolver()
    };
    settings.Converters.Add(new Newtonsoft.Json.Converters.StringEnumConverter());

    o.JsonObjectSerializer = new NewtonsoftJsonObjectSerializer(settings);
});

This is our registration in .NET8:
services.AddSignalR()
        .AddNewtonsoftJsonProtocol(options =>
        {
            options.PayloadSerializerSettings = new JsonSerializerSettings
            {
                NullValueHandling = NullValueHandling.Ignore,
                ContractResolver = new CamelCasePropertyNamesContractResolver()
            };
            options.PayloadSerializerSettings.Converters.Add(new Newtonsoft.Json.Converters.StringEnumConverter());
        });

And this is our C# SignalR client code:
await using var connection = new HubConnectionBuilder()
	.WithAutomaticReconnect()
	.WithUrl(uriTime, options =>
	{
		options.AccessTokenProvider = () => Task.FromResult(accessToken);
	})
	.AddNewtonsoftJsonProtocol(options =>
	{
		options.PayloadSerializerSettings = new JsonSerializerSettings
		{
			NullValueHandling = NullValueHandling.Ignore,
			ContractResolver = new CamelCasePropertyNamesContractResolver()
		};
		options.PayloadSerializerSettings.Converters.Add(new Newtonsoft.Json.Converters.StringEnumConverter());
	});
await connection.StartAsync();

var result01 = await connection.InvokeAsync<SignalRHubActionRequest>("Echo", name, message);

We inspected the request and observed that the server side is returning null in the result property, regardless of what we attempt to send (e.g., a string instead of SignalRHubActionRequest or changing serializer to default or json one). We confirmed this by using tools like ngrok and Fiddler.

We tried several approaches, with the most promising one being the use of the SignalROutput attribute to bind the output:
[SignalROutput(HubName = nameof(MainHub), ConnectionStringSetting = "AzureSignalRConnectionString")]

This resulted in a server-side error. When we changed the return type to string while using this SignalROutput attribute, we encountered a different error.

Ultimately, we downloaded the latest codebase from your repository and used your samples, specifically the Extensions solution, and experienced the same null result issue.
This indicates that the problem lies within your library. We are unsure of the cause of these varying errors, but based on these examples, it appears you can return error objects. This implies you should be able to return an object in the result property as well. We initially thought this functionality was removed, but the errors suggest otherwise. Additionally, your documentation does not indicate that the feature to return objects from a SignalRTrigger function was removed. Therefore, we are requesting your assistance and investigation into this issue.
Thank you.
Project configuration and dependencies
Azure function app
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <AzureFunctionsVersion>v4</AzureFunctionsVersion>
    <OutputType>Exe</OutputType>
	<_FunctionsSkipCleanOutput>true</_FunctionsSkipCleanOutput>
	<GenerateDocumentationFile>True</GenerateDocumentationFile>
	<Nullable>enable</Nullable>
  </PropertyGroup>
  <ItemGroup>
	<PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" />
	<PackageReference Include="Microsoft.AspNetCore.SignalR.Protocols.NewtonsoftJson" Version="8.0.7" />
	<PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.22.0" />
	<PackageReference Include="Microsoft.Azure.Functions.Worker.ApplicationInsights" Version="1.2.0" />
	<PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.DurableTask" Version="1.1.4" />
	<PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http" Version="3.2.0" />
	<PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="1.3.2" />
	<PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore.Analyzers" Version="1.0.2" />
	<PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Rpc" Version="1.0.0" />
	<PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.ServiceBus" Version="5.20.0" />
	<PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.SignalRService" Version="1.14.0" />
	<PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Timer" Version="4.3.1" />
	<PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.4" />
	<PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk.Analyzers" Version="1.2.1" />
	<PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk.Generators" Version="1.3.2" />
	<PackageReference Include="SignalRSwaggerGen" Version="4.7.0" />
  </ItemGroup>
  <ItemGroup>
    <Using Include="System.Threading.ExecutionContext" Alias="ExcutionContext" />
  </ItemGroup>
</Project>

Client app:
<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.SignalR.Client" Version="8.0.7" />
    <PackageReference Include="Microsoft.AspNetCore.SignalR.Protocols.NewtonsoftJson" Version="8.0.7" />
  </ItemGroup>
</Project>

Link to a repository that reproduces the issue
https://github.com/Azure/azure-functions-dotnet-worker/tree/main/samples/Extensions/SignalR

I am having same issue as well so looks like SignalR has not caught up with recent .NET8 upgrades

I was just going to post something similar, Im also seeing this issue.

I have did investigation on your source code and looks like you are passing the return object to the Sytem.Threading.Channels library in GrpcWorker:ProcessRequestCoreAsync() to send it over to the client side. I cannot go further but seems something there is ignoring our return object. It can be wrong assigment or anything, but it is outside of my reach.
There is one more thing that got my attention that in your main branch, in DotNetWorker.Grpc project, you do not have setup .net8 dedicated packages - instead you refer to System.Threading.Channels to 6.0.0 version in your .NETStandard references. I checked and the newest package version is 8.0.0 which has high probability it is the version prepared for .NET8. Can it be related to this issue? Maybe updating reference would fix the problem we are facing?
At last I can add, that our codebase with working solution was using Microsoft.Azure.WebJobs.Extensions.SignalRService package instead (for in-process mode in function app).

Can someone from admins add label potential-bug and need-attention?

Hi,
Has anyone seen any updates on this issue being investigated?
This is also impacting my live project and preventing me from upgrading to .NET8, so I'm eager for this to be resolved asap.
Thanks.

@Y-Sindo Is this something you can help look into?

@satvu This is a known issue, see #1496 . Please see #1496 to track the progress.

Closing this as duplicate - please track using #1496


Problem with toolbox installation via USB2HSD method

Hi guys,
I've tried to install the toolbox via USB2HSD method and when I ran the install.sh script, I got this errors during installation and no toolbox is installed.

When I was looking in to path "/emmc/tsd/etc/persistence/esd/" in the unit according to the commands in the script, there was no files or scripts copied from the specific folder on SD card.
Is this a problem of specific unit or some bug in the install.sh script?
If it's a problem in script, how can I help you to solve it?
Unit number: 5Q0 035 840 A
SW Train: MST2_EU_SK_ZR_P0253T
Many thanks.

Here is a screenshot of the console.

Hello sorry maybe you can help me
This method of USB2HSD What is it? Is it a cable to connect to the computer or a flash drive?
I have the firmware MST2_EU_SE_ZR_P0253T similar to yours so if you guide me in what you did I try too so let's see if it gives the same errors to me. For now I only managed to unlock the developer mode and behind there is the greenmenu but GEM 3.5
I have a Seat with only one. SD card slot

Hello, I followed the instructions on mibwiki.one, here is the link.
Personally I recommend to be very careful as I already managed to break one unit.
I don't know if the USB2HSD cable can be bought, probably not. I made it from a regular USB cable and a purchased HSD cable based on the diagram in link.

Can someone tell me step by step how to go and / or make this USB2HSD cable? Is there a video or images?

I saw. It's not easy at all. But now I ask, when you update the firmware and everything is fine, in the same firmware that you have updated you can not already put the toolbox inside so as to access it from the greenmenu? So when you install your firmware you automatically install the toolbox without welding bridges or anything else.

Hey guys,
I have a 500035840C unit with SW-Train MST2_EU_SK_ZR_P0468T installed.
This is a single sd slot unit, is this mythical USB2HSD cable the only way to install without the soldering method?
I haven't tried to install anything additional yet.
Thanks.

why i can`t access mib.wiki. i tried the the telegram and discord ways and both not letting me to login, even that everything is correct from discord and telegram

why i can`t access mibwiki.one i tried the the telegram and discord ways and both not letting me to login, even that everything is correct from discord and telegram

same here! :(

I am too unable to login. Can someone share this mib-std2-toolbox-installation-via-usb2hsd-cable-aka-solderless-method-0Xzt03EC4d here?


Can cython change cpp compiler?

Fresher to cython here ,when I was runing demo codes (the specific situation is that I was testing if cpp stl could run properly on cython) there gots some wrong answer. Since there seems no problem in code , I guess it may cause by I've installed both 32/64bit compiler and 64bit python in my os , and by defalut cython called 32bit compiler during compile.
Is there any way I could swith to 64 bit gcc compiler? Didn't find instructions in documentation , needs help thanks.
Test codes here:
demo.pyx
# distutils: language=c++
import cython
from libcpp.vector cimport vector

def main():
    cdef vector[int] vect
    cdef int i
    cdef long s = 0
    for i in range(1000000):
        vect.push_back(i)
    for i in range(1000000):
        s += vect[i]
    return s

setup.py
from distutils.core import setup
from Cython.Build import cythonize

setup(
    ext_modules = cythonize(
        "demo.pyx",
    )
)

These codes got result<PHONE_NUMBER>

Please ask support questions on the Cython-users mailing list: https://groups.google.com/forum/m/#!forum/cython-users. In this case the choice of compiler is made by distutils. You won't be able to import a 32 bit module from 64 bit Python so I'd suggest the compiler isn't your problem.


ENH: add fast toeplitz matrix multiplication using FFT

This commit adds a function, matmul_toeplitz, for efficient (loglinear time) matrix-matrix products involving a Toeplitz matrix. The Toeplitz matrix is embedded in a circulant matrix, which is diagonalisable using its discrete Fourier transform. It follows that matrix-vector products and hence matrix-matrix products can be computed using the FFT.
This is described in this book, this MIT page and in this math.stackexchange post.
Further, I split some code from the solve_toeplitz function into a cleaning and validation function _validate_args_for_toeplitz_ops because the cleaning needed for both functions is very similar. In the future, if someone implements other fast methods such as matmul_circulant, log_det_circulant, log_det_toeplitz and so on, they could rely on the same validation function.
There are three reference implementations (that I could find) available online which are written in python, these are:
.. [a] : Jacob R Gardner, Geoff Pleiss, David Bindel, Kilian
Q Weinberger, Andrew Gordon Wilson, "GPyTorch: Blackbox Matrix-Matrix
Gaussian Process Inference with GPU Acceleration" with contributions
from Max Balandat and Ruihan Wu.

Available online
.. [b] : R. Scheibler, E. Bezzam, I. Dokmanić, Pyroomacoustics: A Python
package for audio room simulations and array processing algorithms,
Proc. IEEE ICASSP, Calgary, CA, 2018.

Available online
.. [c] : Maranò S, Edwards B, Ferrari G and Fäh D (2017), "Fitting
Earthquake Spectra: Colored Noise and Incomplete Data", Bulletin of
the Seismological Society of America., January, 2017. Vol. 107(1),
pp. 276-291.

Implementation available online
My implementation seems to be consistent with all of them (the code isn't a direct 'copy-paste' of any of them - the github implementations have MIT licenses and I've referenced these in the function), and I've tried to remain consistent with existing Toeplitz functions in SciPy.
The possible use-cases for this function include fast matrix-matrix multiplications, fast solving using preconditioned conjugate gradient methods (which can readily be built using the scipy.sparse.linalg.LinearOperator class and the scipy.sparse.linalg.cg function).
Tests show that the implementation is correct, and the tests corresponding to solve_toeplitz also all pass. The code passes PEP8 checks locally.

@InfProbSciX this sounds cool. Can you also post some speed test results that demonstrate the speedup?

Yes! Forgot about that :)
Some simple code to run these benchmarks:
import numpy as np
from scipy.linalg import toeplitz, matmul_toeplitz
from numpy.testing import assert_allclose

def fast_sim(n):
    c = np.random.normal(size=n)
    r = np.random.normal(size=n)
    b = np.random.normal(size=n)
    result = matmul_toeplitz((c, r), b)

def naive_sim(n):
    c = np.random.normal(size=n)
    r = np.random.normal(size=n)
    b = np.random.normal(size=n)
    expected = toeplitz(c, r) @ b

# %timeit fast_sim(10000)
# %timeit naive_sim(10000)

Results on my laptop:

Row Len
This_Commit
Naive

100
164 µs
64 µs

1000
768 µs
2650 µs

1000
9640 µs
617000 µs

I verified the performance improvement and accuracy on my machine. Impressive!

@InfProbSciX Thanks a lot for such a thorough pull requests. I wish we get more of such PRs.
I am a bit pessimistic about adding this to the public API since to people who need this, they are quite well-known (in particular the netlib links you gave are famous). The use case is for people who are aware that they have a toeplitz matrix and not aware that there are more performant ways to multiply these matrices.
That number of people to me doesn't appear to be too many to add another function to the public API. For those who are aware of these facts, it is basically a couple of lines. This applies to circulant and hankel matrices too.
Don't get me wrong; I think this is great to have at one's bag of tricks but the curse of SciPy is that once something goes in it takes years to take it out if we decide to have a different way of bundling these together. So I tend to be on the conservative side. But I'll wait for others to chime in too.

It's true that this is just a few lines, but scipy has functionality for solve_toeplitz only at the moment. When I was getting into this, I felt like it was so difficult to try and learn how these operations can be made more performant. Seeing solve_toeplitz was an eye opener, but there are other tricks like the matrix multiplication one, conjugate gradients and so on, that would be great to support a newcomer into the field. Scipy is also (I feel like) the first place I would look for these - I was also very disappointed to learn that BLAS and LINPACK don't come with so many interesting efficient linear algebra routines, so we must rely on third party algos. Matlab seems to have many of these algos built in - I would like to see scipy having some of these too. It's also quite frustrating to look for simple implementations of the Bariess and so on to find that, outside of those closely knit communities who know how it works, it's difficult to find some code that actually does what you were looking for, particularly python code.
Moreover, there are some implementations of this in the public domain (referenced), that perhaps wouldn't be necessary if scipy had the functionality to begin with. The special matrices in scipy are mentioned but I feel like not a lot can be done with them as the most important operations that make use of their special structure are missing.
I actually want to add the other functions as well, like the log_det_* functions at some point, when I have enough time to write them.

That's certainly true and makes a good segway to our mantra "Try to avoid small tricks as public functions". Note that solve_toeplitz uses a LAPACK routine behind the scenes and in my opinion still doesn't fit our mantra but historically these additions came in a very heterogeneous way historically and now we don't dare to decommission them. That is also why BLAS/LAPACK maintainers don't add every function to the catalogue because they are thinking along the same manner.
There are many things I wish we had, for example, one of the longest discussions we had is to have a .H for a shortcut of .conj().T in NumPy arrays. The use case is very clear and it is possibly the most used shortcut but even then there are many things to consider and we still don't have it due to historical reasons.
I have a PR waiting for linalg.solve that auto-detects the matrix structure and uses the proper LAPACK routine that is what matlab's backslash operator is famous for. But it touches so many things that I am still reluctant to propose.
All these to say, even though the functionality is nice, we might not want to add because it pollutes the namespace and also makes it very difficult a few years later to maintain if we figure out a better way to do this. I actually expect this to be handled by the matmul operator of ndarray since it is responsible multiplying the matrices.

I definitely see what you're saying - and I completely agree that we don't want to pollute the public namespace. The main reason I wrote this the way I did was consistency - as solve_toeplitz is written in the same way (as a standalone function instead of a method in a class).
I don't see this as a small trick, as I also want to write the determinant functions which wouldn't be such a trivial implementation. I'm trying to do this so that the scipy toeplitz/special matrices section isn't so incomplete.
If the others are unhappy with the public function as well, here are some proposals to make this hidden from the user:

I could write this as a static method of a toeplitz class. The main problem with this is that we'd need to change the toeplitz function to a class inheriting from ndarray (because I think that's the return on that function). It would be a static method as it also takes in a tuple of row, column as the toeplitz function does. This wouldn't be clean and might cause problems along the way if we were ever to expand the special matrices part.

I could write something into ndarray. I'm extremely reluctant to do this for two main reasons. The major problem with this is that it would lose the efficiency as the ndarray would have to be in memory before the multiplication happens. I also don't really want to cause discrepancies between numpy and scipy, and further, the choice should be up to the user to prefer this method over classic matrix multiplication.

Make this a hidden function, so that only users who really want to use this function would access the function as import _xxx from scipy.linalg (I'm not even sure if this works, and I'm sure it would be bad practice).

I want the special matrices section to be more complete, and I completely understand that the implementation looks trivial, but I don't see the other functions that I'd like to contribute in the future being just tricks, as these are great routines to use. There's a good use case for it - toeplitz matrices are common in statistics, particularly stationary processes - perhaps more people would come to use the routines if they were more easily accessible. I see numpy as the more minimalistic linalg package; scipy's design states that "A good rule of thumb is that if it’s covered in a general textbook on numerical computing ... it’s probably implemented in SciPy." I would like to really complete the special matrices part of scipy to live up to that, because at the moment, there's lots of stuff missing.

There are other obvious implementations that currently SciPy doesn't support for matrix multiplication say, diagonal matrices, triangular matrices etc. even when they have a corresponding BLAS routines for them say ?gbmv or ?trmv and their ...mm flavors. They are not exposed currently but as you argue above then we have to create a whole matmul class for each and everyone of them.
I would actually put the actual lines into the documentation of linalg.toeplitz for the interested.
The main issue here for a possible generalization is that discovering a Toeplitz matrix takes more time than just straightforward matrix multiplication hence the benefit of the whole thing is reduced down to the user who is aware that they have a toeplitz matrix at hand and would likely to look at linalg.toeplitz.

As another approach for Toeplitz matrix-vector products, there's an implementation for symmetric Toeplitz matrices in the HomogeneousIsotropicCorrelation class here, especially the from_array factory method with is_cyclic=False and the _matmat method (is_cyclic should probably be renamed to is_periodic for clarity; the terminology refers to whether the random field whose correlation matrix is represented by the operator has periodic boundary conditions or not).   There's also a draft PR for calculating the determinant that could be adopted for log-determinant, though I never figured out how to get it to return the same answer as numpy.linalg.det() if the matrix is not also circulant.
It sounds like one solution to not wanting all the special matrix implementations in scipy proper would be to make a package/repository of LinearOperator subclasses for special matrices somewhere.  PyLops has one batch, though it seems targeted at geophysical applications rather than general numerics.  The separate package would be somewhat more work than the web page with example code that I thought was mentioned above but can't find now.
I hope at least some of this was useful to someone.

@ilayn The log determinant calculation seems to be a straightforward implementation that utilises the levinson algorithm. Would you be okay if I modified the existing hidden cython implementation by adding an additional flag like return_log_det = False, so that if the flag is set to true, the function returns a tuple of result, log_det? I don't think that there would be any significant overhead if the flag is set to false as the log_det seems to be a free/low-cost side effect if the levinson is run.
There wouldn't be any additional public functions and if everyone else agrees, I'll put the matrix multiplication into the toeplitz documentation.

Hi @DWesl, thanks for mentioning fa PyLops. I second you here, and this is the first reason I started developing this library some years ago: I didn’t feel that scipy would ever allow/be the best place to host many specialized ‘matrix’ implementations. It is true that geophysics is currently the main target (given that it is a very data hungry field) but there is a very extensive set of basic functionalities and we have been even discussing about the possibility of moving all geophysics specific components out to a new library and keep PyLops for just general purpose operators. If people are interested we could speed this up.
Regarding this PR, @InfProbSciX, I am glad to see that more and more people feel the need to optimizing matrix-vector multiplications for special matrices. My main question is: why not subclassing a LinearOperator already (as you also mention eventually users would do that...), this may seem a break in the current trend in scipy but it may pay off in the long run. For example if you want to add log_det* as you say, you will need another public method and raise the same concerns as in this thread. If instead you went for a Toeplitz class this could be just a method of the class, so you limit what it is effectively exposed in the API? Just a suggestion :)

@mrava87 I'd love to add a Toeplitz class to SciPy but this adds more publicly accessible stuff in SciPy, so the decision is up to the devs really. This is the cleanest way to add the functionality imo.
My suggestion for adding the log_det flag to the existing solve function was just a way to add the functionality without adding a public function.

I see your point. I was just thinking that in your case you still add a new public function (while in the case of making Toeplitz class you would add a class). Of course this is a bit different from current scipy structure so it’s obviously up to the devs.
My personal opinion as user is that I prefer more
well defined methods with ‘atomic’ scope than fewer with of additional parameters that lead to many slightly different behaviors, but again I’m not a core dev of scipy so it’s just a comment from user point of view.

@WarrenWeckesser Please feel free to add that code to the commit as well :)
@scipy/scipy-core-team Just following up on this - have you reached a resolution on whether this code should be added?

I verified the performance improvement and accuracy on my machine.

Am I missing any comments or benchmarks for accuracy? All I see is test cases with assert_allclose with the default tolerances, which isn't tight enough for what one would expect for matrix multiplication.

So I'm in favor of adding implementations of the fast matrix-vector products for Toeplitz and Hankel matrices to scipy.linalg. I haven't yet reviewed this PR, so at the moment, I'm just giving a +1 for the feature request.

...

'd love to add a Toeplitz class to SciPy but this adds more publicly accessible stuff in SciPy, so the decision is up to the devs really. This is the cleanest way to add the functionality imo.
My suggestion for adding the log_det flag to the existing solve function was just a way to add the functionality without adding a public function.

My impressions:

there seems to be enough interest to add this functionality in some form, so let's do that
adding matmul_toeplitz, matmul_hankel, and more functions for specialized logdet etc. seems a little ad-hoc. on the other hand, we do have solve_toeplitz et al. already.
adding a LinearOperator subclass may be the better design. the downside is that one then does need to add all functionality in one go, rather than method by method.

I'm +0.5 for merging this PR in its current form (matmul_toeplitz). If we have solve_*, matmul_*, logdet_* etc., the namespace pollution is less bad than if all names would be more random.

Thanks for the comments, I'll make the changes.

I verified the performance improvement and accuracy on my machine.

Am I missing any comments or benchmarks for accuracy? All I see is test cases with assert_allclose with the default tolerances, which isn't tight enough for what one would expect for matrix multiplication.

I decreased the tolerance to 1e-10. Decreasing the tolerance to 1e-12 sometimes fails the tests (e.g. due to one number in a 1000x1000 matrix not being within tolerance). Could this perhaps be made better by using another data type (e.g. float64s instead of floats)? I'll have a look to see if this is the case if this tolerance is still too big.

It shouldn't sometimes fail, that means you're missing a random seed probably. Test runs are supposed to be deterministic.
No, data type is fine, float is a Python builtin, and when you specify it what you get is numpy.float64

The tests are deterministic; what I meant was that if I ran the tests at the lower tolerance without the seed, they sometimes failed.

Please do let me know if there's something else you'd like me to do/change. The tests seem to be passing with the exception of build_docs - some help here would be much appreciated (I'm not sure what's going on there).

My guess, based on my experience trying to get a standalone package working (https://github.com/DWesl/py-toeplitz), is that the tests failing with rtol=1e-12 are from places where math.isclose(desired, 0).  You may be able to get around those by setting atol=1e-14 or similar.

Hi @scipy/scipy-core-team, what needs to be done for this PR? I will make the change suggested by @DWesl - is there anything more that you'd like me to do? Is this PR still awaiting a decision regarding whether or not this functionality can be added?

@rkern @rgommers @mdhaber @peterbell10 @ilayn @WarrenWeckesser Hi team. I'm just following up to see if a decision has been made for this PR.

This seems to be in good shape and from the history it looks like we're leaning towards merging this in its current form. Does anyone have objections to that?

Don't merge yet, I'm working on a more detailed review now.

Thanks for the comments, I'll make these changes.

@WarrenWeckesser I've made the suggested changes - thank you for such a detailed comment on the case of non-square matrices :)

All the CI checks now pass.

Hi @rgommers @WarrenWeckesser - sorry to be a bother! I'm just following up to see if there's any further changes that you'd suggest for this PR.

Hi @rgommers @WarrenWeckesser I'm just following up to see if there's any further changes that you'd suggest for this PR.

@WarrenWeckesser All done!

I've given this the green check mark, but I'll wait a few days before merging, in case anyone else want to comment first.
When it comes time to merge, the commits should be squashed to a single commit.

@WarrenWeckesser Just wanted to check if you'd like me to squash these commits (or if GitHub's squash and merge is fine).

@InfProbSciX, squashed and merged, thanks!  I undid the change to THANKS.txt--that file has been removed.

I added a "thanks" to https://github.com/scipy/scipy/wiki/THANKS.txt-additions-modifications-for-1.6.0, and a release note in https://github.com/scipy/scipy/wiki/Release-note-entries-for-SciPy-1.6.0.  Feel free to edit those as you see fit.


How use it for full screen presentation?

Hi guys,
The main goal is to present my first viewController looking like a "classic" modal, and detail controllers pushed inside will be smaller.
I tried to set contentSizeInPopup with UIScreen bounds dimension and set transition with a full screen presentation, but it didn't work.
Is there anyway to do that in a proper way?
Thanks,
Ben

Hi, if you are going to present the view controller as a normal modal, just use "presentViewController" provided by UIViewController, instead of using STPopupController. contentSizeInPopup will only work if the view controller is pushed into a popup controller.

Hi kevin, thanks for your quick answer.
I already tried that, but as I said, I need details controllers with smaller sizes, and as I started with STPopupController, I can't really reimplement a use case only for make it full screen.
Best behaviour was to set contentSizeInPopup with maximum height minus navigationbar height.

@popei69 why do you need to reimplement it? you can make one view controller as both popup and normal view controller.

@kevin0571 I would like to optimise screen view depending of the device dimension (iphone4s vs iPad). On (really) small device, I will choose full screen, and not for bigger one. I wanted to keep same code as far as I can, but seems STPopup cannot "fake" a classic modal presentation in full screen. Thanks anyway.


the size of tflite

thank you for your great works!
I have a question about your work.

why the size of tflite is different from media-pipe's one?

I think it's because media-pipe hands used float16 and I used float32